Надежно отправить пароль в виде простого текста?

Question

Я работаю над приложением для iOS, в котором пользователь должен будет ввести свой пароль. Затем пароль будет опубликован на странице PHP на моем сайте с помощью POST или GET. (Он должен быть открытым текстом, потому что он используется в скрипте.)

Кроме HTTPS, есть ли способ защитить пароль? Зашифровать его в Obj-C, а затем расшифровать в PHP?

ПРИМЕЧАНИЕ. Имя пользователя не отправляется ... на сервер отправляется только пароль.

EDIT: Чтобы уточнить, Дэвид Стрэттон прав: я пытаюсь не допустить, чтобы злоумышленники в общественных местах просто читали пароли в виде открытого текста, когда они отправлялись на сервер.

Answer 1

План ответа на вызов

Предположим, у вас есть однонаправленная хеш-функция abc (на практике используйте md5 или sha1 криптографически сильный алгоритм хеширования для PHP, см. password_hash ).

Пароль, который вы храните в своей базе данных: abc(password + salt) (храните salt отдельно)

Сервер генерирует случайный запрос challenge и отправляет его клиенту (с salt) и рассчитывает ожидаемый ответ: abc(challenge + abc(password + salt))

Затем клиент вычисляет: abc(user_password + salt) и применяет challenge для получения abc(challenge + abc(user_password + salt)), которое отправляется на сервер, и сервер может легко проверить правильность.

Это безопасно, потому что:

• Пароль никогда не отправляется в виде открытого текста или хранится в виде открытого текста
• Отправляемое хэш-значение изменяется каждый раз (смягчает атаку воспроизведения)

Есть некоторые проблемы:

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

Answer 2

Пересмотреть, не используя HTTPS. HTTPS хорошая защита от ряда атак.

Обычно нет причин для передачи пароля. Передавая пароли, вы отправляете ценные данные, и с ними связан дополнительный риск.

Обычно вы хэшируете пароль и отправляете хеш. На стороне сервера вы сравниваете хэши, если они совпадают, отлично.

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

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

Answer 3

Вы можете зашифровать на устройстве и расшифровать на сервере, но если данные, передаваемые по проводам, достаточно чувствительны, чтобы оправдать такую ​​большую работу, то ИМХО, я полагаю, вам лучше использовать только https.Это проверено, правда и установлено.

Он не идеален, имейте в виду, и были успешные атаки на его старые версии, но это намного лучше, чем "накатывать свой" метод безопасности.

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

Я не говорю, что проблема непреодолима.Я говорю, что это может не стоить усилий, когда инструменты уже существуют.