|
| |
|
|
| |
для: Саня
(20.12.2009 в 20:16)
| | | А я очень замечаю. Причем на столько, что нервов нехватает. Это наверное еще от каналов зависит и провайдера. Но факт есть факт. В любом случае на шифрование страницы требуется время. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 20:10)
| | | В смысле про траффик и медлительность.
> Ну ведь реально медленный протокол, неужели и это будет оспариваться....
Что-то я не замечаю этих эффектов при работе с gmail. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 20:03)
| | | В смысле неприватные?))) Ну ведь реально медленный протокол, неужели и это будет оспариваться.... | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:59)
| | | Откуда такие данные? | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 19:39)
| | | Нерентабельность в скорости и трафике, я же написал. Если данные не приватны, то нет смысла пользовать такой неповоротливый протокол. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 19:18)
| | | Вот другой алгоритм:
С. генерируем случайную соль и запоминаем (в БД, файлы, сессию... куда угодно на сервере) обозначив принодлежность к логину. Её же передаем клиенту.
К. вводит пароль и отправляет серверу хеш-функция(соль и хеш-функция(пароль))
С. смотрит соответствие отпечатка хеш-функция(соль конкретного юзера и хеш пароля из базы) Сразу после этой операции удаляем соль из памяти, чтобы нельзя было воспользоваться ей второй раз.
Вот и вся коллизия. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:00)
| | | > Использовать HTTPS для сокрытия пароля как минимум нерентабельно
В чём же нерентабельность?
Так же не следует забывать, что шифруются и передаваемые страницы, которые могут содержать приватный контент. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:11)
| | | Коллизия — это строка (или не строка), не совпадающая с исходной, и дающая такой же хеш как и исходная строка. Вероятность нахождения этой строки микроскопическая.
> Зачем именно в явном виде хранить?
Вот примерный алгоритм использования изменяемых солей:
С. генерируем случайную соль и запоминаем (в БД, файлы, сессию... куда угодно на сервере)
К. вводит пароль и отправляет серверу соль и хеш-функция(соль+пароль)
С. смотрит что за соль и есть ли она у него в памяти. Если есть, достаём по введённому логину пароль и сравниваем хеш-функция(соль из памяти + пароль из базы). Сразу после этой операции удаляем соль из памяти, чтобы нельзя было воспользоваться ей второй раз. | |
| |
|
|
| |
|
|
| |
для: Саня
(20.12.2009 в 19:10)
| | | Ну а чем хэш пароля не коллизия? Зачем именно в явном виде хранить? | |
| |
|
|
| |
|
|
| |
для: Николай2357
(20.12.2009 в 19:00)
| | | Если соль не меняется при каждой аутентификации, то тогда нет смысла городить этот огород. Опять же, снифаем соль, хеш. Подставляем эти данные в форму и вуаля!
Но если соль изменяется, тогда обязательно нужно знать пароль. Или любую другую строку, дающуюю коллизию с паролем :). | |
| |
|
|
|
