Открыть список
Как стать автором
Обновить

Комментарии 500

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

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

Если у вас предусмотрен сброс пароля, считайте у вас и нет нужды в нем.

Сброс пароля бывает не только через почту.


А еще есть разница между "открыть сайт, нажать кнопку ввода пароля, войти" и "открыть сайт, нажать кнопку, пойти в почту, нажать ссылку, войти".

Бесспорно, этот путь длиннее. Но если на сайте достаточно длинные сессии, то, думаю, это может нивелировать данный минус.

Но если на сайте достаточно длинные сессии, то, думаю, это может нивелировать данный минус.

Не может. Все равно необоснованно много операций ради чего?

Ради отказа от бесконечного количества паролей и их менеджеров. Просто другой путь.

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

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


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

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

Вот про это я и говорю. Пароль от почты же тоже надо где-то хранить; особенно учитывая, что это не единственный пароль, который надо хранить. Так что менеджер все равно нужен. А если он есть, то уже не важно, сколько паролей хранить.

Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.


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


Но оба подхода не спасут ни от стикера на мониторе, ни от masha123456.

Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.

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


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

А почему вы думаете, что у такого пользователя будет сильный пароль на почту?

А почему вы думаете, что у такого пользователя будет сильный пароль на почту?

Да я и не думаю так, но так есть хоть какая-то надежда обезопасить такого гражданина.

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

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

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

Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.


А практика с "ваш пароль недостаточна сильный", я считаю одним из проявлений садизма.

Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.

Пусть дергает. Это лучше, чем потеря критических данных.


А практика с "ваш пароль недостаточна сильный", я считаю одним из проявления садизма.

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


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

Пусть дергает. Это лучше, чем потеря критических данных.

Очень спорное высказывание, т.к. зависит от множества факторов.


А иначе вам как-то придется бороться со слабыми паролями.

А зачем, пользователь все равно найдет как его "подарить".


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


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


Если вы не против, продолжим завтра.


А пока, хорошего воскресения, и добрых снов :).

А иначе вам как-то придется бороться со слабыми паролями.
А зачем, пользователь все равно найдет как его "подарить".

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

Очень спорное высказывание, т.к. зависит от множества факторов.

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


А зачем, пользователь все равно найдет как его "подарить".

Чтобы избежать тривиальных ошибок.

Пусть дергает. Это лучше, чем потеря критических данных.

Да, помню эту историю.


Чувак потом рассказывал что он потерял фотографии своей дочки из-за того что кто-то сумел уболтать саппорт и получить доступ к его эпловой учётке.

Хочется верить, что с таким подходом и пользователям искренне пофиг на вас и наш сервис, чего бы вы там ни предоставляли.
Пользователям у которых много разных email аккаунтов всё равно придется запоминать или записывать связку url -> email. Конечно это проще чем url -> email / password, но все равно менеджер может еще понадобится.
Возможно, это сократит колличество паролей. Но Вы, видимо, подразумеваете, что почтовый клиент у пользователя забирает почту без необходимости ввода пароля. Если же нет, то человеку нужно будет пройти дополнительные шаги авторизации в почте.
Если же ориентироваться на длинную сессию в почте, то такой же подход можно применить и на сайте.
У нас на одном из сервисов сессия сохраняется более суток и подавляющему большинству пользователей не приходится часто вводить пароли.
Такой подход, возможно, больше подходит для временных аккаунтов или там, где нет необходимости в регистрации.
Этот путь не просто длиннее, он сложнее. Вам надо ещё и сделать свой сайт настолько интересным пользователю, чтобы более сложная аутентификация не отбила желание пользоваться вашим сервисом/ресурсом. Благо, у вас скорее всего будут конкуренты без этих хлопот.
Вы же забываете, что пользователю в общем случае не сложно придумать и потом вводить пароль. И не сложно его запомнить. Знаете почему? Потому что пароль к вашему сайту у него в подавляющем большинстве случаев будет такой же, как и ко всем другим аналогичным сайтам, и вполне вероятно, к его почте и онлайн-банкингу. А вы вместо того, чтобы вводить привычное слово, предлагаете пользователям квест «зайди в почту, найди наше письмо, открой письмо, перейди по ссылке. И желательно потом не забудь удалить письмо»
Понимаете, с одной стороны — ваша мысль интересна. С другой — неудобна. очень неудобна. Если, допустим, я каждый раз буду вынужден делать ЛИШНИЕ движения в виде проверки почтового ящика, для авторизации на каком-то ресурсе, то я просто через некоторое время перестану им пользоваться. Люди вообще ленивы сами по себе (отсюда и пульты управления бытовой техникой), поэтому любое лишнее движение будет воспринято отрицательно. Тем не менее было бы интересно провести где-то эксперимент и посмотреть на результаты.
Вечные куки в большинстве случаев решат проблему :)
Сервисы, любящие ставить куки на две недели, это отдельная беда, конечно.
Что-то мне подсказывает, что можно (нужно и стоит) при использовании такой схемы оставить пользователю в профиле тычку/галку/слайдер вида «Помнить меня день/неделю/месяц/год/до посинения»
Это Вы не видели игру The Settlers Online — она разлогинивается через пару часов!

Хотя вечные куки — это проблема на компьютере коллективного пользования.

А какая разница будет кука на 15 минут или на 100 лет, если через минуту за комп может сесть другой человек? Для девайсов коллективного пользования должна быть хорошо заметная кнопка "выйти".

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

Очень не удобно на девайсе личного пользования.

Ну так это надо оставить на усмотрение пользователя. Но по умолчанию д.б. «до закрытия браузера».
И этот выбор должен настраиваться так, что при заходе с нового устройства надо заново выставить опцию «хранить куки и после закрытия браузера». А по умолчанию на каждом новом устройстве куки хранятся до закрытия — независимо от того, какой выбор я делал на других устройствах, где работал раньше.
Электронная почта это много независимых почтовых серверов + набор необязательных к исполнению соглашений — доставка отдельно взятого письма вообще никем и никогда не гарантируется, оно может уйти в /dev/null по дороге, доставка задержаться, упасть в спам и тп, для реализации вашей же идеи необходима идеально работающая почта.
А уже нечто похожее например сайт издательства МИФ использует.
На сайте Бюро Горбунова аналогичная система. Вообще на таких сервисах это реально удобно, деструктивных действий практически нет (нельзя удалить аккаунт, перевести миллион денег на произвольный счет и так далее). Ну зайдет кто-то на МИФ, ну почитает мои книги. Карточка у меня виртуальная, купить с нее человек ничего не сможет, пока я сам туда не положу деньги.
Western Union использует примерно то же через SMS. Для логина вводишь номер телефона, приходит код в SMS, вводишь его. Никаких паролей.
В целом неплохая система как мне кажется, а раз уж такая крупная и связанная с деньгами компания ее использует — это повод как минимум подумать и посмотреть на нее внимательнее.
неплохая

ага XD

раз уж такая крупная

ага XDXDXDXD
Компания из Fortune 500 для вас недостаточно крупная?
Пароли через СмС не очень секьюрное решение, т.к. добавляется еще одна цепочка которому мы должны доверять — оператор сотовой связи. Я точно не помню, но по-моему передача смс не зашифрована, поправьте меня если я не прав.
Плюс СмС перехватить можно.
Но это если уже совсем ударяться в паранойю.
и дубль симки сделать можно(были случаи и неединожды)
вы и так доверяете оператору свои деньги, неужели доверить еще и временный пароль от социалочки такая проблема?
вы и так доверяете оператору свои деньги

250,42 рублей баланса?
и что, 250р уже не деньги?

По большому счёту да, один поход в магазин дороже обходится, некоторым аккаунт от соцсети дороже.
Я вот, например, со своим постоплатным тарифом не доверяю. Даже когда и доверял, количество денег на балансе телефона было на 3-4 порядка меньше типичного баланса карт.
Намекается, что если компания крупная, это совсем не значит, что система у неё хорошая. Чаще бывает наоборот — компания либо ещё что-то очень крупное, но сделано что-то чуть ли не самым плохим вариантом.

Что касается конкретно данного случая, защита по смс — один из наименее безопасных вариантов из всех возможных. Получается, компания крупная, а защита минимальная.

Хотя если отслеживается перевыпуск карты, уже не совсем ужасная защита (без этого это даже защитой нельзя считать в принципе, т. к. защита минимальна), но всё-равно, это явно не то решение, на которое нужно равняться.

За что мне поставили 4 минуса — не понимаю. Видимо, нужно было лучше объяснить.

Тогда надо использовать облако.

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

В целом, никто не мешает слать временны пароль на почту пользователю. Но тогда TTL такого запроса должна стать в разы короче, либо нужно будет сделать лимит на попытки ввода токена.


А СМС, да они в разы дороже, чем отправка письма.

смс менее защищенные чем email (например к ним имеют доступ те же гос. спец. службы). Так что если делать привязку через телефон то какой-нить Authy.

почему в смс высылают полную часть кода а не половинку, одну половинку показывают например на сайте а вторую в смс которую надо ввести

Потому что атакующий, который запросил СМС, смотрит на тот же самый сайт.

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


(я уж молчу о том, что я не на каждом сайте хотел бы светить свой емейл)

