Безопасный вход в систему: шифрование с открытым ключом в PHP и Javascript - PullRequest
6 голосов
/ 07 октября 2009

Я пытаюсь сделать «обычную» форму входа в систему с именем пользователя и паролем безопасной, без использования HTTPS. Моя идея такова:

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

Что мне нужно знать для этого:

  • Какой метод шифрования лучше всего использовать? RSA
  • Как мне расшифровать пароль в PHP?
  • И, возможно, самый сложный вопрос, как я могу заставить Javascript зашифровать пароль?

Ответы [ 7 ]

17 голосов
/ 07 октября 2009

Заранее: извините за негатив, однако;

Реализация собственного протокола безопасности - никогда - хорошая идея, если вы не высококвалифицированный специалист по безопасности, или вы на самом деле не заботитесь о безопасности и хотите создать только впечатление безопасности (маркетинг) и остановить сценарий детишек.

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

Другой момент заключается в том, что люди часто забывают упомянуть, чего они хотят достичь. Безопасность имеет три знаменитых компонента, называемых CIA, а именно: конфиденциальность, целостность и доступность. Для вас важно, чтобы данные, которые вы транспортируете, были конфиденциальными, или важна целостность (т. Е. Вы уверены, что отправленные данные получены именно от того, кого вы ожидаете, а не от человека посередине)?

Чтобы конкретизировать в этом случае, единственное, чего вы добиваетесь здесь, это то, что пассивный злоумышленник не может видеть, что проходит по линии. Как только ваш злоумышленник становится активным и меняет сообщения на своем маршруте, вся ваша безопасность рушится. Поэтому мой совет - просто придерживаться решения, предложенного экспертами (в данном случае TLS, а не ssl, поскольку это старая версия), и просто убедиться, что ваш сервер его поддерживает.

редактирование:

Кстати, SSL / TLS не может работать без сертификатов. Весь смысл криптографии с открытым ключом состоит в том, что должна быть хоть какая-то доверенная сторона.

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

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

edit2: после комментариев

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

Если я, будучи мошенником, провожу атаку «человек посередине», я могу создать самозаверяющий сертификат без уведомления пользователя. Таким образом, преимущество использования TLS с самозаверяющими сертификатами состоит в том, что у вас есть, по крайней мере, реализация протокола corrent (и даже реализовать это далеко не просто). Более того, вы можете избежать уродливых предупреждений, посоветовав своим пользователям один раз доверять сертификату вручную. Однако это возможно только в том случае, если у вас относительно небольшая группа постоянных посетителей, для общедоступного веб-сайта это не совсем решение.

10 голосов
/ 07 октября 2009

Это не кажется безопасным с точки зрения клиента. Две (связанные) проблемы:

  1. Как клиент доверяет серверу? Как он может убедиться, что ключ, который представляет сервер, принадлежит ему?
  2. Можно проводить атаки «человек посередине». Вредоносный прокси-сервер может удалить и сохранить открытый ключ до того, как его увидит клиент, подставив свой собственный, а затем расшифровать пароль, когда клиент проверяет подлинность, сохраняет его, повторно шифрует и отправляет ответ, чтобы клиент не понял, что с ним что-то не так.

Что не так с обычным SSL? Должен быть консенсус, что это безопасно, иначе поставщики и организации откажутся от поддержки в одночасье. В отличие от этого, большинство попыток изобрести необычный новый способ обеспечения безопасности «по дешевке» обычно пропускают нечто фундаментальное.

3 голосов
/ 07 октября 2009

Похоже, многое из того, что вы хотите сделать, предоставляется плагином jquery JCryption . Он даже предполагает PHP в качестве бэкэнда, так что он вам подойдет.

1 голос
/ 07 октября 2009

Livejournal делает нечто похожее на то, что вы хотите, где:

  1. Сервер генерирует строку запроса, вставляет ее в форму. [ 1 ]
  2. Клиент генерирует ответ путем хеширования MD5 пароля, затем MD5 хэширует предыдущий хеш с добавлением запроса [ 2 ].
  3. Сервер получает ответ, проверяет правильность запроса, затем делает то же, что и шаг 2, сравнивая результат с ответом.
0 голосов
/ 05 апреля 2014

Храня пароли в зашифрованном виде на сервере, сервер может получить пароли и проверить контрольную сумму, отправленную клиентом. Отправьте пароль сеанса и попросите клиента создать хэш пароля сеанса и введенного пользователем пароля, сделайте то же самое на сервере и сравните два хеша.

Это не защитит пользователей от атак MITM - локальных администраторов, АНБ, телекоммуникаций, перехватчиков маршрутизаторов, но сохранит пароль в открытом доступе.

0 голосов
/ 07 октября 2009

jCryption выглядит интересно, я раньше такого не видел.

Но я должен спросить, что не так с SSL?

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

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

0 голосов
/ 07 октября 2009

Это очень хорошая идея, и она уже сделана. См. jCryption .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...