Зачастую, одно из первых архитектурных решений, принятых в начале разработки вашего сайта — будет использование email + password для авторизации пользователя. Эта связка прочно засела в наши головы, и мы уже на задумываемся, зачем мы заставляем людей придумывать пароль. Мы привыкли так делать.
Но давайте подумаем, возможно, вашим пользователям не нужны пароли.
Одно из возможных решений, это использовать OAuth 2.0, но не у всех пользователей может быть аккаунт в социальной сети и желание его использовать на вашем ресурсе.
Но как-же тогда избавиться от пароля? На этот вопрос, я и попробую ответить в статье.
Единственный защищенный пароль — это тот, который вы не в силах запомнить.
Troy Hunt
Сам по себе пароль уже является проблемой. Он не выгоден, ни вам, ни вашим пользователям.
Для владельца сайта пароль не выгоден тем, что его хранение создает дополнительную уязвимость в системе. Каким бы сильным ни был ваш хеширующий алгоритм (и упаси вас господь, не использовать его) рано или поздно он станет пустяком для новых GPU, а в последствии и CPU. А если ваша база данных утечет в сеть, то это нанесет колоссальный удар по вам и вашим посетителям. Без паролей же база становится в разы менее лакомой добычей.
Для посетителей вашего сайта, пароль — это дополнительные трудности. Неопытные пользователи будут лишний раз использовать свой "обычный" пароль, повышая риск потерять его. А продвинутые пользователи будут вынуждены придумывать специальный пароль для вашего сайта или пользоваться менеджером паролей.
Сам по себе феномен менеджеров паролей, это уже костыль, который должен нам был показать всю не востребованность и неэффективность повсеместного использования паролей.
Помимо этого, вы можете дополнительно отравить жизнь вашим пользователям, заставив их периодически менять их, или запретить / заставить использовать специальные символы.
Ответ — не использовать пароли. Вам достаточно знать только email пользователя.
При регистрации на сайте, вы так или иначе завязаны на пользовательской почте. Вы высылаете на нее письма с подтверждением, что пользователь является владельцем аккаунта; вы используете его для сброса пароля.
Сброс пароля уже звучит как оксюмороном. Ведь для того, чтобы задать новый пароль достаточно лишь получить письмо на email. Все. Так и зачем же вы заставляли пользователя придумывать пароль, менять его и использовать только угодные вам символы?
Ведь чтобы авторизовать пользователя, вам достаточно выслать ему на почту письмо со сгенерированной ссылкой, как при подтверждении аккаунта. Этого хватит чтобы авторизовать пользователя.
Да и современные email сервисы в разы более защищены и подготовлены к атакам, чем регулярный сайт с котиками. Доверьте хранение и защиту пароля профессионалам.
Рассмотрим пример простого сайта с PostgreSQL в качестве базы данных.
Нам будет достаточно двух таблиц (с минимальным набором полей):
users:
Имя поля | Тип данных | Атрибуты |
---|---|---|
id | serial |
PRIMARY KEY |
varchar(320) |
UNIQUE |
sign_in_requests:
Имя поля | Тип данных | Атрибуты |
---|---|---|
id | serial |
PRIMARY KEY |
varchar(320) |
||
token | uuid |
UNIQUE |
request_ip | varchar(45) |
|
activated_at | timestamp |
NULLABLE |
expired_at | timestamp |
Несколько комментариев на счет таблиц:
Процесс авторизации весьма прост:
https://example.com/signin/callback/email/{{token}}
.activated_at=now()
, чтобы предотвратить множественное использование токена.В качестве защиты от спама письмами, можно сделать рейт лимит, или не высылать письмо чаще чем раз в 10 минут.
Кому стоит использовать данную технику:
И не стоит использовать данную технику:
Хотя, идея с отказом от пароля выглядит дико и непривычно, на первый взгляд, взамен она может дать ряд преимуществ, и облегчить жизнь вам и вашим пользователям.
Источник изображения: https://pixabay.com/en/padlock-grunge-rusty-rusting-76866/
К сожалению, не доступен сервер mySQL