А разве входя через email + password, вы не светите email?

А разве я обязан вводить там реальный емейл?

Некоторые сервисы не пустят вас, пока вы не подтвердите email. Следовательно, не войдя в него, вы не сможете этого сделать.

Ну так одноразовые емейлы же для этого и придуманы.

А что мешает использовать одноразовый Email в этой схеме?

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

Согласен, если вы намерены использовать этот аккаунт долгое время, то потеря доступа к email, повлечет и потерю аккаунта.


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

Хотя, если вы намерены использовать этот аккаунт долгое время, то потеря доступа к email (а временная почта это и подразумевает), повлечет и потерю аккаунта.

Почему?


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

Вы же предлагаете свой подход не только "для важных учеток", а везде?

Почему?

"Почему" потеряете доступ? Я не совсем понял этот вопрос.


Вы же предлагаете свой подход не только "для важных учеток", а везде?

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

"Почему" потеряете доступ? Я не совсем понял этот вопрос.

Да, почему может случиться потеря эккаунта.


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

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

Да, почему может случиться потеря эккаунта.

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


… ценой понижения безопасности и удобства

А чем, помимо возможности использования одноразовых email, этот вариант менее безопасный?

Почта протухнет, следовательно вы не сможете выслать на нее письмо с ссылкой на вход

Вы про свою систему говорите, или про существующие?


А чем, помимо возможности использования одноразовых email, этот вариант менее безопасный?

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

Вы про свою систему говорите, или про существующие?

Да я все, про описанную систему выше говорю.


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

Да, но не большая, чем зайти даже с временной почтой и паролем.


А временные пароли по СМС / Google Authenticator / прочие 2fa могут решить эту проблему с почтой.


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

Да я все, про описанную систему выше говорю.

В вашей системе — да, так работать не будет. И это большая проблема.


Да, но не большая, чем зайти даже с временной почтой и паролем.

Эм, вы не с тем сравниваете. Сравнивать надо "мы зашли на сервис, введя почту (в худшем случае) и пароль от этого сервиса" с "мы зашли на сервис, введя почту и пароль от почты".


А временные пароли по СМС / Google Authenticator / прочие 2fa могут решить эту проблему с почтой.

Не могут. Чужой компьютер позволяет воспользоваться открытой сессией для разных странных нужд.


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

Вам не приходилось, а я несколько раз за рубежом пользовался интернет-кафе и общими компьютерами в отелях.

Чужой компьютер позволяет воспользоваться открытой сессией для разных странных нужд.

Элементарные правила безопасности никто не отменял. Режим инкогнито, выход из аккаунта — для кого это всё? Есть сомнения в чистоте компьютера (кейлоггеры и т.п.) — найдите другой.
Режим инкогнито, выход из аккаунта — для кого это всё?

Это все не помогает, если компьютер скомпрометирован.


Есть сомнения в чистоте компьютера (кейлоггеры и т.п.) — найдите другой.

Зачем мне это усложнение, если я не настолько дорожу данными сервиса, в который логинюсь?

Мужик, если компьютер «скомпроментирован», то либо ты странный (вот на «скомпроментирован»'ном компьютере тебе не чего не поможет, чес слово такой бред несёте !), либо ты думаешь, что пароль и почта, и более того тут говориться о менеджерах паролей, не помогут! Как ты блин собираешься в кафе авторизоваться, когда у тебя все пароли в менеджере?
Говоришь надо всё равно логиниться через почту? А когда это у нас общественные компа, да и любые другие, кроме своего, стали вдруг безопасными?
P.s. не то чтобы я не доверяю любым компам, но как минимум используют режим инкогнито и отключаю всякие куки и все свои учётки активирую с помощью смс на телефон, но я это могут делать и без пароля! А идея замены на сообщение на почту как одна из функций мне лично нравится, особенно когда я сижу дома и мне лень тянуться до телефона!
Как ты блин собираешься в кафе авторизоваться, когда у тебя все пароли в менеджере?

Легко и просто: открыл менеджер на телефоне, вбил пароль в компьютер.


Говоришь надо всё равно логиниться через почту?

Нет, я говорю, что через почту логиниться не надо.

Ну не логинься! Кто-то запрещает? Автор статьи говорил не про замену для всех, а для тех кому эта фича полезна, тому кому лень постоянно вводить пароль!
Для сравнения, сейчас ни кто ни заставляет вас использовать для входа смс подтверждение через телефона, но фича то есть!
Да и как по мне это удобнее чем смс на телефон, в том отношении, что я и так сижу за компом в браузере, открыть почту и посмотреть код, как например это сделано в том же Steam, не так уж и затратно по времени! А вот брать телефон, скорей всего у вас тоже так, снимать блокировку, открывать сообщение и потом вводить этот код ручками…
Полезность каждый определяет для себя сам, но как минимум — это полезная фича =)
Ну не логинься! Кто-то запрещает?

Автор, который утверждает, что пользователям не нужны пароли.


Для сравнения, сейчас ни кто ни заставляет вас использовать для входа смс подтверждение через телефона, но фича то есть!

Вы, видимо, не слышали про принудительную двухфакторную аутентификацию в онлайн-банках?

Автор, который утверждает, что пользователям не нужны пароли.

Всем? Автор может так и считает, но я нет. Для меня это просто полезная фича в некоторых сервисах =)
Вы, видимо, не слышали про принудительную двухфакторную аутентификацию в онлайн-банках?

Серьёзно? То есть имея приложения для банкинга вы полезете на свой личный кошиль через хрен пойми как защищённый комп?
Зачем мне это усложнение, если я не настолько дорожу данными сервиса, в который логинюсь?

То есть ваш банковский счёт для вас это несерьёзно? Можете пояснить или я не понял, вы вроде писали, что логинетесь на сервисы данными на которых вы не дорожите, тогда зачем сейчас говорить про онлайн банки? Добавлю, что приложения на телефоне (банкинг) не плохо так защищает!!! В принципе заходите через браузер компа почти не нужно! Могу ошибаться, т.к. не пользуюсь пока!
Всем?

Статья написана так, как если бы всем.


Серьёзно? То есть имея приложения для банкинга вы полезете на свой личный кошиль через хрен пойми как защищённый комп?

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


Можете пояснить или я не понял, вы вроде писали, что логинетесь на сервисы данными на которых вы не дорожите, тогда зачем сейчас говорить про онлайн банки?

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


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

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

Не подменяйте контекст, вы написали «никто не заставляет использовать смс-подтверждение» — я вам привел пример (и их много) сервисов, которые заставляют.

Во-первых не подменяю, т.к. мы с вами говорили о сервисах, данные которых для вас не важны, с этого я и начал! Во-вторых банк — это хоть и сервис, но всё таки данные там крайне важны!
Я вам больше того скажу, иногда приходится именно так и делать (потому что приложение для банкинга должно где-то стоять, а у этого «где-то» может не быть интернета), и вот как раз здесь принудительное подтверждение каждой операции очень помогает.

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

Ездил не заграницу, а по России пользовался нормально. Понимаю, что Россия != Заграница, но разве нельзя купить сим-карту? Извините, но мне кажется вы тяните проблемы, которые решаются.
Если говорить о логине в банк, то вы предоставляете, скорей всего почту и пароль. Вернусь, вы всё равно подставляете важные для вас данные!
Я бы купил в аэропорту сим-карту или почитал в сети как обстоят дела с интернетом в той стране в которую лечу!
Да насчёт организованности банкинга, я вам полностью согласен. Данные передаются зашифрованными и боятся, что кто-то получит к ним доступ, не нужно, т.к. другого способа защиты попросту нет =)
P.s. Вообще есть =) Наличные деньги в сумке или потайном кармане всегда безопасней карты =)
Во-первых не подменяю, т.к. мы с вами говорили о сервисах, данные которых для вас не важны, с этого я и начал!

Так и надо было писать "никто из сервисов, данные которых для вас не важны, не заставляет пользоваться смс-подтверждениями". Впрочем, все равно не уверен, что это правда.


Ездил не заграницу, а по России пользовался нормально. Понимаю, что Россия != Заграница, но разве нельзя купить сим-карту?

Не везде можно. Не везде есть покрытие. Иногда просто жалко денег.


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

Нет, конечно. Уникальный идентификатор (в ВТБ24 — вообще цифровой) и пароль.


Я бы купил в аэропорту сим-карту

У вас много лишних денег? Ну вот купили вы сим-карту, залезли в Porthcarno, а там хрен вам, а не мобильное покрытие. А вот проводочек протянут.


Наличные деньги в сумке или потайном кармане всегда безопасней карты

Очевидно, нет. Объяснять надо?

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

Если не секрет, что это за интернет-кафе такое, где нет возможности подключить смартфон по вайфаю?

Обычный принт-шоп в Севилье, неподалеку от Архива Индий.

Ну вот мой пример: перед походом в принтшоп в Петрозаводске, я залил нужный мне файл на флэшку и в интернет.


Придя в принтшоп я просто продиктовал адрес и они скачали мой файл. Флэшка не понадобилась.


Вводить какие либо пароли на их компьютерах — не понадобилось.


А какой Ваш кейс, если не секрет?

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

файл не был публично доступен

А почему?


