Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум (новые сообщения вниз) Структурный форум

тема: Хранение логина и пароля в куках

Сообщения:  [1-10]    [11-20]   [21-30]  [31-38] 

 
 автор: Trianon   (29.12.2007 в 19:44)   письмо автору
 
   для: Loki   (29.12.2007 в 10:01)
 

admin_key ты вроде как предлагал вшить в php-код. Впрочем, я мог понять тебя неправильно.

   
 
 автор: Loki   (29.12.2007 в 10:01)   письмо автору
 
   для: Trianon   (29.12.2007 в 09:54)
 

Я не спорю, просто раз уж мы начали придираться к словам...:)
Под сервером, я естественно подразумевал сервер БД.

   
 
 автор: Trianon   (29.12.2007 в 09:54)   письмо автору
 
   для: Loki   (29.12.2007 в 09:47)
 

Саш, по той же причине, по которой мы вообще меняем пароли на хеши, лучше сдеалть так, чтобы основному серверу по возможности и эти хеши были бы неизвестны.
Другими словами, было бы лучше, если б проверить хеш на адерватность сервер бы мог, а выдать его (а уж нем паче все хеши разом) - уже нет.
Именно поэтому их лучше таки хранить в БД, причем доступ строить не через таблицу, а через представление или хранимую процедуру, доступ к которой дать от дополнительного эккаунта БД или даже вообще разместитьь в другой БД.

   
 
 автор: Loki   (29.12.2007 в 09:47)   письмо автору
 
   для: Trianon   (28.12.2007 в 19:50)
 

В том случае, если они в БД хранятся:)

   
 
 автор: Trianon   (28.12.2007 в 19:50)   письмо автору
 
   для: Loki   (28.12.2007 в 10:26)
 

Серверу - неизвестны.
Известны БД.

   
 
 автор: Loki   (28.12.2007 в 10:26)   письмо автору
 
   для: Trianon   (27.12.2007 в 22:28)
 

>В том что по хешу и admin_key (а это велична известная, как минимум серверу) несложный пароль можно подобрать. А значит этим мы создаем соблазн атаки охоты за этим admin_key.
Серверу так же известны хэши паролей. Так не логичнее ли охотится непосредственно за ними, если уж все равно атаковать сервер?

   
 
 автор: Trianon   (27.12.2007 в 22:28)   письмо автору
 
   для: Loki   (27.12.2007 в 13:10)
 

>>Конечно это лучше чем пароль в открытом виде, и даже лучше чем чистый хеш md5, но зачем?
>просто я не вижу чем твое предложение принципиально отличается. Ты просто вводишь еще один пароль, для автологина.

Я бы не стал называть его паролем. Если его кто-то перехватит, он не сможет сделать ни одно действие, для которого требуется ввод пароля руками.


>Ну у нас теперь два независимых пароля для разных целей.... в чем защищенность?
>В том что по хешу и admin_key (а это велична известная, как минимум серверу) несложный пароль можно подобрать. А значит этим мы создаем соблазн атаки охоты за этим admin_key.

>Из предложенного мной хэша, получать пароль попросту нецелесообразно - проще взломать фтп сервер или сервер БД. Так как admin_key может быть абсолютно произвольным набором символов любой длинны (мне же его не надо запоминать). А украв и подделав куку все равно как авторизоваться по "хэшу на основе пароля" или по "второму паролю".

Нет, не всё равно. По автологону не может ( точнее не должен ) быть доступен весь спектр операций с приватным контентом.
Например, изменение пароля,. других параметров профиля, а иногда даже отправка сообщений будет требовать явной аутентификации путем ввода пароля.

   
 
 автор: Loki   (27.12.2007 в 13:10)   письмо автору
 
   для: Trianon   (26.12.2007 в 22:26)
 

>Конечно это лучше чем пароль в открытом виде, и даже лучше чем чистый хеш md5, но зачем?
просто я не вижу чем твое предложение принципиально отличается. Ты просто вводишь еще один пароль, для автологина. Ну у нас теперь два независимых пароля для разных целей.... в чем защищенность? Из предложенного мной хэша, получать пароль попросту нецелесообразно - проще взломать фтп сервер или сервер БД. Так как admin_key может быть абсолютно произвольным набором символов любой длинны (мне же его не надо запоминать). А украв и подделав куку все равно как авторизоваться по "хэшу на основе пароля" или по "второму паролю".

   
 
 автор: Trianon   (26.12.2007 в 22:26)   письмо автору
 
   для: Loki   (26.12.2007 в 16:15)
 

В качестве автологон - токена?
Или в качестве параметров аутентификацииприменяемых при проверке пароля, вводимого руками?

Если первое - тем, что в вычислении задействован пароль. Зависимость от него условиями задачи не требуется, ведь так? Тогда зачем?
Собственно, я сам предлагал нечто такое ... в одной из тем.
Конечно это лучше чем пароль в открытом виде, и даже лучше чем чистый хеш md5, но зачем?

Если второе, то имеет смысл ввести зависимость от известных данных.
В данном случае - от логина пользователя.

   
 
 автор: vitali   (26.12.2007 в 16:30)   письмо автору
 
   для: Drago   (26.12.2007 в 15:22)
 

Для "Елена Смирнова" сходите на страницу:
http://www.frolov-lib.ru/books/bsp/v34/ch7.htm#ch7_0

   

Сообщения:  [1-10]    [11-20]   [21-30]  [31-38] 

Форум разработан IT-студией SoftTime
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования