Хеширование пароля (не-SSL)
Как пароль передается из браузера на сервер в случае передачи не по протоколу ssl?
Я хочу использовать bcrypt для хэширования пароля + соли перед отправкой .... но, похоже, нет реализации javascript для алгоритма bcrypt ...
достаточно md5, SHA-1?
PS: Мой сайт не хранит никакой личной информации пользователя. Я просто хочу, чтобы пользовательский пароль не был взломан, так как пользователь мог использовать тот же пароль на других сайтах, которые содержат его / ее личную информацию
6 ответов
По правде говоря, вы можете хэшировать его во внешнем интерфейсе, но это не решит вашу основную проблему. Поскольку вы собираетесь сохранить хэш для последующей проверки, хакеру нужно знать только его значение. Затем хакер может отправить вам хешированное значение, и ваша система проверит его как правильное значение. По сути, вы отправляете в систему незашифрованный пароль.
Чтобы передача была эффективной, она должна быть зашифрована с помощью SSL.
На самом деле, простой способ обойти проблему хеширования - просто сыграть с человеком в средней атаке . Поскольку он не использует SSL, человек, использующий браузер, не имеет возможности узнать, что HTML-контент не с вашего сервера.Злоумышленник может просто разместить свой код между клиентом и сервером и разместить дополнительный код в HTML, чтобы ввести пароль в журнал. Опубликованная информация затем переходит к злоумышленнику; он или она берет то, что требуется (в данном случае пароль), а затем пересылает информацию на ваш сервер. Ни вы, ни злоумышленник не будете знать, что вы не общаетесь друг с другом.
По этой причине вы должны покупать сертификат из проверенного источника. Они проверяют, что сервер, с которым вы общаетесь, является тем, кем они себя называют.
Связанный: Отравление DNS
Я всегда рекомендую людям использовать SSL там, где они могут, но для полноты картины следует отметить, что можно безопасно выполнить аутентификацию без SSL посредством тщательной реализации ] HMAC - код аутентификации сообщения на основе хэша .
Убедитесь, что вы используете криптографически безопасный алгоритм хеширования с HMAC (я бы предложил SHA-224 или лучше), и вы должны помнить, что, хотя вы можете пройти аутентификацию, не раскрывая ключ / пароль таким образом, ваш данные по-прежнему должны передаваться в открытом виде, поэтому их нельзя использовать в качестве замены SSL для таких операций, как транзакции по кредитным картам и т. д.
В зависимости от того, что вы делаете, вы можете перенести свою аутентификацию на openid.
Ваш метод кажется очень небезопасным. Но подойдя к вашим вопросам ...
- Точно так же, как это было бы отправлено по SSL, только в незашифрованном виде.
- Нет, MD5 недостаточно даже для SSL. Если вы действительно беспокоитесь о безопасности, то зачем вам выбирать взломанный алгоритм, который может быть расшифрован с помощью множества онлайн-сервисов (это было предметом нескольких оживленных дебатов здесь, по SO).
- Даже если вы хешируете пароли перед их отправкой, вы делаете это НА СТОРОНЕ КЛИЕНТА. Это означает, что ваш хэш и ваш алгоритм доступны и показаны каждому конечному пользователю. В результате хороший хакер теперь точно знает, как вы отправляете пароли.
В заключение, просто получите от GoDaddy сертификат SSL не менее 20 долларов, если вы хотите защитить свой сайт / текст во время передачи от клиента к серверу. Перед сохранением в БД зашифруйте свои пароли на стороне сервера.
Хммм,
Протокол ответа на запрос подойдет.
Клиент получает страницу входа в систему
1) Начать сеанс
2) Создайте сеансовый ключ
3) Отправить сеансовый ключ как хэш-цель
Пользователь входит в систему, нажимает "Отправить"
1) Задача Javascript SHA-1 сеансового ключа + SHA-1 пароля, записывает результат в поле пароля
2) Форма подзаголовков Javascript
3) Сервер берет SHA-1 сеансового ключа + хэш пароля SHA-1 и сравнивает
Сеансовый ключ - это то, что не дает перехватчику воспроизвести поток. Сервер помнит, что это было.
ОДНАКО, SHA1 пароля должен использовать соль. Простого использования имени пользователя может быть достаточно, чтобы заранее созданная радужная таблица не работала. Поскольку в этом протоколе будет отображаться соль, вы не сможете полностью победить радужные таблицы.
РЕДАКТИРОВАТЬ: Оглядываясь назад, я не прояснил одну вещь. Идентификатор сеанса, о котором я говорю, не является идентификатором сеанса PHP. Это дополнительный идентификатор, который хранится в переменной сеанса и передается клиенту в форме. Его нужно использовать один раз для аутентификации и исключить из послесловия переменной сеанса PHP. Тем не менее, после этого перехватчик может перехватить сеанс.
Имейте в виду, что весь этот вопрос - способ защитить пароль от снифферов. Его собственный сайт полностью уязвим для любого, кто может обнюхать и перехватить сеанс, и он это знает.
БОЛЬШОЕ ПРЕДУПРЕЖДЕНИЕ: злоумышленник MITM может заменить код javascript чем-то еще, например, предоставить ему копию пароля. Только SSL может защитить от этой атаки.
Возможно, вы можете попробовать реализовать команду APOP http://www.ietf.org/rfc/rfc1939.txt