У Вас же, по Вашим словам, есть большой опыт в таких делах.


Почему Вы не подстраховались?

У Вас же, по Вашим словам, есть большой опыт в таких делах.

В каких?


Почему Вы не подстраховались?

Потому что не счел необходимым.

Ну то есть, в качестве примера Вы используете случай "пользователь профакапил"?

Нет, я использую случай "на это не рассчитывали".

В каких?

Пребывание в местах со специфической ситуацией в плане интернета.

Автор, который утверждает, что пользователям не нужны пароли.

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

Видимо мы не знакомы с автором, ведь я в начале статьи явно сказал "возможно не нужны",

Заголовок статьи же.


в конце развернуто перечислили кому эта функция могла бы быть полезна

Указав там корпоративные сайты, для которых это, как уже сказано, неверно.


(да и API сейчас тоже есть много у кого)

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

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


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

Через OTP — да, меньше рискую. Но речь в примере шла не про OTP, а про логин через почту.

Тут соглашусь :) Через почту не вариант.
Да, почему может случиться потеря эккаунта.
Email это ключ к восстановлению пароля. Если вы при регистрации использовался «одноразовый email», то восстановить пароль в случае утери будет не возможно.
Кроме того часть функционала сайта может быть не доступна без доступа к электронной почте (рассылки, уведомления и т. д.).
Email это ключ к восстановлению пароля. Если вы при регистрации использовался «одноразовый email», то восстановить пароль в случае утери будет не возможно.

Ну и пофиг, я вполне способен сам следить за своими паролями.


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

Это меня тоже может не волновать.

Ну и пофиг, я вполне способен сам следить за своими паролями.
Это меня тоже может не волновать.
Охотно верю. Но ведь статья не про вас.

А про кого?

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

он наверно имеет ввиду сервисы которые генерируют временные ящики на 10 минут и тем самым он юзает их для регистрации не светя свой настоящий email.


и второй раз получить к тому же временному email очень мало вероятно

Все популярные почтовые сервисы доступны только через HTTPS.
Интернет-кафе, это не только доступ к интернету, но и чужой компьютер, которому вы не можете доверять… Никакие HTTPS не помогут на чужом устройстве.

Мне кажется, эта проблема решилась сама собой пару лет назад, когда в каждом кофе появился Wifi.

Далеко не в каждом, если вы посмотрите по всему миру. А уж если вам что-то напечатать надо, так и еще веселее.

После введения «WiFi по паспорту» некоторые кафе перестали раздавать WiFi
Да уж, как появился, так и исчез…
После повсеместного распространения LTE посетители просто перестали обращать на это внимание.

Повсеместное распространение LTE в любой стране пребывания — это тоже не так просто, как кажется.

Для чужого компьютера это не имеет значения.

я уж молчу о том, что я не на каждом сайте хотел бы светить свой емейл

Светить username+spamsite112@gmail.com и получать по факту почту на username@gmail.com не подходит под это описание?

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

Sendmail такое из коробки поддерживает, вроде как — так что привязки к Gmail особой нет. А про связь ящиков — тут уж смотря какие цели. Если цель — увести основное никому не известное мыло от направленной атаки — тогда да. Но и в таком случае можно создать ширпотребный ящик и использовать теги уже на нём :)

Цель — не светить свою идентичность и усложнить связь учеток на разных сервисах друг с другом.

Интересно: тут либо на каждый сервис/сайт регистрировать свою почту, чтобы «усложнить связь учеток на разных сервисах друг с другом», но это быстро надоест, а более способов я не вижу, а один E-mail уже свяжет так и так учётки между собой. Либо если сайт требует регистрацию по мобильному номеру, то как тут быть?
Интересно: тут либо на каждый сервис/сайт регистрировать свою почту, чтобы «усложнить связь учеток на разных сервисах друг с другом», но это быстро надоест

Если надоест, значит не так уж и важно.


Либо если сайт требует регистрацию по мобильному номеру, то как тут быть?

Я без идей. Кто-то как-то говорил, что найти сервисы, имитирующие номера для смс тоже можно.

На самом деле есть вариант объединить преимущества обоих подходов:
1) При регистрации попросить-таки придумать пароль, как обычно
2) При логине требовать емейл
3) Дальше предлагать либо ввести пароль либо подтверждение на почту
Все старые юзкейсы работают, но если обычный пользователь забыл пароль или не хочет париться его вспоминать-вводить, пользуется подтверждением.

Чем это (радикально) отличается от обычного "сброса пароля по почте"?

Тем же, чем iPhone 1 от HTC touch :) Радикально ничем, но удобнее гораздо.
Сброс пароля заставляет вводить новый пароль, у самых умных ещё "пароль не может совпадать со старым". Новый пароль точно так же забывается когда заходишь ещё раз на сайт ещё через год.
Ну и заходить на сайт каждый раз через сброс пароля лютое неудобство и костыляторство, а тут как бы альтернативный способ: хочешь — заходи.

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

Это если "сброс пароля" требует ввода нового пароля, а не делает автологин. Такие решения уже есть.


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

«В половине глючит» — это же проблема конкретной реализации.

Ну как бы проблема с не тем браузером — она часто встречается.

Удобнее — нет, если только не предлагать это прямо в процессе логина (и название сменить, да), иначе ровно то же самое. :)
Многие так и делают когда лень запоминать или записывать пароль. Вполне себе удобно, особенно когда сайт сохраняет сессию на долго.

То есть:


  • у Вас есть потребность в интернете
  • у Вас есть электронная почта
  • при этом, у Вас нет смартфона и Вы где-то нашли интернет-кафе

Кто Вы, и как попали в наше время?

Вы серьезно никогда в местах без сотового покрытия не были?


У меня смартфон-то есть, только сотового интернета нет. И дело было буквально года три назад в милом городе Севилье. И год назад на Койя-сан. И в этом году в Порткарно.

Не могли бы Вы в точности описать решаемую Вами задачу?


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


Это какой-то очень интересный кейс.


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

Омг, да все же просто, как валенок.


Есть билет, купленный онлайн. Чтобы пройти по билету, нужна распечатка (нет, показать с устройства нельзя; и все равно на устройстве билета нет). Билет лежит в pdf в дропбоксе. Сотового интернета нет, потому что нет (вплоть до отсутствия сотовой связи вообще, так тоже бывает). Приходим в принт-шоп, у них есть компьютер, подключенный к интернету (как раз для кейсов "распечатайте мне из интернета"). Заходим в дропбокс (там пароль и 2FA, пароль в менеджере на смартфоне, 2FA в приложении на смартфоне), скачиваем файл, отдаем на печать, все.


В случае с онлайн-банкингом все то же самое, только сотовая связь есть, а сотового интернета нет (у меня так в Китае было).

В случае с онлайн-банкингом все то же самое

То есть, Вы входили в онлайн-банк с компьютера на котором побоялись вводить пароль от своей почты?

Ну да, я даже объяснял, почему.

Билет лежит в pdf в дропбоксе.

То есть Вы, с таким большим, по Вашим словам, опыте и знаниях, не имеете с собой OTG и флэшки на такой случай?

Да. Я вообще перестал с собой возить носители в путешествия.

Вам не кажется, что такой Ваша пример нерепрезентативен при обсуждении функционала массового сервиса?

Нет, не кажется.

В чём проблема завести специальный почтовый ящик-помойку? Основная почта пусть будет для общения и важных дел, запасная — для подписок на спам и засвечивания везде, где требуется.

Ни в чем.

пришел к подобному подходу довольно давно есть пару замечаний по таблице sign_in_requests:


  1. Колонку email заменить на users_id (связь по primarykey как то более привычно).
  2. Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).
  3. Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену
  4. Колонка requestIp в реальности бесполезна (если только не супер строгая система, но там такой подход вообще не подойдет).
  5. Добавляю колонку deleted_at где можно деактировать любую запись

Также в некоторых случаях если не охото jwt юзать или сессии, можно добавить колонку secret(Uniq) и сообщать ее пользователю и там хранить уже в куках или localstorage и отправлять этот секрет с каждым запросом, у этого подхода есть и минусы но в некоторых случаях он прекрасно подходит


Получается колонка secret это как бы session_id который не чистится и человек авторизован пока не выйдет (logout)

Колонку email заменить на users_id (связь по primarykey как то более привычно).

Как я говорил выше, в этой реализации, эта таблица может также выполнять роль sign_up_requests. А в этом случае, у вас может еще не быть пользователя с таким email.


Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).

Тоже вариант. Но у меня были случаи, когда токен нужно было в ручном сделать "долгожителем" (для нерасторопного, но очень важного для бизнеса пользователя), при этом не меняя срок жизни остальных токенов.


Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену

Вот это крутое замечание, обновил статью.


Добавляю колонку deleted_at где можно деактировать любую запись

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

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

На корпоративных сайтах обычно используется SSO.

Но перед тем, как зайти через SSO вы ведь должны ввести email + pass. Конечно, если ваш почтовый сервис, это уже SSO, то да, вопрос отпадает.

Но перед тем, как зайти через SSO вы ведь должны ввести email + pass.

