Есть ли безопасный способ отправить пользователю его пароль в виде открытого текста по электронной почте? - PullRequest
4 голосов
/ 25 февраля 2012

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

Есть ли обходное решение для этой проблемы?

Как можно сделать отправку пользователю его пароля по электронной почте максимально безопасной?

Ответы [ 7 ]

3 голосов
/ 26 февраля 2012

Простой ответ: не надо. Если вы считаете, что ваша база данных небезопасна, электронная почта намного, намного меньше.

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

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

Возможно, вы захотите рассмотреть хороший алгоритм хеширования, например BCrypt , который включает соль.

1 голос
/ 26 февраля 2012

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

0 голосов
/ 03 февраля 2015

Существует обходной путь, который менее безопасен, чем сброс пароля, но работает, если требуется, чтобы пользователи отправляли пароль, а не ссылку для сброса.

Что вы делаете, вы генерируете новый пароль, которыйсодержит достаточно случайности, чтобы ее было трудно угадать, но она также отформатирована таким образом, чтобы ее было легко запомнить и прочитать (скажем, по телефону).

Что-то вроде: xyz - xyz - xyz - nnnn , где xyz - простое, но необычное слово и nnnn - это четырехзначное число.

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

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

Уважаемый Фамилия, Фамилия,

Вы просили, чтобы мы сбросили вашпароль.

Ваш новый пароль:
insipid-mirth-nonplus-9174

Вы сможете войти в систему один раз, используя этот пароль, затем вам нужно будет ввести новый пароль.

Важные предупреждения

Эта система имеет ряд серьезных уязвимостей, которые делают ее непригодной для веб-сайтов, где безопасность данных имеет решающее значение.Их больше, но я знаю, о которых я могу думать:

  1. В отличие от систем, в которых используется ссылка для сброса пароля, эту систему можно использовать для блокировки кого-либо из системы (при условии, чтоВы используете его как есть), если только вы не потребуете от кого-то заполнить идентифицируемую информацию перед выполнением сброса пароля или отправите сообщение «Вы уверены, что хотите сбросить пароль?»сначала электронная почтаЭто будет означать, что они нажимают на ссылку с GUID, которая идет на сервер;в этот момент их также можно отправить в форму для сброса пароля.
  2. Поскольку пароль отправляется в виде простого текста по электронной почте, существует опасность его перехвата и использования пароля.Хотя, честно говоря, это не сильно отличается от риска отправки ссылки для сброса пароля.
  3. Если вы игнорируете риски на шаге № 1 и не используете достаточно случайный способ генерации паролей (скажем,вы используете список слов, состоящий из менее чем 1000 элементов), кто-нибудь, взломавший ваш сервер, сможет получить хэш с посоленным паролем, а затем написать алгоритм, который генерирует все возможные пароли и проверяет их на соответствие хешированному паролю.Не такая большая проблема, если вы используете криптографически сложный алгоритм хеширования.
0 голосов
/ 26 февраля 2012

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

Просто вам придется пойти по какому-то простому пути ....

1. Вам придется принять этот пароль как переменную, которая отправитот пользователя.2. Когда вы сохраняете базу данных, просто конвертируйте ее по своему усмотрению.3. Но когда вы отправляете их пользователю по почте, в этот раз просто прислали эти переменные пароли ...

Я думаю, будет полезно построить ваше представление о ПУТИ .......

0 голосов
/ 26 февраля 2012

Да, есть общий обходной путь.

Предполагая, что у вас есть пользователи в вашей базе данных.

Вы отправляете «ссылку для сброса пароля», содержащую некоторую «ключевую» информацию, например, guid.Примером ссылки является форма:

http://your.site.com/setpassword?id=5b070092-4be8-4f4d-9952-1b915837d10f

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

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

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

0 голосов
/ 26 февраля 2012

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

Таким образом, не существует безопасного способа безопасной отправки пароля в виде открытого текста.

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

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

0 голосов
/ 26 февраля 2012

Вы должны хешировать все пароли в своей базе данных.

sha1($_POST['password'].$salt.$username);

В случае утери пароля

Пользователь запрашивает ссылку для сброса пароля, которая содержит хэш, сгенерированный втаблица "user_meta".Когда пользователь получает эту ссылку, хэш сравнивается с хешем в базе данных, и пользователь сможет ОБНОВИТЬ свой текущий пароль с новым паролем.

PTXT пароля: никогда не раскрывается.

Вы сравниваете только хэши.

...