Как безопасно отправить пароль зарегистрировавшемуся пользователю?

Question

[Сергей delphinpro]

Пользователь регистрируется.
Пароль ему система генерирует сама.
Пароль в открытом виде существует только на этапе регистрации.
Необходимо отправить учетные данные письмом.
Проблема в том, что отправка писем ставится в очередь и когда дело доходит до фактической отправки, открытого пароля у нас уже нет.
Что делать-то? А главное — как, в плане безопасности?

Теги хз какие ставить =)

Answer 1

[Алексей Уколов]

Странное дело - куда он девается-то? Что мешает прямо в задачу очереди его сохранить?

Ну а если вас безопасность интересует - пароль должен устанавливать пользователь, тогда он никуда и не утечёт. Если же это совершенно невозможно, то нужно всё равно генерировать не пароль, а разовую ссылку на регистрацию / подтверждение регистрации, по которой пользователь обязан установить свой пароль. В плане безопасности это мало чем отличается от генерации пароля - стащив хоть ссылку, хоть пароль, можно авторизоваться. А вот с точки зрения архитектуры будет проще реализовать сценарий и в любой момент можно отделить таких "неактивированных" пользователей.

Comments

[Денис Юрьев]

чтобы по разовой ссылке авторизоваться было сложнее - время жизни ссылки ограничить надо)
для параноиков еще привязать ее к сессии и/или айпишнику

[Алексей Уколов]

Ну да, тут уже можно накручивать какие-то механики поверх.

[Сергей delphinpro]

ну как куда? Хешируется и исчезает =)

[Алексей Уколов]

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

Answer 2

[Надим]

Пользователь САМ должен придумать пароль, а ВЫ должны хранить хеш от него, но не САМ пароль. Разумеется в целях большей безопасности НЕ нужно отправлять пароль на почту, вот совсем-вообще. Единственный тонкий момент - на этапе ввода юзером его пароля, проверяйте, чтобы юзер выбрал достаточно надежный пароль.

Comments

[FanatPHP]

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

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

[Надим]

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

[Сергей delphinpro]

Надим Закиров, FanatPHP,
Я бы тоже выбрал этот вариант, но хотят так как есть.

У меня регистрация в попапе на любой странице. Так что там счетчики всегда есть.

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

[FanatPHP]

Ссылка уникальная одноразовая, такая же, как при сбросе пароля.

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