Эээ, почему это? Если я в домене и включена доменная аутентификация, то вообще ничего вводить не надо. Если в браузере доменной аутентификации нет, но открыты корпоративные сервисы, значит, уже есть открытая сессия, и тоже ничего вводить не надо. В-третьих, в SSO не обязательно email (и даже не обязательно пароль).

А в чём проблема вместо подтверждения по емейл запросить код из Google Auth?
И безопасно и помнить не нужно. Тогда и пароль нафиг не нужен. И нет необходимости в каждом интернет-кафе почту дёргать. А уж критические изменения подтверждать по е-майл.
И безопасно и помнить не нужно.

Небезопасно. Украли устройство — получили доступ.


А если устройство отказало — доступ не получит даже владелец.

Не будем драматизировать. Во-первых я указал что критичные изменения подтверждаются по е-мейл. Для параноиков или сайтов с деньгами можно сделать выбор «пароль/auth/пароль+auth». Во-вторых — если вы забыли пароль (равноценно утере девайса) — всё равно в тот же е-мейл для восстановления полезете. И не забывайте, сервер может проверять белые списки, смотреть были ли заходы с этого ip ранее и проводить иные проверки, и при сомнениях задавать пользователю разные неожиданные вопросы из ряда секретных или требовать таки ввести пароль/пин. В общем идея хороша, и всяко девайс угнать обычно сложнее, чем пароль.
Не будем драматизировать.

Это не "драматизировать", это реальные проблемы. Кому-то может быть на них положить, так бывает. Но не всем.


Во-первых я указал что критичные изменения подтверждаются по е-мейл.

Доступном на том же устройстве, да?


Во-вторых — если вы забыли пароль (равноценно утере девайса) — всё равно в тот же е-мейл для восстановления полезете

Это если восстановление через емейл.


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

Да нет, просто забрал со стола и все.

Кому-то может быть на них положить, так бывает. Но не всем.

Судя по вашим сообщениям выше, вам положить. Но потроллить-то надо.
Доступном на том же устройстве, да?

Нет, на телефоне только 2fa.
Да нет, просто забрал со стола и все.

А вы не бросайте на столе телефон с 2fa, если вы такой параноик.
Предлагаю диаметрально противоположное — для авторизации на сайте предлагаем ввести пользователю только пароль. Действительно, зачем при авторизации нужен логин?
Email, имя и еще какие-то данные могут спрашиваться при регистрации и использоваться, например для рассылки уведомлений, но при авторизации спрашивать только пароль. Да, пароли у всех должны быть одинаковые, потому-что автогенерируемые.
P.S. Пытался опубликовать заметку на эту тему на хабре, хотя суть укладывается в одном предложении.
для авторизации на сайте предлагаем ввести пользователю только пароль. Действительно, зачем при авторизации нужен логин?

Чтобы исключить ситуации, когда пароли совпадают.


(еще чтобы усложнить перебор, конечно же)

представьте, что пароль у вас — это склеенные email и пароль.
пароли и должны быть у всех разные. если они настолько просты, что совпадают — сам себе злобный буратино.
>> если они настолько просты, что совпадают
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
А не надо проверять после выдачи, пароль генерируем сами, уникальным:) это как пример.
>> пароль генерируем сами, уникальным
Вам за это не один пользователь спасибо не скажет. Например, видели какие сейчас имена электронных адресов автоматически предлагают Яндекс, Google? А мы тут вроде как про удобство.
Для неавторизированного пользователя отображаем поле ввода пароля, человек вводит свой пароль, берем от него хеш (с солью), проверяем есть ли такой пароль в табличке, если есть — авторизуем пользователя, если нет — это новый пользователь, предлагаем ему ввести доп информацию о себе, например email или что кому нужно.

На счет одинаковых паролей, просто хочу показать, что подход с одним паролем ничем от логина и пароля не отличается, только это удобнее.
>> водит свой пароль, берем от него хеш (с солью)
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.
Соль или должна быть одна, общая, или генерироваться из пароля.
Соль или должна быть одна, общая, или генерироваться из пароля.

А вы уверены, что у вас криптографическая стойкость от этого не упадет? По идее, должна бы.

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

Ничем не отличается? Как вы защититесь от ситуации "ошибся в одном символе пароля, попал в чужую учетку"?

И как бороться с подбором пароля?
Т.е. тупым перебором можно подобрать всю базу аккаунтов.
Предложу аналогию с симметричными алгоритмами шифрования. Одного пароля достаточно и, если пароль достаточно хороший «тупым» перебором его подобрать «проблематично».
В чем проблематичность перебора?
Если у сервера есть логин, то перебор пароля пресекается после N неудачных попыток входа в этот аккаунт — все остальные работают. Если у Вас только пароль, то можно бесконечно долго подбирать пароли — Вы не можете пресечь эти попытки, только положив весь сервер.
Точно также как можно бесконечно брутить пароль для зашифрованного архива и если пароль достаточно сложный ничего не получить, не смотря на то что никто и никак не может ограничить попытки подбора этого пароля.
Тем более, что с брутом пароля к аккаунту на веб-сервисе все-таки есть некоторые возможности ограничить попытки брутфорса, например по ip.
И еще, я не предлагал использовать эту систему для всего, например для денежных операций. Мне кажется для различных сервисов должны использоваться разные подходы. Я скорее про те сервисы, брутить пароли для которых никому особо и не нужно (в смысле не стоит стоимости этого самого брута).
В случае с паролем к архиву у Вас всего один вариант пароля.
В случае с сервисом злоумышленник может подобрать все пароли или большую часть. Особенно, если ему все равно какой аккаунт взламывать.
Согласен, т.е. подбор пароля для базы из 10000 пользователей упрощает задачу на log(10000,2) = 13.3 бит. Пароль из 16 символов это около 85 бит (если только английские символы и цифры).
И еще, что если злоумышленник уже как-то слил базу с хешами и теперь ему нужно подобрать пароль к хешам.

Интересно кстати, никто еще не придумал делать табличку с хешами пользователей общедоступной?
Опять же на первый взгляд может показаться дикостью, с другой стороны можно привести аналогию с шифрованием по типу «черного ящика» и нормальным шифрованием, когда известно как шифруется и зашифрованные данные общедоступны, но расшифровать их не так-то просто.
>> Пароль из 16 символов
Вы совсем не любите своих пользователей.
И для хеша это простейший запрос к бд, разве что строка для проверки длиннее.
>> И для хеша это простейший запрос к бд, разве что строка для проверки длиннее.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
представьте, что пароль у вас — это склеенные email и пароль.

Представил. Чем это теперь отличается от введенного логина и пароля? Тем, что все в одном поле?


пароли и должны быть у всех разные

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


(защита от перебора все равно усложняется)

У меня все логины (где это не обяхательно имя пользователя или email) выглядят вот так: RMz-utG-7C
Но вам приходится заполнять в форме два поля, это не удобно и это излишне.
Мысль использовать только пароль, конечно, может показаться дикой, но только сначала.
За меня это делает автозаполянлка, ей всё равно сколько полей.

Кстати, на счёт одного пароля, это я где-то такое видел на очень древнем сайте. Просто даётся некий id и всё.
Если вспомните где это видели, напишите пожалуйста здесь.
Это был какой-то адовый правительственный сайт из 90ых :)

Если не изменяет память, так делает саппорт Webmoney, он просто выдает вам токен на вход в чат.

Например, на DuckDuckGo нужна только pass phrase для сохранения настроек.
Внимание! Введенный вами пароль уже используется пользователем Вася Пупкин. Пожалуйста, введите другой пароль.

Это в разы опаснее: придётся кучу раз заходить на почту на всех компах, с которых вам потребовалось зайти на форумы или интернет-магазины.
При защите паролем — чем меньше мы его вводим, тем надёжнее.
Такая авторизация имеет смысл в паре с простым паролем, типо 4х цифр: часть функционала на нём, а все критичные действия — через авторизацию в почте.

Вот ведь занятно, коллега — вы ответили на час позже и примерно то же самое.
А плюсуют вас :)
Я вообще рид-онли, мне на плюсы всё равно.
Вашего комментария на момент написания не видел, извинтиляюсь.
То есть, чтобы залогиниться на форум мне надо ещё и почту проверить и что-то там ткнуть, вместо того чтобы автозаполнение само за меня заполнило. У — удобство. А если учитывать, что добрые 90% моих учёток загеристрированны с почтой на 10minutemail.com то становится вдвойне весело.

У сброса пароля через почту всё-таки есть одна дополнительная фича — хоть взломщик и получит таким образом доступ к аккаунту (если у него уже есть доступ к почте), но владелец аккаунта тоже узнает о взломе — ведь взломщик не знает старый пароль и не сможет его восстановить, даже если другие следы (письмо со ссылкой сброса пароля) он сможет подчистить.


Что касается большого срока жизни сессии — какая разница, надо вводить пароль или нет, если это надо делать раз в год?


Ну и последнее, про менеджеры паролей. По-хорошему, если уж Вы заботитесь о безопасности пользователей, то нужно наоборот, приучать и стимулировать использовать менеджеры паролей. Что касается сложности в использовании — то с тем же KeePass всё наоборот намного проще, чем в Вашей схеме — когда я вижу форму логина на сайте я нажимаю Ctrl-Alt-A и… всё. KeePass сам определяет что это за сайт, сам вводит логин/пароль или что на этом сайте нужно, и сам отправляет форму. Так что вся "сложность" использования менеджера паролей заключается в однократном добавлении записи о новом сайте при регистрации (с процессом которой KeePass так же помогает генерируя пароль).

