Хеширование пароля (без SSL)

Question

Как пароль отправляется из браузера на сервер в случае передачи не по протоколу ssl?

Я хочу использовать bcrypt для хэширования пароля + соли перед отправкой .... но, похоже, реализации javascript нетдля алгоритма bcrypt ...

достаточно ли md5, SHA-1?

PS: мой сайт не хранит никакой личной информации пользователя. Я просто хочу, чтобы пароль, предназначенный для пользователя, невзломанный, поскольку пользователь может использовать тот же пароль на других сайтах, которые содержат его / ее личную информацию

Answer 1

По правде говоря, вы можете хэшировать его на внешнем интерфейсе, но это не решит основную проблему.Поскольку вы собираетесь хранить хеш для последующей проверки, хакер должен знать только то, что является хэшированным значением.Затем хакер может отправить вам хэшированное значение, и ваша система аутентифицирует его как правильное значение.По сути, вы отправляете незашифрованный пароль в систему.

Чтобы быть эффективным, передача должна быть зашифрована с помощью SSL.

На самом деле, простой способ обойти проблему хешированияпросто сыграть человека в средней атаке .Поскольку он не использует SSL, человек, использующий браузер, не может знать, что содержимое HTML не с вашего сервера.Злоумышленник может просто расположить свой код между клиентом и сервером и поместить дополнительный код в HTML-код для регистрации пароля.Размещенная информация затем отправляется злоумышленнику;он или она берет то, что нужно (в данном случае пароль), а затем пересылает информацию на ваш сервер.Ни вы, ни злоумышленник не узнаете, что вы не общаетесь друг с другом.

По этой причине вам необходимо купить сертификат из проверяемого источника.Они подтверждают, что сервер, с которым вы общаетесь, - это тот, о ком они говорят.

Связанный: Отравление DNS

Answer 2

Ваш метод кажется очень небезопасным.Но чтобы подойти к вашим вопросам ...

1. Точно так же, как это будет отправлено через SSL, только в незашифрованном виде.
2. Нет, MD5 недостаточно хорош, даже по SSL.Если вы действительно беспокоитесь о безопасности, то зачем вам выбирать взломанный алгоритм, который может быть расшифрован с помощью множества веб-сервисов онлайн (это было предметом нескольких оживленных дебатов на SO).
3. Даже если вы хэшируете пароли перед их отправкой, вы делаете эту СТОРОНУ КЛИЕНТА.Это означает, что ваш хэш и ваш алгоритм открыты и показаны каждому конечному пользователю.В результате, хорошо работающий хакер теперь точно знает, как вы отправляете пароли.

В заключение, просто получите сертификат SSL по крайней мере за 20 долларов США от GoDaddy, если хотите защитить свой сайт / текство время передачи с клиента на сервер.Зашифруйте свои пароли на стороне сервера перед сохранением в вашей БД.

Answer 3

В зависимости от того, что вы делаете, вы можете разгрузить свою аутентификацию на openid.

Answer 4

Может быть, вы можете попытаться реализовать команду APOP http://www.ietf.org/rfc/rfc1939.txt

Answer 5

Хммм,

Здесь будет работать протокол ответа на вызов.

Клиент получает страницу входа
1) Начать сеанс
2) Создать ключ сеанса
3) Отправить сеансключ в качестве цели хеширования
Пользователь входит в систему, нажимает кнопку отправки
1) Задача Javascript SHA-1 сессионного ключа + пароль SHA-1, записывает результат в поле пароля
2) Форма Jimascript subimts
3) Сервер берет SHA-1 сессионного ключа + хэш-пароль SHA-1 и сравнивает

Сессионный ключ - это то, что удерживает перехватчик от воспроизведения потока.Сервер помнит, что это было.

ОДНАКО, SHA1 пароля должен использовать соль.Простое использование имени пользователя может быть достаточно для предотвращения работы готовой радужной таблицы.Поскольку соль будет раскрыта в этом протоколе, вы не сможете полностью победить радужные столы.

РЕДАКТИРОВАТЬ: Оглядываясь назад, я ничего не прояснил.Идентификатор сессии, о котором я говорю, не является идентификатором сессии PHP.Это дополнительный идентификатор, который хранится в переменной сеанса и передается клиенту в форме.Его нужно использовать один раз для аутентификации и удалить из переменной сеанса PHP afterwords.Тем не менее, сниффер может захватить сеанс после этого момента.

Пожалуйста, имейте в виду, что весь этот вопрос - способ защитить пароль от снифферов.Его собственный сайт полностью уязвим для любого, кто может прослушивать и перехватывать сеанс, и он знает это.

ОГРОМНОЕ ПРЕДУПРЕЖДЕНИЕ ЖИРА: злоумышленник MITM может заменить код javascript чем-то другим, например, предоставить ему копиюпароль.Только SSL может защитить от этой атаки.

Answer 6

Я всегда рекомендую людям использовать SSL там, где они могут, но для полноты следует отметить, что позволяет безопасно выполнять аутентификацию без SSL посредством тщательной реализации HMAC - Hash-BasedКод аутентификации сообщения .

Вы должны быть уверены, что используете криптографически безопасный алгоритм хеширования с HMAC (я бы рекомендовал SHA-224 или лучше), и вы должны помнить, что хотя вы можете проходить аутентификацию, не раскрываяключ / пароль, таким образом, ваши данные по-прежнему должны передаваться в виде открытого текста, поэтому их нельзя использовать в качестве замены SSL для таких вещей, как транзакции по кредитным картам и т. д.