Пусть дергает. Это лучше, чем потеря критических данных.
Очень спорное высказывание, т.к. зависит от множества факторов.
А иначе вам как-то придется бороться со слабыми паролями.
А зачем, пользователь все равно найдет как его "подарить".
Мне кажется, мы с вами уже уперлись в тупик обсуждения. Мне абсолютна ясна ваша позиция, и я надеюсь, что вы хотя бы допускаете, что моя теория имеет место быть.
Во всяком случае, мне было очень приятно с вами подискутировать, и обсудить возможные недостатки предложенной выше системы.
Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.
А практика с "ваш пароль недостаточна сильный", я считаю одним из проявлений садизма.
Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.
Но эта проблема проста для программистов и серьезных пользователей. А вот подавляющее большинство использует незамысловатые комбинации, и, вероятно, используют один пароль везде. И вот в этом случае, безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты, и хотябы.
Но оба подхода не спасут ни от стикера на мониторе, ни от masha123456.
Что вы понимаете под менеджментом пароля для почты? Я говорил о программах-менеджерах, которые генерируют и хранят ваши пароли от учетных записей.
А пароль от почты, да, его действительно нужно хранить очень и очень сильно, независимо ни от чего. Т.к. в текущем положении дел, он является мастер паролем (из-за возможности сбросить пароль учетной записи на сайтах, зарегистрированных на эту почту).
В целом, никто не мешает слать временны пароль на почту пользователю. Но тогда TTL такого запроса должна стать в разы короче, либо нужно будет сделать лимит на попытки ввода токена.
Да тоже самое получаем, timeout работает по принципу "когда нибудь, но только не сейчас", т.е. если вы даже напишите -500, он сработает не раньше чем через один тик (зависит от браузера, но если не изменяет память минимальный таймаут 5-10мс).
Оу, если речь шла, что ваш сервис начал поддерживать ES2017, тогда прошу прощения. Я прочел по-горизонтали и подумал, что это очередное водолейство на тему "Breaking news: появились промисы"
Очень спорное высказывание, т.к. зависит от множества факторов.
А зачем, пользователь все равно найдет как его "подарить".
Мне кажется, мы с вами уже уперлись в тупик обсуждения. Мне абсолютна ясна ваша позиция, и я надеюсь, что вы хотя бы допускаете, что моя теория имеет место быть.
Во всяком случае, мне было очень приятно с вами подискутировать, и обсудить возможные недостатки предложенной выше системы.
Если вы не против, продолжим завтра.
А пока, хорошего воскресения, и добрых снов :).
Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.
А практика с "ваш пароль недостаточна сильный", я считаю одним из проявлений садизма.
Ну раз мы рассматриваем такого пользователя, давайте уж будем честны, он использует свою реальную (единственную) почту. Тут уже никто не поможет.
Да я и не думаю так, но так есть хоть какая-то надежда обезопасить такого гражданина.
Да я все, про описанную систему выше говорю.
Да, но не большая, чем зайти даже с временной почтой и паролем.
А временные пароли по СМС / Google Authenticator / прочие 2fa могут решить эту проблему с почтой.
Да и не припомню, чтобы за последние пару лет мне хотелось авторизоваться в блоге с чужого компьютера.
Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.
Но эта проблема проста для программистов и серьезных пользователей. А вот подавляющее большинство использует незамысловатые комбинации, и, вероятно, используют один пароль везде. И вот в этом случае, безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты, и хотябы.
Но оба подхода не спасут ни от стикера на мониторе, ни от
masha123456.Почта протухнет, следовательно вы не сможете выслать на нее письмо с ссылкой на вход. Считайте, потеряли аккаунт. Разве что в саппорт писать.
А чем, помимо возможности использования одноразовых email, этот вариант менее безопасный?
Что вы понимаете под менеджментом пароля для почты? Я говорил о программах-менеджерах, которые генерируют и хранят ваши пароли от учетных записей.
А пароль от почты, да, его действительно нужно хранить очень и очень сильно, независимо ни от чего. Т.к. в текущем положении дел, он является мастер паролем (из-за возможности сбросить пароль учетной записи на сайтах, зарегистрированных на эту почту).
"Почему" потеряете доступ? Я не совсем понял этот вопрос.
Я предлагаю его как одну из альтернатив, дабы избавить пользователя от огромного количества паролей.
Ради отказа от бесконечного количества паролей и их менеджеров. Просто другой путь.
Согласен, если вы намерены использовать этот аккаунт долгое время, то потеря доступа к email, повлечет и потерю аккаунта.
С другой же стороны, использовать временную почту для важных учеток — не очень хорошая идея.
Бесспорно, этот путь длиннее. Но если на сайте достаточно длинные сессии, то, думаю, это может нивелировать данный минус.
А что мешает использовать одноразовый Email в этой схеме?
Но перед тем, как зайти через SSO вы ведь должны ввести email + pass. Конечно, если ваш почтовый сервис, это уже SSO, то да, вопрос отпадает.
Некоторые сервисы не пустят вас, пока вы не подтвердите email. Следовательно, не войдя в него, вы не сможете этого сделать.
А разве входя через email + password, вы не светите email?
В целом, никто не мешает слать временны пароль на почту пользователю. Но тогда TTL такого запроса должна стать в разы короче, либо нужно будет сделать лимит на попытки ввода токена.
А СМС, да они в разы дороже, чем отправка письма.
А на них и так вся ответственность. Если у вас предусмотрен сброс пароля, считайте у вас и нет нужды в нем.
Да тоже самое получаем, timeout работает по принципу "когда нибудь, но только не сейчас", т.е. если вы даже напишите
-500, он сработает не раньше чем через один тик (зависит от браузера, но если не изменяет память минимальный таймаут 5-10мс).Оу, если речь шла, что ваш сервис начал поддерживать ES2017, тогда прошу прощения. Я прочел по-горизонтали и подумал, что это очередное водолейство на тему "Breaking news: появились промисы"