Я вам так скажу, многие сервисы, высылают пароль на почту а не генерируют новый (уже меньше таких стало, но имеют место быть. Даже в топовых интернет-магазинах).

Я в курсе. И? К чему Вы это сказали?

А! В смысле, они высылают не новый случайный пароль (что тоже плохо, особенно если при этом старый пароль удаляется), а текущий пароль? Т.е. хранят пароль без хеширования, помимо прочего. Ну, что тут скажешь, в таких веб-магазинах надо голосовать рублём, удаляя аккаунт и отправляя письмо по всем доступным email-ам руководства, объясняя почему дальнейшее использование их веб-магазина не представляется возможным.

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

Идея-то может и хорошая (избавиться от множества паролей), но вот реализация…
Тут можно провести две аналогии:


  1. Это OAuth. Но не OAuth, а хуже. Потому что это просто почта. Кэп доволен. %)
  2. безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты
    Это менеджер паролей. Потому что в итоге — все равно нужен один пароль. Но это хуже менеджера паролей, потому что… ну вы поняли. %)

В обоих случаях есть общая черта — мы используем почту не по назначению, отсюда огребаем косяки с пограничными случаями и удобством. Отсюда вывод — надо использовать менеджеры паролей, потому что они ради этого и придуманы! Минус только один — менеджер паролей есть не у всех, и он не стандартизован (так, как почта). Хотя, с момента распространения соцсетей и смартфонов, и почты, вероятно, у кого-то уже может не быть… но это уже не проблема запоминания паролей.


И да, есть еще вариант — ключ. Это можно считать за длинный незапоминаемый логин+пароль, если угодно. Или просто хардварный ключ.

Ах да, забыл еще важный момент — почта никак не гарантирует сохранность ваших паролей! Вот у меня, к примеру, мыло.жру регулярно стало отжимать почту в этом году, но, к счастью, я там давно ничего важного из логинов уже не держал или перевел от греха подальше в короткие промежутки, пока был доступ… Или вообще контора, держащая серваки, разорится/реорганизуется и домен с почтой пропадет навсегда.
Такие дела. :)

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

Менеджер паролей это PKI. Но не PKI, а хуже. Почему сайты не делают аутентификацию по пользовательскому сертификату — не ясно.

Некоторые делают: webmoney, startssl. Геморроя с этими сертификатами — море. Нет, после регистрации всё неплохо, сертификат установлен в браузер и дальше логиниться несложно. Но чтобы не остаться без доступа приходится из браузера этот сертификат выковыривать, сохранять в отдельный файл, при этом его шифруя паролем (который ещё нужно добавить в менеджер паролей, угу), импортировать его в другие свои браузеры (а что, если доступ нужен с чужого компа, кстати?) и потом ещё не забывать обновлять эти сертификаты (во всех браузерах, чтобы не скучно было) раз в 1-3 года. Спасибо, но нет!

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

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

Увеличивается время входа на сайт. Ввести логин и пароль гораздо быстрее.
Увеличивается время входа на сайт.

Вы имеете ввиду время сессии / срок действия cookie?

Нет, сам процесс входа. Вместо «ввёл имя, ввёл пароль, нажад вход» получается «ввёл почту, открыл вкладку с почтовым ящиком/почтовый клиент, открыл письмо, нажал на ссылку».

Плюс многие сейчас почту только на телефоне читают, а пароль от почты могут даже не помнить. И им тогда придётся ручками ссылку вбивать. Лучше уж цифровой код присылать. Ну или и то и другое сразу.
В общем, хуже только вход на сайты через соцсети устроен, когда тыкаешь «войти через фэйсбук», а тебя, после подтверждения доступа на фэйсбуке, кидают на форму регистрации на самом сайте. Нахрена тогда вообще фэйсбук тут нужен был?
Нет, просто представьте, что ходите в интернет через диалап. Но сайты уже совсем не те, что были при диалапе. %)
Одно из возможных решений, это использовать OAuth 2.0, но не у всех пользователей может быть аккаунт в социальной сети и желание его использовать на вашем ресурсе.

А что мешает использовать несколько способов аутентификации? Кто хочет, тыкает «войти через facebook» и логинится через него, кто хочет — регистрируется через логин-пароль и использует их для входа на сайт? Как вариант, можно даже руководствоваться таким принципом: если соцсеть отдаёт е-мейл, привязанный к учётной записи, то считать, что соцсеть уже подтвердила принадлежность этого адреса владельцу (но предварительно проверить используемые соцсети, что они действительно проверяют при привязке почту, а не разрешают забить туда любой адрес безо всякой проверки)

Заметьте, я не сказал ни слова против OAuth. Подход описанный выше может спокойно сосуществовать с ним (в принципе, как сейчас и происходит).

На сайте издательства «Манн, Иванов и Фербер» (не реклама) давно реализован похожий способ аутентификации.

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

НЛО прилетело и опубликовало эту надпись здесь
В Medium то же самое.
Вот я рядовой ленивый пользователь.
Я, скорее всего, зайду на сайт, введу свой мейл и… А пароль вводить? Ощущение, что на меня хотят повесить e-mail-рассылку (так, по сути, и есть, если задуматься), как-то подозрительно это, и, скорее всего, я просто покину сайт. Минус пользователь.
Пол беды. Допустим, я об этом не задумался.
Захожу на сайт, ввожу мейл, радостно тыкаю кнопку входа… И оно мне сообщает, что нужно что-то там открывать и что-то там тыкать… Ой, Господи, ну его нафиг. И просто закрою вкладку.
Ладно, это я к чему. К тому, что хоть эта схема и придумана для самых непродвинутых пользователей, именно их она и отпугнет от использования сайта, я считаю. А нормальные люди используют менеджеры паролей. Поэтому, отток пользователей после введения такой системы входа не был бы чем-то странным, по-моему.

Как я сказал в заключении, этот подход непривычен. Но никто не мешает вам рассказать пользователям, как пользоваться такой "фичей".


К примеру, сделать галочку "я не хочу использовать пароль". А остальное дело времени и выработки рефлексов.

Как раз искал этот комментарий что бы самому не писать… Действительно если сервис не пускает тебя сразу, а заставляет идти и тыкать ссылку где то в письмах в 99.9% случаях такой сервис не нужен никому. Первое о чём нужно думать в любой реализации это об удобстве пользователя. Да, действительно пароли и логины надоели, но перекладывать на устаревшый уже морально email это плохой вариант. Более того, даже эти несчастные смс подтверждения уже порядком надоели. А точно идентифицировать юзерское устройство нельзя (можно было бы скажем какой то ключ устройства типа IMEI использовать, но тоже мимо.
Действительно если сервис не пускает тебя сразу, а заставляет идти и тыкать ссылку где то в письмах в 99.9% случаях такой сервис не нужен никому.

Мне нужен. Я один такой из тысячи?

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

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

И долго вы оставались владельцем почты с паролем из 3 цифр? :)

Случайно сменил в прошлом году. Не ту кнопку в запарке нажал
Повезло! Меня они шантажом заставляли сменить пароль на менее сложный, чем был. %)
Хотя, идея с отказом от пароля выглядит дико и непривычно,
Вообще этой идее как миниму лет пять. И даже есть реализации для фрейворков и CMS.
nopassword.alexsmolen.com

Охотно верю, но раньше решения предложенного вами не встречал.


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

В «Telegram» тоже сначала не было паролей. Но потом под давлением обстоятельств пришлось сделать, хоть и опционально.
Вы не избавляетесь от пароля, вы перекладываете «сервис аутентификации» на сторонний ресурс (в статье это почта, некоторые еще используют sms). Из плюсов:
— Вы перекладываете написание/сопровождение аутентификатора на сторонний сервис
— Вашим пользователям не нужны пароли у них есть почта/sms
Из минусов:
— Для входа на ваш ресурс необходимо войти/проследовать в зависимый сервис
— В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы

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

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

Спасибо за внимание…
вы перекладываете «сервис аутентификации» на сторонний ресурс

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


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

Да, ровно как и сейчас. Если у вас взломали почту — то вы потеряете и доступ к большей части сайтов вместе с ней. Т.к. "ресет пароля".


если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).

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

В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Так ведь и при обычном способое взломщик может получить доступ ко всем привязанным аккаунтам через востановление пароля.
Давай-те не будем путать алгоритм аутентификации и алгоритмом восстановления пароля. вещи таки разные (не смотря на то, что сделаны у многих рукожопо).

Владелец сайта при создании/внедрении алгоритма восстановления пароля должен учитывать что почта может быть взломана (привет «Секретные вопросы» например)
Секретные вопросы

Еще один излюбленный инструмент садиста. Я с большей долей вероятности забуду "Имя первой учительницы", чем сгенерерованный 64'ех символьный пароль.


P.s. менеджер секретных вопросов может стать неплохим стартапом.

