Как обезопасить процесс регистрации, если нет ssl

Question

Я создаю страницу регистрации для пользователя, чтобы зарегистрироваться в качестве члена, и мне интересно, как сохранить пароль пользователя в безопасности, если у меня нет ssl-сервера.

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

Это хорошая идея? Любое хорошее предложение? У меня есть другой вариант?

Большое спасибо за любую хорошую идею.

Answer 1

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

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

Посмотрите на http://www.jcryption.org,, он может делать то, что вы хотите.

Answer 2

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

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

Это, конечно, зависит от наличия на сервере хешированного пароля, из которого можно создать сравнительное значение.И это определенно нет-нет.

Итак ... вы храните пароль, хешированный известной солью (S1) на сервере.Когда кто-то хочет войти в систему, вы отправляете ему идентификатор сеанса (S2) и S1, и они отправляют обратно:

md5(S2 . md5(S1 .password));

Существуют реализации JavaScript md5.

Md5 приближается к концу полезностикак надежный шифр - однако для указанных здесь куколок это должно быть достаточно.

Answer 3

Вы должны использовать SSL (остальное НЕ так безопасно) для аутентификации, и, к счастью, вы можете использовать OpenID с открытым исходным кодом, как это делает stackoverflow.com. Например, вы можете прочитать, почему Stackoverflow.com перешел на OpenID, прочитав эту статью (хорошее чтение).

Существует очень удобная библиотека OpenID, доступная от LightOpenID. Я создал небольшую библиотеку «Openid для PHP с удобным для пользователя способом выбора OpenID благодаря openid-selector и LightOpenID», доступную по адресу github . Я также разместил демо на своем веб-хостинге по адресу http://westerveld.name/php-openid/

Answer 4

Открытые ключи Центров сертификации (ЦС), хранящиеся в веб-браузере, - это единственное, что предотвращает уязвимость SSL / TSL для человека в середине атаки. Таким образом, нет способа защитить эти решения.
Все эти решения уязвимы для человека в средней атаке.

Обратите внимание, что Мэллори (активный злоумышленник) может заменить свой открытый ключ на странице.

Answer 5

Реальным решением этой проблемы является использование реального соединения SSL / HTTPS.

Обоснование:

• Если контент, доступный после входа в систему, стоит защитить, весьсеанс должен быть защищен, а не только пароль пользователя.
• Если содержимое не стоит защищать, зачем вообще входить в систему?

Обратите внимание, что вам не нужно использовать платный SSLсертификат для получения преимуществ SSL.Вы можете подписать свою собственную (см. http://www.debian -administration.org / article / 284 для примера).Однако в последних версиях Firefox использование самозаверяющих сертификатов стало проблемой, если пользователь не готов установить вас в качестве CA.(По какой-то странной логике Firefox отображает гораздо менее тревожный диалог для добавления нового CA, чем добавление исключения для отдельного сервера, который использует самозаверяющий сертификат. Это очень плохо, потому что принятие нового CA принимает все сертификаты , которые будутбыть подписанным этим CA в будущем!)

Однако, если вы настаиваете на том, чтобы не использовать настоящий SSL, вы можете реализовать шифрование с помощью JavaScript: http://www.hanewin.net/encrypt/ или http://www.jcryption.org/ - будьте предупрежденыхотя это требует большой работы, и конечный результат может оказаться почти таким же защищенным, как SSL, если его правильно реализовать в каждой мелочи .Конечный результат никогда не будет таким безопасным, как SSL , потому что вы должны передать JS-скрипт в пользовательский агент посетителя (браузер) без шифрования, и в результате посетитель может в конечном итоге запустить JavaScript, выбранный злоумышленником.(злоумышленник может выполнить атаку «Человек посередине», поскольку в противном случае вам также не понадобится защита пароля пользователя).

Answer 6

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

Распространенным способом является получение пароля и отправка только хэша.

Я предлагаю вам передать "соль" со стороны сервера в форму и хешировать пароль и соль вместе, чтобы сделать ее более случайной.

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