Безопасный сброс пароля без отправки по электронной почте

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

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

Любой вход был бы оценен.

Обновить:
Сделав попытку OpenID и вспомнив, что этот сервер не разрешает PHP (и, таким образом, cURL) делать какие-либо внешние запросы, я снова пытался отправить почту с PHP. По-видимому, все мои предыдущие ужасные события с mail () на этом сервере ушли.

Спасибо за все ваши данные, я могу снова взглянуть на OpenID в будущем.

Punt по проблеме с паролем. Переключитесь на OpenID. Вам не нужно беспокоиться о сбросе пароля, и пользователю нужен только новый пароль, если он того пожелает.

это беспроигрышный.

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

Действительно, единственно разумно безопасными альтернативами являются те, которые используют подобный метод. Отправьте электронное письмо, sms-сообщение, на которое они должны ответить, автоматический телефонный звонок, где они должны пробивать цифры и т. Д.

Единственный метод, который я могу думать о том, что не использует эту систему, будет вопросом безопасности. Банки часто используют их для дополнительной проверки, когда пользователи регистрируются или не могут правильно регистрироваться несколько раз. Иногда они также используются как «секретный» код для получения пароля, но даже тогда он обычно отправляется по электронной почте пользователю, а не отображается на странице.

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

Тем не менее, вы можете использовать схему «секретного вопроса», чтобы позволить кому-то сбросить свой пароль. Когда этот человек создает свою учетную запись, вам нужно уловить секретный вопрос и ответ. Затем вы запрашиваете у пользователя этот вопрос и разрешаете только сбрасывать, если они отвечают правильно.

Я должен предупредить вас, что это не очень хороший способ защиты своего пароля от несанкционированного доступа. Для хорошей статьи читайте: http://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html

У вас нет способа узнать, кто пытается сбросить пароль «Джо». Это может быть Джо, или может быть кто-то, как Джо.

Альтернативой отправке электронной почты является либо вызов одного из телефонов Джо с помощью однократного сбросного ключа, либо отправка SMS-сообщения.

Вызов телефона Джо с аудио-сообщением легко с http://www.twilio.com/. Но любой человек может забрать офисный телефон Джо. Таким образом, вы обычно хотите получить дополнительную возможность перед вызовом. Например, секретный вопрос / ответ. Используя телефон и секретный q & a, вы сделали вещи более жесткими для плохих парней, но все же выполнимыми Джо.

Другая идея – отправить сообщение сброса кому-то, кому доверяет Джо и кто знает Джо. (Отправить по электронной почте или по телефону / смс.) Вариант этого заключается в том, чтобы отправить сотруднику, который знает Джо, например, его назначенный salesrep, HR rep и т. Д.

Используйте сообщение: отправьте письмо с уличной почтой с кодом возврата в нем. Потребуется пару дней, чтобы добраться туда, но кража почты – это федеральный рэп. См. http://www.postalmethods.com/ Если есть очень плохие возможные отрицательные результаты, это может быть хорошим решением.

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

Другой пример – потребовать от Джо позвонить в справочную службу и позволить человеку допросить его.

Суть в том, что никакая техника не идеальна. См. Рассказ об истории твиттера: http://www.technewsworld.com/story/67612.html?wlc=1247790901&wlc=1248238327

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