Но это не так. :) Сколько уже было статей на тему «лучше запоминаемые длинные пароли, чем рандомный набор символов». Другой вопрос, что длиной-то многие как раз и жертвуют…
дак там суть не в вопросах,. а в том чтоб задать простую фразу (не обязательно ответ) по которому система вас идентифицирует
P.s. менеджер секретных вопросов может стать неплохим стартапом.

В KeePass + KeeFox можно настроить заполнение любого поля на странице. А вообще я туда забиваю случайные символы, пока в лимит не упираюсь.
Я вот только одного не могу понять: значит любой кто узнает email пользователя сможет войти в его аккаунт на сайте? Так ведь на многих сайтах даже пишут email в профиле открыто. По моему бредовая затея.

P.S. Другой вопрос OAuth. Вот это конечно удобная штука.
upd. Кажется понял. Я невнимательно прочитал про процесс авторизации, извините.
OTP токен решает проблему с паролями гораздо лучше.
Я бы еще добавил к этому функциональность «запомни меня» с двойным токеном и защитой от кражи кук.

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

Каким бы сильным ни был ваш хеширующий алгоритм (и упаси вас господь, не использовать его) рано или поздно он станет пустяком для новых GPU, а в последствии и CPU.
Все остальные решения по сервису тоже принимать с оглядкой на то, что может случится в ближайшие 200 лет?

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

Кстати да! Мыло еще и долго идти может. А то и вообще в спам угодить.

А если я хочу передать доступ к аккаунту кому-то (другу, коллеге)? Мне придется дать доступ к своей почте или менять почту на другую, специально созданную для этого сервиса?

Если разрешите позанудствовать, то "шарить" учетки, как правило, запрещено на любом сайте.


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

интересный подход, однако как по мне, слишком муторно каждый раз лазить в почту, чтобы получить ссылку на необходимый ресурс. сайт по идее все равно будет хранить библиотеку емайлов, похитив которую уже можно совершать спам рассылку и в итоге претензии пользователей все равно будут направлены на обладателя сайта. по мне как будто-то в данной схеме не хватает какого-то звена (не пароля :-) ), но повторюсь подход показался интересным
слишком муторно каждый раз лазить в почту, чтобы получить ссылку на необходимый ресурс
Каждый раз лазить в менеджер паролей чтобы получить пароль ещё более муторно.
могу сказать только про себя — таким сайтом я бы не стал пользоваться. менеджерами паролей не пользуюсь впринципе.
Лучший менеджер паролей — это мозг и/или бумажный блокнотик
Зависит от качеств носителя. :)
Зачем туда лазить? Автозаполнение рулит.
Ну не то, что бы прям рулит (возможность взлома и перехвата), но нажать одну кнопку — точно необременительно. :)
Возможность перехвата там не выше, чем при ручном заполнении, а может даже ниже, так как менеджер паролей может более строго проверять адрес страницы, чем человек.
Выше, выше. Это как с переходом улицы, вроде и зеленый свет, а посмотреть по сторонам все же не повредит. :)
Ну пока что я видел только предупреждение о незащищенной форме, а от митм менеджер вряд ли поможет, это не его профиль же…
Для некоторых категории сайтов (например новостных или любых других «пассивных» ресурсов) может быть достаточно вообще только email. При регистрации авторизация прилетает на почту, регистрировались — подтверждаем. Далее для входа просим полностью указывать зарегистрированный email.
Для «взлома» нужно знать, что пользователь с конкретным адресом почты зарегистрирован на ресурсе. Весь профит, который получит «взломщик» — информацию о том, что я отписан от новостей спорта. Мой же профит в отсутствии необходимости запоминать очередную связку логин / пароль.

Это еще более упрощенный вариант. Но тут прямо на лицо огромная дыра в безопасности. Хотя все зависит от ваших потребностей.

Всецело поддерживаю Art3. Мейлы у всех разные, коллизии пользователей не будет, как в случае, когда выше предлагали оставить только пароль. Т.е. надо разрешить пустой пароль, что означает его отсутствие, а кому важна безопасность, тот пароль введёт.


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


И вообще, кому это надо делать? Большинство из нас на таких сайтах "неуловимые Джо".

Адрес доставки? Добровольно отдать? То есть квартира, где деньги лежат, уже известна злоумышленнику, только ключа и не хватает. :3
Могу ошибаться, но в квартире деньги лежат сейчас только у бабушек и дедушек. У всех остальных они в кошельке и на карточке… Ладно, иногда могу пару тысяч на комоде оставить случайно.
Я два раза писал и потом стирал дополнение «и номер карточки»… Видимо, зря. :3
Ну ладно, но — остальные вещи в квартире — можно и потерять? :)
Вы так говорите, будто в других квартирах вещей не существует )
Науке это не известно. %) Но главное — зачем добровольно рисовать на себе мишень?
НЛО прилетело и опубликовало эту надпись здесь
Поправьте если ошибаюсь, но информация по подписке приходит непосредственно на почтовый ящик, я же говорю о сторонних сайтах.
НЛО прилетело и опубликовало эту надпись здесь

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

Вам не понадобится вводить пароль, если при каждом входе будет производиться новая регистрация.
Славно.
С подобного ресурса я лично сразу проголосую ногами. Точнее удалением закладки.
На большинстве ресурсов у меня разные сложные пароли. Дома они все хранятся в браузере, доступны в любой момент через ctrl+enter. Причём если сайт меня заставляет нажимать ctrl+enter чаще чем раз в ~месяц, то он обычно сразу удаляется из списка посещаемых. Исключение пока только у алиэкспресса, так как аналогов к сожалению нет.
А если я захожу с чужого компьютера, то 10 раз подумаю посещать ли вообще определённые сайты залогиневшись. В 99% случаев этого не требуется (ну я не человек, который не может и дня прожить не отправив минимум 20 сообщений в интернет).
И кстати. Я для регистрации на всяких помойках использую не аккаунты на 10 мин, а просто левые аккаунты с бесплатных сервисов почты, которыми пользуюсь только для регистрации на подобных ресурсах. И которые естественно сразу попадают в спам-листы. Т.е. восстановить пароль при сильном желании можно, но каждый раз туда бегать — увольте. Искать среди 100 писем о том, что я выиграл $100 ссылку на авторизацию – это бред.
Так же не приемлю давать кому-то свой телефон. Даже если тот-же гугль для россиян требует его, то я просто меняю страну обитания, и регистрируюсь без. Во-первых из-за спама, а во-вторых из-за безопасности. Перевыпустить симку и снять с карты все деньги – многим как 2 байта переслать, но для этого надо знать телефон, и быть уверенным, что игра стоит свеч — на карте много денег. Что легко вычисляется по профилю и действиям пользователя.
Так что ни какого смысла менять устоявшуюся систему – нет. Ну кроме как облегчить жизнь разработчику очередного недоресурса, перевалив бремя ответственности на других.
Опа, а я думал, уже для всех эта обязаловка, а для кого еще есть льготы? Для Зимбабве небось? :)
Последний раз сервер Нью-Йорка прокатил. Ну естественно я сказал, что я откуда-то типа Абу-Даби.
Вообще идея простого входа в приложение без каких либо вводов логинов и паролей или авторизаций через сторонние сервисы не нова. Но реализация фактически не возможна, если например говорить о мобильных устройствах… Скажем мы регистрируем не пользователя а его копию программы или его устройство, скажем каким то алгоритмом создающим уникальный токен устройства или копии программы и затем предоставляющий этот токен в качестве ключа для работы с сервером.
Тогда, возникает ряд вопросов… Что делать например, когда юзер на втором устройстве хочет видеть свой аккаунт? Как перенести, незная токена?
Выход, есть, это хранить например этот токен в облачной экосистеме, например если говорить о iOS то хранить например в облаке этот ключ. Но опять же… если у пользователя отключено использование iCloud?
Более того, что будет когда юзер просто удалит приложение и захочет заново получить доступ к своему аккаунту?
Да, и как быть если у юзера несколько аккаунтов на одном устройстве? Как тогда между ними переключаться?
Т.е. выходит что хранить креды в любом случае где то да надо, либо на устройстве (что как я написал выше возможно лишь в исключительных случаях), либо в голове пользователя, либо можно создать пользователю квест зайди туда нажми сюда что выливается в неудобство и потерю времени.
Так что получаем простую формулу: (Быстро… Просто… Надёжно) В ней можно подчеркнуть лишь два критерия, а третий будет как раз всегда в недостатке.
НЛО прилетело и опубликовало эту надпись здесь
Я считаю, напротив, что для входа не нужен email и логин. Только пароль

И как вы предлагаете бороться с входом в чужие эккаунты при ошибке ввода пароля?

НЛО прилетело и опубликовало эту надпись здесь
Т.к. если пароль действительно хороший, шанс такой ошибки будет примерно равен шансу ввести чужой email/логин вместо своего

С чего бы? Во-первых, пара логин/пароль длиннее, чем пароль, во-вторых, логин не случаен.

НЛО прилетело и опубликовало эту надпись здесь
А почему никто не боится, что в каком-нибудь Bitcoin два блока будут иметь одинаковый хеш?

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


в хорошем пароле это должно быть явно не 8-12 байт.

В пароле на 12 символов никак не больше 12 байт (просто потому, что с практической точки зрения пароль покрывается одним байтом на символ).


