Безопасно отправить пароль обычного текста?
Я работаю над приложением для iOS, в котором пользователь будет заполнять свой пароль. Затем пароль будет отправлен на страницу PHP на моем сайте, используя POST или GET. (Он должен быть открытым текстом, потому что он используется в скрипте.)
Помимо HTTPS, есть ли способ защитить пароль? Зашифровать его в Obj-C, а затем расшифровать его в PHP?
ПРИМЕЧАНИЕ. Имя пользователя не отправляется … только пароль отправляется на сервер.
EDIT: Чтобы уточнить, Дэвид Стреттон прав … Я пытаюсь предотвратить злонамеренные снифферы в публичных местах от простого чтения текстовых паролей, поскольку они отправляются на сервер.
3 Solutions collect form web for “Безопасно отправить пароль обычного текста?”
Очерк ответа на вызов
Предположим, что у вас есть односторонняя хеш-функция abc (на практике используйте md5 или sha1
Пароль, который вы храните в своей базе данных, – abc(password + salt) (хранить salt отдельно)
Сервер генерирует случайную задачу challenge и отправляет ее клиенту (с salt ) и вычисляет ожидаемый ответ: abc(challenge + abc(password + salt))
Затем клиент вычисляет: abc(user_password + salt) и применяет challenge для получения abc(challenge + abc(user_password + salt)) , который отправляется на сервер, и сервер может легко проверить достоверность.
Это безопасно, потому что:
- Пароль никогда не отправляется открытым текстом или не сохраняется в виде открытого текста
- Значение хэша, которое отправляется, изменяется каждый раз (смягчает повторную атаку)
Есть некоторые проблемы:
Откуда вы знаете, какую соль отправить? Ну, я никогда не нашел для этого решения, но использование детерминированного алгоритма для превращения имени пользователя в соль решает эту проблему. Если алгоритм не является детерминированным, злоумышленник может определить, какое имя пользователя существует, а какие нет. Это требует, чтобы у вас было имя пользователя. Альтернативно, у вас может быть статическая соль, но я недостаточно знаю о криптографии, чтобы оценить качество этой реализации.
Пересмотреть, не используя HTTPS. HTTPS – хорошая защита от ряда атак.
Обычно нет необходимости передавать пароль. Передавая пароли, вы отправляете ценные данные, и их дополнительный риск связан с этим.
Обычно вы вводите пароль и отправляете хэш. На стороне сервера вы сравниваете хэши, если они совпадают, отлично.
Очевидно, что при таком подходе хеш важен, и вам нужно защититься от повторной атаки. Вы можете заставить ваш сервер генерировать криптозащитную одноразовую соль, передать ее клиенту, соль и хэш-пароль, а также сравнить хэш-серверы.
Вам также необходимо защититься от обратной хеш-атаки на пароль. IE, у меня есть хэш, и я могу сравнить его с кучей предварительно сгенерированных хэшей, чтобы найти исходный пароль.
Вы можете зашифровать на устройстве и расшифровать на сервере, но если данные, проходящие через провод, достаточно чувствительны, чтобы гарантировать, что много работы, тогда ИМХО, я считаю, что вам лучше использовать https. Это проверено, верно и установлено.
Это не идеально, заметьте, и были успешные атаки против более старых версий, но это чертовски намного лучше, чем «сворачивание собственного» метода безопасности.
Скажите, что ваш ключ скомпрометирован, например: если вы используете https с сертификатом от доверенного органа, то вы просто покупаете новый сертификат. HTe, если он доверяет полномочиям, примет новый сертификат. Если вы используете свой собственный маршрут, вам необходимо обновить ключи не только на вашем веб-сервере, но и у клиента. Ни в коем случае я не хочу такой головной боли.
Я не говорю, что вызов непреодолимый. Я говорю, что это может не стоить усилий, когда инструменты уже существуют.