Как передать пароль при регистрации (PHP и SQL)

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

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

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

Есть ли простой способ как-то зашифровать его на стороне клиента и расшифровать на стороне сервера? Или, возможно, отправить его кусками с задержками и фиктивными пакетами.

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

  • При входе запрашивается соль для вызова, и клиент хэширует пароль перед его отправкой
    hash(hash(password). salt).
  • Для сохранения сеанса у клиента должен быть актуальный токен-ключ, а также браузер и IP-адрес, идентичные тем, которые создали сеанс.
  • Естественно, все пользовательские вводы и ответы ajax проверяются перед запросом.

authentication php sql passwords registration
person Oliver    schedule 24.05.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

На самом деле есть один правильный ответ: используйте HTTPS. SSL через HTTP — единственное решение, которое полностью защитит это.

Вы не можете выполнить здесь проверку javascript, потому что соль будет раскрыта. Что не является правильным подходом.

person Amir Raminfar    schedule 24.05.2011
comment
SSL - это боль, потому что намерение состоит в том, чтобы реализовать это в CMS; поэтому код будет на клиентском сервере, поэтому у них не будет статического IP-адреса и сертификата. Думаю, я мог бы направить регистрацию через свой сервер. - person Oliver; 25.05.2011
comment
@Oliver, тогда их сайт в любом случае никогда не будет таким безопасным, поскольку без HTTPS каждый раз, когда люди входят в систему, их учетные данные будут отправляться по сети в незашифрованном виде, и они будут отправлять свои аутентифицированные идентификаторы сеанса в незашифрованных файлах cookie с каждым запросом на сервер. Так зачем делать большое дело о регистрации? - person Mark Snidovich; 25.05.2011
comment
Я думаю, что любой ключ шифрования, используемый javascript, может быть раскрыт при просмотре источника. - person Oliver; 25.05.2011
comment
Аутентифицированные сеансы @Mark также связаны с изменяющимся ключом токена, поэтому вам нужно будет поймать идентификатор сеанса и токен и сделать запрос, прежде чем реальный пользователь что-либо сделает, а также узнать IP-адрес и браузер реального пользователя. И когда реальный пользователь пытается что-то сделать после захвата сеанса, он уничтожает сеанс. - person Oliver; 25.05.2011
comment
@Oliver Отлично, помогает частая регенерация сеанса. Под «ключом токена», я думаю, вы имеете в виду идентификатор сеанса или вы имеете в виду токен CSRF? Отсутствие HTTPS при входе по-прежнему является проблемой. Что бы вы ни делали для регистрации, обязательно сделайте это и для нее, верно? - person Mark Snidovich; 25.05.2011
comment
@Oliver: вам не нужен статический IP-адрес для SSL. Все, что вам нужно, это веб-сервер и домен. Сертификат SSL подтверждает, что ДОМЕННОЕ ИМЯ, к которому вы подключаетесь, не лжет. IP-адрес может меняться при каждом запросе, но пока имя сертификата и адрес в URL-адресе совпадают, все в порядке. - person Marc B; 25.05.2011
comment
@Mark Должен был упомянуть, что я не использую сеансы php, я полностью использую свою собственную систему. Сеансы имеют простой увеличивающийся идентификатор, а затем привязанный к нему токен. Токен просто создается с помощью hash('sha256', mt_rand()). Во время входа клиент отправляет имя пользователя, а сервер отвечает солью (сделанной так же, как токен). Затем клиент отправляет хэш ( хэш (пароль) . соль ), поэтому сбор соли не очень поможет. Насколько я вижу, вход в систему довольно безопасен. - person Oliver; 25.05.2011
comment
@Marc B: Единственная проблема в том, что он генерирует предупреждающие сообщения в большинстве браузеров. Chrome пытается убедить меня, что моя веб-почта убьет меня. Но если это только для регистрации, это еще не все. - person Oliver; 25.05.2011
comment
@Oliver: Какие предупреждения? Существует множество сайтов с несколькими IP-адресами и одним сертификатом ssl без каких-либо предупреждений (например, amazon.com). - person Marc B; 25.05.2011
comment
@Марк Б: Хм. У меня сложилось впечатление, что для получения проверенного SSL-сертификата вам нужен статический IP-адрес, к которому проверяющая компания может его привязать. И если вы используете сертификат, который никем не проверен (например, Verisign), то браузер будет выдавать предупреждения. - person Oliver; 25.05.2011
comment
@Oliver: предупреждение о самозаверяющем сертификате не имеет ничего общего с IP-адресами. Это просто означает, что браузеры не распознают Acme Certs-R-Us как действительный ЦС. Чтобы получить сертификат SSL, вам просто нужно подтвердить, что домен, для которого вы его выдаете, действительно является вашим доменом. но нигде в процессе подачи заявки на сертификат не говорится, что example.com - это 127.0.0.1. - person Marc B; 25.05.2011
comment
@Marc B: Хорошо, спасибо, что прояснили это. Но можете ли вы использовать SSL на общем веб-сервере? У меня есть дешевый общий веб-хост, и поиск в их разделе поддержки предполагает, что вы не сможете использовать SSL, пока не заплатите за подписанный сертификат. и статический IP. - person Oliver; 25.05.2011
comment
Статический против. динамические IP не имеют значения. Но совместное использование одного IP-адреса несколькими доменами SSL проблематично. Некоторые веб-серверы (и веб-хосты) вообще не поддерживают его. TLS решает проблему (1 IP = несколько доменов ssl), но на хостах старой школы, поддерживающих только SSL, действует правило: 1 IP = только 1 домен SSL. - person Marc B; 25.05.2011
comment
Итак, вернемся к исходному вопросу. Нет практического способа безопасно отправить пароль во время регистрации, кроме как через SSL. Можно ли что-то сделать, чтобы хотя бы затруднить захват? - person Oliver; 25.05.2011
comment
Для любого используемого шифрования потребуется либо статический ключ, который можно было бы легко раскрыть, либо динамический ключ, который можно было бы раскрыть при перехвате пакетов. Это означает, что пароль или хэш могут быть обнаружены. Есть ли какая-то польза от шифрования пароля, если и ключ, и метод могут быть легко обнаружены? - person Oliver; 25.05.2011

arrow_upward
1
arrow_downward

Есть ли простой способ как-то зашифровать его на стороне клиента и расшифровать на стороне сервера?

Как насчет использования HTTPS?

person Mark Snidovich    schedule 24.05.2011