Можно добавить email/логин в начало или конец пароля.

В этот момент вы получили логин-пароль.


Я против принудительного дополнительного поля, не имеющего под собой технического обоснования

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

НЛО прилетело и опубликовало эту надпись здесь
А повсеместные цифровые подписи, когда подписываются не сами данные, а хеши от них?

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


Но зачем, если можно просто создать хороший пароль?

Что такое "хороший пароль"?


Вы можете объяснить, зачем нужно поле, не имеющее отношения к паролю?

Для идентификации пользователя.


Но откуда Вы знаете, что, например, кто-нибудь не введёт чужой email/логин вместо своего тупо по укурке или неверно попадая по клавишам и не проверяя ввод?

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

Не то, чтобы длина больше, она заранее неизвестна. :) Просто мы как бы множим пространства имен с вводом нового логина. Это может быть и плюсом и минусом.
НЛО прилетело и опубликовало эту надпись здесь
Почему два разных случайных набора данных не могут иметь одинаковый хеш

Могут. Какой от этого вред?


Например, как считаете, какова вероятность, что два разных пользователя придумают пароль, например, такой?

Два разных пользователя из скольких?


А вообще, обычно настоящий ID пользователя является числом, которое даже нельзя поменять и которое зависит только от порядкового номера пользователя на сайте.

… или нет. Но этого никого не волнует вообще.


А что, если я давно сменил свой основной никнейм? Почему нельзя поменять его там же, где пароль?

Иногда можно.


А если можно поменять логин там же, где пароль, то почему нельзя перенести туда все символы из пароля?

Потому что для аутентификации нужно "кто" и "что".


Ниже, чем случайно подобрать длинный и сложный пароль?

Да, если длина пароля одинакова в обоих случаях.

НЛО прилетело и опубликовало эту надпись здесь
Когда цифровая подпись применима к объекту, который автор подписи не подписывал? Даже не знаю…

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


Хоть из 10 миллиардов.

Вы же понимаете, что чем больше людей, тем больше вероятность совпадения?


Хотя я в этом сомневаюсь) Намеренно подобрать возможно, а вот случайно…

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


Суть была в том, что логин ≠ ID.

И что?


Почему иногда, если пароль можно менять часто?

"Иногда" — "на некоторых сервисах". Потому что стоимость смены логина (точнее говоря, публичного идентификатора; стоимость смены частного логина как раз пренебрежимая) достаточно высока.


Всё равно, если пароль был хорошим, никто не подберёт логин — ни случайно, ни намеренно.

Почему "никто"? Есть вероятность, с увеличением числа людей в системе она увеличивается, причем нелинейно (опять возвращаемся к парадоксу дней рождений).


Но она не одинакова же, в варианте с только паролем пароль длиннее.

А откуда вы это взяли? Почему в варианте с только паролем пароль длиннее? Что мешает владельцу связки логин-пароль увеличить длину?

НЛО прилетело и опубликовало эту надпись здесь
Случайность вообще штука интересная… Если рассматривать 1 попытку, то это 50/50 при любой сложности и длине. %)
А если мы про брутфорс (потенциально бесконечный), то это совсем другое.
Чексумма это дополнительная сущность, разве одного хеша не должно быть достаточно?

Чтобы избежать описанной атаки, одного хеша недостаточно.


Какова вероятность для 10ккк?

Лень считать, извините. Приблизительно 1 — e^(-99999999990000000000/2d), где d — число возможных паролей.


То, что для идентификации пользователя, наверное, ему надо указывать свой внутренний ID.

Нет, зачем?


Она случайно не потому высока, что в БД идексируется строка?

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


В таком случае может увеличиться и вероятность подбора пары логин+пароль.

Увеличиться по сравнению с чем?


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

Есть. Вероятность подбора, математически доказанная.


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

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

НЛО прилетело и опубликовало эту надпись здесь
А от какого блока данных берётся чексумма?

От полезной нагрузки.


Ну идентификация же.

Идентификация пользователя не обязательно означает, что он должен назвать внутренний ID.


Кто вообще сказал разработчикам таких систем, что логин и никнейм должен быть одной и той же строкой?

Пользователь, которому неохота помнить две разных.


А раз уж они сэкономили (не очень понятно даже, на чём), то можно (постараться) обновить ссылки за пределами системы.

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


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

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


Многих ли это нынче волнует?

Всех тех, кого вообще волнует сохранность их данных.


Вы уверены, что пользователь со слабым паролем считает его слабым?

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


И совсем другое дело, когда пользоваться слабым паролем становится в принципе невозможно

… это когда они запрещены, да? Как иначе вы этого добьетесь?

НЛО прилетело и опубликовало эту надпись здесь
Хеш сам выполняет роль чексуммы.

Нет, не выполняет. У хэша другая задача.


Разве тот же PGP/GPG считает, например, для MKV-файла чексуммы его потоков?

Думаю, что не считает. Но если вы возьмете другой блоб, который дает коллизию по ЭЦП, то он не будет MKV.


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

Тогда это будет идентификация без аутентификации. Упс.


Зачем ему помнить свой ник?

Чтобы говорить "найди меня на сайте, ник такой-то".


Однако проблема не в только в рассматриваемом сайте, но и во внешнем источнике, не осилившем распарсить страничку профиля, взять оттуда внутренний ID пользователя (который никогда не меняется)

Кто вам сказал, что внутренний ID (а) никогда не меняется и (б) доступен на страничке профиля?


Хотя сайт должен не только хранить ID в профиле, но и предоставить API для получения ника по ID.

Нет, не должен, конечно же. С какой бы радости? Внутренний ID — это внутренняя информация, детали реализации.


А если разработчику лень — ну, можно сделать ссылки на профили без ников, только по ID — это дёшево и сердито.

… и не устраивает пользователя, которому надо диктовать "ф-е-й-с-б-у-к-точка-к-о-м-слеш-один-пять-три-восемь-нувыпоняли".


А можно воспользоваться этими правилами для создания пароля в варианте с только паролем?

Можно. Но вероятность коллизии-то выше, чем если бы был еще и логин.


минимум 2 пользователя могут создать один и тот же пароль, он пройдёт формальную проверку на сложность, а далее после кражи пароля одного пользователя им будет возможно взломать другого

… так для этого надо знать, какого пользователя взламывать. А как это узнать?

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

Не, не "предположим". При правильном подборе чексуммы и хэшфункции это невозможно.


Но главное, что к нему будет применима цифровая подпись, которая ему не предназначалась.

Но поскольку мы знаем, что цифровая подпись применялась к MKV, мы знаем, что произошла подмена, и атака не прошла.


Уже на следующем этапе, найдя пароль ключ доступа в своей БД, сервер получит все нужные ему данные о пользователе.

Это все равно идентификация, без аутентификации.


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

Когда "тогда"? Научитесь уже цитировать, на какую фразу вы отвечаете.


А разве «найди меня по логину» лучше?

Лучше, чем что?


Например, ВКонтактик.

У Вконтактика не меняется. Это личное дело Вконтактик. Другие сервисы не обязаны это гарантировать.


Но мне всё равно, пусть меняется, просто я имел ввиду постоянный ID, который можно использовать (но если он не меняется — зачем множить сущности?). Тогда пусть сайт предоставляет уникальный и постоянный ID пользователя — и всё.

Вот это обычно и есть никнейм. И именно поэтому его нельзя поменять.


Скажем так, я видел это на одном сайте

То, что вы где-то видели, не означает, что все должны так делать.


тут речь о жёсткой связи логина и ника, порождающей неудобства

В обмен на удобства, да. И как-то так решили, что удобства выигрывают.


Почему крайним должен быть тот, кто хочет, чтобы данные для его входа на сайт и его имя на сайте могли быть разными строками?

Потому что он в меньшинстве.


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

Тем самым повысив неудобство. Чем длиннее пароль, тем неудобнее.


Угадать. С такой же вероятностью, с какой у двух пользователей будет одинаковый «сложный» пароль

Эээ, откуда вероятность-то та же? Вероятность одинакового пароля у двух произвольных пользователей считается по парадоксу дней рождений, шанс угадать пользователя, у которого нужный нам пароль — m/n, где n — число пользователей, а m — чиcло пользователей с нужным нам паролем.

НЛО прилетело и опубликовало эту надпись здесь
Всё сводится к сравнению шанса совпадения паролей у двух разных пользователей с шансом совпадения хешей (а теперь ещё и чексумм) двух разных блобов.

Не сводится. Кейсы разные.


Кто будет выяснять, злоумышленник он, переименовавший левые данные в MKV, или пострадавший?

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


OK. А что в этом плохого?

Понижение безопасности.


Лучше, чем просьба найти его по нику, который он не помнит?

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


Как это может быть удобно?

Какое "это"?


Но почему нельзя менять логин?

Потому что разделение ника и логина маловостребовано, а реализацию усложняет.


Вынужден, но не обязан. Под «почему должен» я имел ввиду «почему обязан».

Потому что он в меньшинстве.


Зато поле ввода всего одно.

Это чем-то удобнее? Нет.


ему не составит труда прибавить его к своему паролю, если он не хочет чего-то большего

Составит, потому что ему надо помнить, куда прибавлять. Лишнее усилие.


Вообще, вероятность подобрать логин даже выше, т.к. логин имеет определённую длину и после него не следует ничего

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


а когда он часть ключа, то после него сразу идёт начало пароля. И попробуй понять, у пользователя ник «user» и пароль «123456» или же ник «user123» и пароль «456»

Понимаете, да, что это на самом деле уязвимость, а не достоинство?

Да, это к тому же накладывает дополнительное требование на минимальное расстояние редактирования (расстояние Левенштейна) между двумя паролями, что во сто крат хуже обычного требования на длину пароля. Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?


Да и при использовании тривиальных схем хэширования у нас есть шанс появления паролей-коллизий, не привязанных ни к одному email.

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

Вы стоимость этой операции представляете?

НЛО прилетело и опубликовало эту надпись здесь

Эээ… нет. Тут в посте уже обсуждалось, что для входа вам нужно посчитать хэш единожды, а для проверки уникальности — столько раз, сколько пользователей (потому что хэш для каждого пользователя считается с разной солью).

НЛО прилетело и опубликовало эту надпись здесь

Какой тогда смысл этой соли? Можно ее выкинуть с тем же успехом.

Ну в теории против радуги, но тут проблемы с радугой далеко не на первом месте. %)

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

Ну, это не особо отличается от просто брутфорса. :) Ведь сила таблиц в том, что их можно заранее просчитать и потом переиспользовать.

Все-таки малость отличается: когда можно каждый сгенеренный хэш прогонять по всем пользователям сайта "а вдруг подойдет" — это ощутимо выгоднее, чем для каждого пользователя пересчитывать.

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

Мы на уникальность проверяем внутри одного сайта, другие нас не интересуют. Вы понимаете, что использование одной соли для всех паролей сайта — это снижение защищенности?

Это решаемо. Например, когда пользователь устанавливает пароль (при регистрации или меняет старый), можно проверять, не используется ли хеш пароля другим аккаунтом. Правда, придётся предупреждать и владельца другого аккаунта (и принять временные меры для его защиты) =)

Во-первых, это затратно для баз с большим кол-вом пользователей. Тем более для распределенных
Во-вторых речь шла о рисках "похожести" двух паролей когда пользователь хочет ввести feezbuzz, но ошибается и вводит fezbuzz, и логинится под другим аккаунтом. Вот как раз наличие дополнительного user id (еmail или обычный логин) нивелирует этот риск

НЛО прилетело и опубликовало эту надпись здесь
Есть такое, но разве бинарное дерево поиска не решает эту проблему?

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


(кстати, это еще одно простое техническое объяснение того, почему-таки нельзя использовать просто один пароль — как вы определите, какую соль использовать?)

НЛО прилетело и опубликовало эту надпись здесь
Не должен. С чего Вы взяли, что должен?

С того, что иначе при краже БД можно, зная пароль одного пользователя, залогиниться под всеми пользователями, у которых совпадает хэш.

НЛО прилетело и опубликовало эту надпись здесь
Но ведь у всех должны быть разные пароли.

Пароли разные, хэш внезапно одинаковый. Правда, печаль?


(ну ладно, при разумной длине хэша это чрезвычайно маловероятно, н все же)


Но даже если на это забить, анализ украденной БД с хэшами резко упрощается.

НЛО прилетело и опубликовало эту надпись здесь
Я не против, если Вы уменьшите вероятность коллизии при разных паролях до 0%.

Афаик, это невозможно.


Но ведь при хешировании в качестве «соли» (или её части, если нужно) используется имя сайта, которое больше нигде не используется.

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

Вероятность коллизии ноль = логин.
%)
Есть такое, но разве бинарное дерево поиска не решает эту проблему?

Скорее не бинарное, а 2-3-4 дерево, но это так — технические подробности.


Что касается распределённых, то разве нельзя держать копии на всех машинах

И получить головную боль в виде поддержки консистентности данных пользователей?


Но если пользователи используют действительно уникальные пароли, а не «feezbuzz» — что там может совпасть? -_-

Это все скорее слишком оптимистичные сценарии, не все готовы хранить и запоминать пароли на 64+ символа с равным соотношением спец. символов, цифр, букв, и уж тем более еще меньший процент готов приводить свои пароли в соотвествие с техническими рекомендациями по безопасности. Чаще запоминают мнемонические пароли, или пароли как ответы на вопросы (день рождения, имя жены, домашнего животного, и.т.д)

>> Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)
НЛО прилетело и опубликовало эту надпись здесь
Скорее, я надеюсь, что пользователь, ознакомившись с принципом авторизации, придумает действительно надёжный пароль.

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

НЛО прилетело и опубликовало эту надпись здесь
Однако является ли это проблемой?

Ну да, это неудобно пользователю.

НЛО прилетело и опубликовало эту надпись здесь

Это неудобно. Более того, это упрощает словарные атаки.

НЛО прилетело и опубликовало эту надпись здесь

Но и не менее неудобно. Зачем мне решение, которое не приносит пользы?

НЛО прилетело и опубликовало эту надпись здесь
Представьте, что вы подошли к торговцу/за́мку/чему-то ещё и должны назвать секретное слово, которое сообщили только Вам и его знаете только Вы, и тогда на Вас снизойдут всякие бонусы.

Одноразовое?


Но ведь если кодовое слово длинное и угадать его затруднительно, проблемы нет, не так ли?

Проблема есть — мне надо это слово запомнить.

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

Для одноразовых бонусов разницы нет.


А вообще мог бы быть и многоразовым.

А для многоразовых начинаются проблемы безопасности.


А как же запоминание пароля?

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

Не в ту сторону думали. :) НЕЛЬЗЯ отказаться от логина, только от пароля. Либо все будут анонимы.
НЛО прилетело и опубликовало эту надпись здесь
Суть в том, что анонимам не нужны логины и пароли в принципе. :) Любая попытка разделить пользователей — это уже логин. С паролем или без.
НЛО прилетело и опубликовало эту надпись здесь
Он неосуществим. :) Можно только «играть» в анонимов, если сервер просто не будет показывать имена, читай — логины. Но так надо определиться, со стороны системы анонимность или пользователя.
НЛО прилетело и опубликовало эту надпись здесь
Ну и вот, хорошо, что пришли к понятию идентификации наконец. :)
Теперь можно заменить слова логин и пароль на ИД и ключ и на этом успокоиться. Или нет? :)
НЛО прилетело и опубликовало эту надпись здесь
Вот! Вот он — яяязь главный вопрос — почему он должен помнить? Для решения этого вопроса и существуют менеджеры. :)
Теперь осталось только осознать, что ИД и «пароль без логина» — одно и то же. :3
НЛО прилетело и опубликовало эту надпись здесь
Но… нормальные сайты так и делают. :)

Кому трудно? ИД в любом случае постоянный. И еще раз: нет никакого пароля без логина, это и есть ИД. %) И если ИД менять, то это просто новая регистрация. Те же проблемы, что и со сменой логина, или большие.

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

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

Оу, до меня только сейчас дошло. Вот отправляется на сервер пароль в хешированном виде. А что с ним дальше происходит?

НЛО прилетело и опубликовало эту надпись здесь
то надо по этому хешу найти пользователя

Каким образом? Вот конкретно, прямо по шагам: у нас есть сервер, ему прилетел с клиента хеш пользовательского пароля. Что сервер делает дальше?

НЛО прилетело и опубликовало эту надпись здесь

Омг. Вы понимаете, что этот ваш "хеш" — это на самом деле простой пароль (не важно, как пользователь его получил), и ваш сервер хранит его в БД в открытом виде? А это значит, что одна утечка БД — и можно залогиниться на сайт под любым пользователем вообще.

НЛО прилетело и опубликовало эту надпись здесь

Радужная таблица радостно возвращает нас к открытым паролям.

НЛО прилетело и опубликовало эту надпись здесь

А зачем своя для каждого сайта? У вас тривиальное H(data), радужная таблица для H достаточна.

НЛО прилетело и опубликовало эту надпись здесь

Это не важно. С точки зрения сервера приходит готовый ключ data. Как он сформирован — не важно, и злоумышленник может сразу передавать этот ключ, не заморачиваясь поиском пользовательского пароля. Поэтому на уровене сервера у вас обычные несоленые хэши, со всеми вытекающими.

НЛО прилетело и опубликовало эту надпись здесь
Серверная соль уже может быть уникальной для каждого пользователя

Каким образом, если вы пользователя не знаете?


(а если она неуникальна, то возвращаемся к пониженной криптостойкости)

НЛО прилетело и опубликовало эту надпись здесь
А разве нельзя иметь на сервере соль, одинаковую для всех пользователей, но которую знает только сервер?

Нельзя. Все, что доступно серверу, может быть украдено.


На какое время заполнения таблицы Вы рассчитываете?

Так прикол в том, что нам не надо заполнять таблицу целиком (если мы, конечно, не делаем атаку на конкретного пользователя). Мы просто начинаем генерить ее с нуля, и для каждого варианта сразу проверяем, есть ли он хотя бы у какого-нибудь пользователя. Есть — ура, у нас есть одна жертва. И так далее.


И почему бы просто не увеличить вычислительную сложность хеширования пароля (в адеква