Комментарии 500
В таком случае на почтовые сервисы ляжет двойная ответственность.
А вообще, концепция имеет место быть, тоже задумывался о таком.
А на них и так вся ответственность. Если у вас предусмотрен сброс пароля, считайте у вас и нет нужды в нем.
Если у вас предусмотрен сброс пароля, считайте у вас и нет нужды в нем.
Сброс пароля бывает не только через почту.
А еще есть разница между "открыть сайт, нажать кнопку ввода пароля, войти" и "открыть сайт, нажать кнопку, пойти в почту, нажать ссылку, войти".
Бесспорно, этот путь длиннее. Но если на сайте достаточно длинные сессии, то, думаю, это может нивелировать данный минус.
Но если на сайте достаточно длинные сессии, то, думаю, это может нивелировать данный минус.
Не может. Все равно необоснованно много операций ради чего?
Ради отказа от бесконечного количества паролей и их менеджеров. Просто другой путь.
Вы так говорите, как будто пароль в почту не надо менеджить (а если на него все завязано, то ведь его надо менеджить еще сильнее).
Что вы понимаете под менеджментом пароля для почты? Я говорил о программах-менеджерах, которые генерируют и хранят ваши пароли от учетных записей.
А пароль от почты, да, его действительно нужно хранить очень и очень сильно, независимо ни от чего. Т.к. в текущем положении дел, он является мастер паролем (из-за возможности сбросить пароль учетной записи на сайтах, зарегистрированных на эту почту).
Что вы понимаете под менеджментом пароля для почты? Я говорил о программах-менеджерах, которые генерируют и хранят ваши пароли от учетных записей.
Вот про это я и говорю. Пароль от почты же тоже надо где-то хранить; особенно учитывая, что это не единственный пароль, который надо хранить. Так что менеджер все равно нужен. А если он есть, то уже не важно, сколько паролей хранить.
Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.
Но эта проблема проста для программистов и серьезных пользователей. А вот подавляющее большинство использует незамысловатые комбинации, и, вероятно, используют один пароль везде. И вот в этом случае, безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты, и хотябы.
Но оба подхода не спасут ни от стикера на мониторе, ни от masha123456.
Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.
Во-первых, пока вы его запоминаете, он все равно должен где-то храниться. Во-вторых, это работает только для часто используемых паролей. В-третьих, я не доверяю своей памяти настолько, чтобы внезапно потерять доступ к интернет-банку.
И вот в этом случае, безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты, и хотябы.
А почему вы думаете, что у такого пользователя будет сильный пароль на почту?
А почему вы думаете, что у такого пользователя будет сильный пароль на почту?
Да я и не думаю так, но так есть хоть какая-то надежда обезопасить такого гражданина.
Если у него слабый пароль на почту, то принудительно привязав сервисы к почте вы его не обезопасили, а наоборот.
Ну раз мы рассматриваем такого пользователя, давайте уж будем честны, он использует свою реальную (единственную) почту. Тут уже никто не поможет.
Но ухудшать-то зачем? Если на нашем сервисе сильные требования к паролям и нет возможности восстановления через почту — нам искренне пофиг, насколько слабый пароль у пользователя на почту.
Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.
А практика с "ваш пароль недостаточна сильный", я считаю одним из проявлений садизма.
Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.
Пусть дергает. Это лучше, чем потеря критических данных.
А практика с "ваш пароль недостаточна сильный", я считаю одним из проявления садизма.
Если вы можете себе позволить выдавать каждому пользователю (безотказное) устройство генерации одноразовых кодов с биометрической аутентификацией — то можете не ограничивать сложность паролей. А иначе вам как-то придется бороться со слабыми паролями.
Вопрос ведь в критериях сильного пароля, а не в самой практике.
Пусть дергает. Это лучше, чем потеря критических данных.
Очень спорное высказывание, т.к. зависит от множества факторов.
А иначе вам как-то придется бороться со слабыми паролями.
А зачем, пользователь все равно найдет как его "подарить".
Мне кажется, мы с вами уже уперлись в тупик обсуждения. Мне абсолютна ясна ваша позиция, и я надеюсь, что вы хотя бы допускаете, что моя теория имеет место быть.
Во всяком случае, мне было очень приятно с вами подискутировать, и обсудить возможные недостатки предложенной выше системы.
Если вы не против, продолжим завтра.
А пока, хорошего воскресения, и добрых снов :).
А иначе вам как-то придется бороться со слабыми паролями.
А зачем, пользователь все равно найдет как его "подарить".
То есть ваш подход — это всего лишь прикрытие собственной задницы перед начальством или заказчиком, когда поломают вашего пользователя, — мы не виноваты, пользователь проэ… мотал не наш пароль, а почтовый.
Не решение проблемы, а просто спихивание ответственности.
Очень спорное высказывание, т.к. зависит от множества факторов.
Есть ситуации, когда обращение в саппорт лучше, чем потеря данных из-за компроментации емейла.
А зачем, пользователь все равно найдет как его "подарить".
Чтобы избежать тривиальных ошибок.
Пусть дергает. Это лучше, чем потеря критических данных.
Да, помню эту историю.
Чувак потом рассказывал что он потерял фотографии своей дочки из-за того что кто-то сумел уболтать саппорт и получить доступ к его эпловой учётке.
Если же ориентироваться на длинную сессию в почте, то такой же подход можно применить и на сайте.
У нас на одном из сервисов сессия сохраняется более суток и подавляющему большинству пользователей не приходится часто вводить пароли.
Такой подход, возможно, больше подходит для временных аккаунтов или там, где нет необходимости в регистрации.
Вы же забываете, что пользователю в общем случае не сложно придумать и потом вводить пароль. И не сложно его запомнить. Знаете почему? Потому что пароль к вашему сайту у него в подавляющем большинстве случаев будет такой же, как и ко всем другим аналогичным сайтам, и вполне вероятно, к его почте и онлайн-банкингу. А вы вместо того, чтобы вводить привычное слово, предлагаете пользователям квест «зайди в почту, найди наше письмо, открой письмо, перейди по ссылке. И желательно потом не забудь удалить письмо»
Сервисы, любящие ставить куки на две недели, это отдельная беда, конечно.
Хотя вечные куки — это проблема на компьютере коллективного пользования.
А какая разница будет кука на 15 минут или на 100 лет, если через минуту за комп может сесть другой человек? Для девайсов коллективного пользования должна быть хорошо заметная кнопка "выйти".
Очень не удобно на девайсе личного пользования.
И этот выбор должен настраиваться так, что при заходе с нового устройства надо заново выставить опцию «хранить куки и после закрытия браузера». А по умолчанию на каждом новом устройстве куки хранятся до закрытия — независимо от того, какой выбор я делал на других устройствах, где работал раньше.
В целом неплохая система как мне кажется, а раз уж такая крупная и связанная с деньгами компания ее использует — это повод как минимум подумать и посмотреть на нее внимательнее.
неплохая
ага XD
раз уж такая крупная
ага XDXDXDXD
Плюс СмС перехватить можно.
Но это если уже совсем ударяться в паранойю.
Что касается конкретно данного случая, защита по смс — один из наименее безопасных вариантов из всех возможных. Получается, компания крупная, а защита минимальная.
Хотя если отслеживается перевыпуск карты, уже не совсем ужасная защита (без этого это даже защитой нельзя считать в принципе, т. к. защита минимальна), но всё-равно, это явно не то решение, на которое нужно равняться.
За что мне поставили 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, а там хрен вам, а не мобильное покрытие. А вот проводочек протянут.
Наличные деньги в сумке или потайном кармане всегда безопасней карты
Очевидно, нет. Объяснять надо?
Вот вы попробуйте попользоваться, когда вы находитесь в зарубежной поездке без вай-фая и сотового интернета, узнаете много интересного.
Если не секрет, что это за интернет-кафе такое, где нет возможности подключить смартфон по вайфаю?
Обычный принт-шоп в Севилье, неподалеку от Архива Индий.
Ну вот мой пример: перед походом в принтшоп в Петрозаводске, я залил нужный мне файл на флэшку и в интернет.
Придя в принтшоп я просто продиктовал адрес и они скачали мой файл. Флэшка не понадобилась.
Вводить какие либо пароли на их компьютерах — не понадобилось.
А какой Ваш кейс, если не секрет?
Ниже уже описал. Отличие от вашего в том, что файл не был публично доступен, поэтому я не мог продиктовать адрес.
Автор, который утверждает, что пользователям не нужны пароли.
Видимо мы не знакомы с автором, ведь я в начале статьи явно сказал "возможно не нужны", а в конце развернуто перечислили кому эта функция могла бы быть полезна, а кому напротив.
Если вы не дорожите — какая разница, скомпрометирован ли компьютер.
Я не дорожу данными сервиса, куда логинюсь с общего компьютера, но дорожу почтой.
И входя через Auth вы как раз меньше рискуете, т.к. логгер запишет временный код.
Через OTP — да, меньше рискую. Но речь в примере шла не про OTP, а про логин через почту.
Да, почему может случиться потеря эккаунта.Email это ключ к восстановлению пароля. Если вы при регистрации использовался «одноразовый email», то восстановить пароль в случае утери будет не возможно.
Кроме того часть функционала сайта может быть не доступна без доступа к электронной почте (рассылки, уведомления и т. д.).
Email это ключ к восстановлению пароля. Если вы при регистрации использовался «одноразовый email», то восстановить пароль в случае утери будет не возможно.
Ну и пофиг, я вполне способен сам следить за своими паролями.
Кроме того часть функционала сайта может быть не доступна без доступа к электронной почте (рассылки, уведомления и т. д.).
Это меня тоже может не волновать.
он наверно имеет ввиду сервисы которые генерируют временные ящики на 10 минут и тем самым он юзает их для регистрации не светя свой настоящий email.
и второй раз получить к тому же временному email очень мало вероятно
Для чужого компьютера это не имеет значения.
я уж молчу о том, что я не на каждом сайте хотел бы светить свой емейл
Светить username+spamsite112@gmail.com и получать по факту почту на username@gmail.com не подходит под это описание?
Не подходит. Во-первых, не у всех гмейл (а у тех, у кого гмейл, есть OpenId Connect, и им вся эта фигня с логином через емейл не нужна бы), а во-вторых, это все равно позволяет связать ящики.
Sendmail такое из коробки поддерживает, вроде как — так что привязки к Gmail особой нет. А про связь ящиков — тут уж смотря какие цели. Если цель — увести основное никому не известное мыло от направленной атаки — тогда да. Но и в таком случае можно создать ширпотребный ящик и использовать теги уже на нём :)
Цель — не светить свою идентичность и усложнить связь учеток на разных сервисах друг с другом.
Интересно: тут либо на каждый сервис/сайт регистрировать свою почту, чтобы «усложнить связь учеток на разных сервисах друг с другом», но это быстро надоест
Если надоест, значит не так уж и важно.
Либо если сайт требует регистрацию по мобильному номеру, то как тут быть?
Я без идей. Кто-то как-то говорил, что найти сервисы, имитирующие номера для смс тоже можно.
На самом деле есть вариант объединить преимущества обоих подходов:
1) При регистрации попросить-таки придумать пароль, как обычно
2) При логине требовать емейл
3) Дальше предлагать либо ввести пароль либо подтверждение на почту
Все старые юзкейсы работают, но если обычный пользователь забыл пароль или не хочет париться его вспоминать-вводить, пользуется подтверждением.
Чем это (радикально) отличается от обычного "сброса пароля по почте"?
Тем же, чем iPhone 1 от HTC touch :) Радикально ничем, но удобнее гораздо.
Сброс пароля заставляет вводить новый пароль, у самых умных ещё "пароль не может совпадать со старым". Новый пароль точно так же забывается когда заходишь ещё раз на сайт ещё через год.
Ну и заходить на сайт каждый раз через сброс пароля лютое неудобство и костыляторство, а тут как бы альтернативный способ: хочешь — заходи.
Сброс пароля заставляет вводить новый пароль, у самых умных ещё "пароль не может совпадать со старым".
Это если "сброс пароля" требует ввода нового пароля, а не делает автологин. Такие решения уже есть.
Впрочем, будем честными, этот описанный вами вариант реализован, например, в Slack — и вот я вам честно скажу, у меня он работает в половине случаев, а в половине глючит. А пароль работает всегда.
То есть:
- у Вас есть потребность в интернете
- у Вас есть электронная почта
- при этом, у Вас нет смартфона и Вы где-то нашли интернет-кафе
Кто Вы, и как попали в наше время?
Вы серьезно никогда в местах без сотового покрытия не были?
У меня смартфон-то есть, только сотового интернета нет. И дело было буквально года три назад в милом городе Севилье. И год назад на Койя-сан. И в этом году в Порткарно.
Не могли бы Вы в точности описать решаемую Вами задачу?
А то выглядит так, что Вы хотите зайти в интернет-банк с компьютера которому не доверяете, и при этом получить смс код в местности где нет сотовой связи.
Это какой-то очень интересный кейс.
Я, как человек много путешествующий по всяким жопеням России и Европы, хотел бы понять что это за интересная ситуация и подготовиться к ней.
Омг, да все же просто, как валенок.
Есть билет, купленный онлайн. Чтобы пройти по билету, нужна распечатка (нет, показать с устройства нельзя; и все равно на устройстве билета нет). Билет лежит в pdf в дропбоксе. Сотового интернета нет, потому что нет (вплоть до отсутствия сотовой связи вообще, так тоже бывает). Приходим в принт-шоп, у них есть компьютер, подключенный к интернету (как раз для кейсов "распечатайте мне из интернета"). Заходим в дропбокс (там пароль и 2FA, пароль в менеджере на смартфоне, 2FA в приложении на смартфоне), скачиваем файл, отдаем на печать, все.
В случае с онлайн-банкингом все то же самое, только сотовая связь есть, а сотового интернета нет (у меня так в Китае было).
пришел к подобному подходу довольно давно есть пару замечаний по таблице sign_in_requests:
- Колонку email заменить на users_id (связь по primarykey как то более привычно).
- Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).
- Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену
- Колонка requestIp в реальности бесполезна (если только не супер строгая система, но там такой подход вообще не подойдет).
- Добавляю колонку 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 (и даже не обязательно пароль).
И безопасно и помнить не нужно. Тогда и пароль нафиг не нужен. И нет необходимости в каждом интернет-кафе почту дёргать. А уж критические изменения подтверждать по е-майл.
И безопасно и помнить не нужно.
Небезопасно. Украли устройство — получили доступ.
А если устройство отказало — доступ не получит даже владелец.
Не будем драматизировать.
Это не "драматизировать", это реальные проблемы. Кому-то может быть на них положить, так бывает. Но не всем.
Во-первых я указал что критичные изменения подтверждаются по е-мейл.
Доступном на том же устройстве, да?
Во-вторых — если вы забыли пароль (равноценно утере девайса) — всё равно в тот же е-мейл для восстановления полезете
Это если восстановление через емейл.
В общем идея хороша, и всяко девайс угнать обычно сложнее, чем пароль.
Да нет, просто забрал со стола и все.
Email, имя и еще какие-то данные могут спрашиваться при регистрации и использоваться, например для рассылки уведомлений, но при авторизации спрашивать только пароль. Да, пароли у всех должны быть одинаковые, потому-что автогенерируемые.
P.S. Пытался опубликовать заметку на эту тему на хабре, хотя суть укладывается в одном предложении.
для авторизации на сайте предлагаем ввести пользователю только пароль. Действительно, зачем при авторизации нужен логин?
Чтобы исключить ситуации, когда пароли совпадают.
(еще чтобы усложнить перебор, конечно же)
пароли и должны быть у всех разные. если они настолько просты, что совпадают — сам себе злобный буратино.
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
На счет одинаковых паролей, просто хочу показать, что подход с одним паролем ничем от логина и пароля не отличается, только это удобнее.
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.
Соль или должна быть одна, общая, или генерироваться из пароля.
А вы уверены, что у вас криптографическая стойкость от этого не упадет? По идее, должна бы.
На счет одинаковых паролей, просто хочу показать, что подход с одним паролем ничем от логина и пароля не отличается, только это удобнее.
Ничем не отличается? Как вы защититесь от ситуации "ошибся в одном символе пароля, попал в чужую учетку"?
Т.е. тупым перебором можно подобрать всю базу аккаунтов.
Если у сервера есть логин, то перебор пароля пресекается после N неудачных попыток входа в этот аккаунт — все остальные работают. Если у Вас только пароль, то можно бесконечно долго подбирать пароли — Вы не можете пресечь эти попытки, только положив весь сервер.
Тем более, что с брутом пароля к аккаунту на веб-сервисе все-таки есть некоторые возможности ограничить попытки брутфорса, например по ip.
И еще, я не предлагал использовать эту систему для всего, например для денежных операций. Мне кажется для различных сервисов должны использоваться разные подходы. Я скорее про те сервисы, брутить пароли для которых никому особо и не нужно (в смысле не стоит стоимости этого самого брута).
В случае с сервисом злоумышленник может подобрать все пароли или большую часть. Особенно, если ему все равно какой аккаунт взламывать.
И еще, что если злоумышленник уже как-то слил базу с хешами и теперь ему нужно подобрать пароль к хешам.
Интересно кстати, никто еще не придумал делать табличку с хешами пользователей общедоступной?
Опять же на первый взгляд может показаться дикостью, с другой стороны можно привести аналогию с шифрованием по типу «черного ящика» и нормальным шифрованием, когда известно как шифруется и зашифрованные данные общедоступны, но расшифровать их не так-то просто.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
представьте, что пароль у вас — это склеенные email и пароль.
Представил. Чем это теперь отличается от введенного логина и пароля? Тем, что все в одном поле?
пароли и должны быть у всех разные
Ну то есть надо будет взять какой-нибудь аналог GUID, с криптографической случайностью? Вот эти пароли и правда только в менеджере хранить, а тогда уже нет разницы, сколько полей вводить.
(защита от перебора все равно усложняется)
Мысль использовать только пароль, конечно, может показаться дикой, но только сначала.
У сброса пароля через почту всё-таки есть одна дополнительная фича — хоть взломщик и получит таким образом доступ к аккаунту (если у него уже есть доступ к почте), но владелец аккаунта тоже узнает о взломе — ведь взломщик не знает старый пароль и не сможет его восстановить, даже если другие следы (письмо со ссылкой сброса пароля) он сможет подчистить.
Что касается большого срока жизни сессии — какая разница, надо вводить пароль или нет, если это надо делать раз в год?
Ну и последнее, про менеджеры паролей. По-хорошему, если уж Вы заботитесь о безопасности пользователей, то нужно наоборот, приучать и стимулировать использовать менеджеры паролей. Что касается сложности в использовании — то с тем же KeePass всё наоборот намного проще, чем в Вашей схеме — когда я вижу форму логина на сайте я нажимаю Ctrl-Alt-A и… всё. KeePass сам определяет что это за сайт, сам вводит логин/пароль или что на этом сайте нужно, и сам отправляет форму. Так что вся "сложность" использования менеджера паролей заключается в однократном добавлении записи о новом сайте при регистрации (с процессом которой KeePass так же помогает генерируя пароль).
Я в курсе. И? К чему Вы это сказали?
А! В смысле, они высылают не новый случайный пароль (что тоже плохо, особенно если при этом старый пароль удаляется), а текущий пароль? Т.е. хранят пароль без хеширования, помимо прочего. Ну, что тут скажешь, в таких веб-магазинах надо голосовать рублём, удаляя аккаунт и отправляя письмо по всем доступным email-ам руководства, объясняя почему дальнейшее использование их веб-магазина не представляется возможным.
Идея-то может и хорошая (избавиться от множества паролей), но вот реализация…
Тут можно провести две аналогии:
- Это OAuth. Но не OAuth, а хуже. Потому что это просто почта. Кэп доволен. %)
безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты
Это менеджер паролей. Потому что в итоге — все равно нужен один пароль. Но это хуже менеджера паролей, потому что… ну вы поняли. %)
В обоих случаях есть общая черта — мы используем почту не по назначению, отсюда огребаем косяки с пограничными случаями и удобством. Отсюда вывод — надо использовать менеджеры паролей, потому что они ради этого и придуманы! Минус только один — менеджер паролей есть не у всех, и он не стандартизован (так, как почта). Хотя, с момента распространения соцсетей и смартфонов, и почты, вероятно, у кого-то уже может не быть… но это уже не проблема запоминания паролей.
И да, есть еще вариант — ключ. Это можно считать за длинный незапоминаемый логин+пароль, если угодно. Или просто хардварный ключ.
Такие дела. :)
К счастью, пока что все основные сервисы предоставляют POP3. Плюс можно зарегать собственный домен чтобы ни от кого не зависеть. Тогда все письма будут скачиваться на личный комп и аккуратно бэкапиться в зашифрованном архиве в облако. С другой стороны, домен, наверное, тоже могут отобрать… как страшно жить, да.
Некоторые делают: webmoney, startssl. Геморроя с этими сертификатами — море. Нет, после регистрации всё неплохо, сертификат установлен в браузер и дальше логиниться несложно. Но чтобы не остаться без доступа приходится из браузера этот сертификат выковыривать, сохранять в отдельный файл, при этом его шифруя паролем (который ещё нужно добавить в менеджер паролей, угу), импортировать его в другие свои браузеры (а что, если доступ нужен с чужого компа, кстати?) и потом ещё не забывать обновлять эти сертификаты (во всех браузерах, чтобы не скучно было) раз в 1-3 года. Спасибо, но нет!
Это и в самом деле очень удобный и правильный метод авторизации для не критичных сервисов. Единственно что для решения ситуации со сломанной почтой я бы оставил как альтернативу традиционный вход.
Вообще, если посмотреть на все крупные сайты, сейчас уже нормой является привязка авторизации к браузеру через куки или локальное хранилище, что принципиально ничуть не безопаснее вашего вашего метода.
Увеличивается время входа на сайт.
Вы имеете ввиду время сессии / срок действия cookie?
Плюс многие сейчас почту только на телефоне читают, а пароль от почты могут даже не помнить. И им тогда придётся ручками ссылку вбивать. Лучше уж цифровой код присылать. Ну или и то и другое сразу.
В общем, хуже только вход на сайты через соцсети устроен, когда тыкаешь «войти через фэйсбук», а тебя, после подтверждения доступа на фэйсбуке, кидают на форму регистрации на самом сайте. Нахрена тогда вообще фэйсбук тут нужен был?
Одно из возможных решений, это использовать OAuth 2.0, но не у всех пользователей может быть аккаунт в социальной сети и желание его использовать на вашем ресурсе.
А что мешает использовать несколько способов аутентификации? Кто хочет, тыкает «войти через facebook» и логинится через него, кто хочет — регистрируется через логин-пароль и использует их для входа на сайт? Как вариант, можно даже руководствоваться таким принципом: если соцсеть отдаёт е-мейл, привязанный к учётной записи, то считать, что соцсеть уже подтвердила принадлежность этого адреса владельцу (но предварительно проверить используемые соцсети, что они действительно проверяют при привязке почту, а не разрешают забить туда любой адрес безо всякой проверки)
Я, скорее всего, зайду на сайт, введу свой мейл и… А пароль вводить? Ощущение, что на меня хотят повесить e-mail-рассылку (так, по сути, и есть, если задуматься), как-то подозрительно это, и, скорее всего, я просто покину сайт. Минус пользователь.
Пол беды. Допустим, я об этом не задумался.
Захожу на сайт, ввожу мейл, радостно тыкаю кнопку входа… И оно мне сообщает, что нужно что-то там открывать и что-то там тыкать… Ой, Господи, ну его нафиг. И просто закрою вкладку.
Ладно, это я к чему. К тому, что хоть эта схема и придумана для самых непродвинутых пользователей, именно их она и отпугнет от использования сайта, я считаю. А нормальные люди используют менеджеры паролей. Поэтому, отток пользователей после введения такой системы входа не был бы чем-то странным, по-моему.
Как я сказал в заключении, этот подход непривычен. Но никто не мешает вам рассказать пользователям, как пользоваться такой "фичей".
К примеру, сделать галочку "я не хочу использовать пароль". А остальное дело времени и выработки рефлексов.
На практике это будет выглядеть немного по-другому. Ты зарегистрируешься в сервисе и подтвердишь свою почту, перейдя по ссылке из письма. После перехода получишь вечную куку и больше авторизовываться тебе уже не нужно. Это ничем не отличается от обычной регистрации.
эх, раньше как было. на мэйлру завел почту в 99 году. пароль был всего 3 цифры.
Хотя, идея с отказом от пароля выглядит дико и непривычно,Вообще этой идее как миниму лет пять. И даже есть реализации для фрейворков и CMS.
nopassword.alexsmolen.com
— Вы перекладываете написание/сопровождение аутентификатора на сторонний сервис
— Вашим пользователям не нужны пароли у них есть почта/sms
Из минусов:
— Для входа на ваш ресурс необходимо войти/проследовать в зависимый сервис
— В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Относительного последнего пункта есть оговорка, пользователь может для каждого аккаунта заводить отдельный ящик,…
но как бы проще тогда уже просто, регистрация с логином паролем и все счастливы…
Послесловие: я не считаю данный подход ущербным, но напоминаю что убирать пароль совсем, это тоже плохая идея, оставляйте хотя-бы на тот случай если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).
Спасибо за внимание…
вы перекладываете «сервис аутентификации» на сторонний ресурс
Так это и прекрасно. Зачем моему сайту с котиками хранить пароли от пользователей, которые могут только комментировать.
В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Да, ровно как и сейчас. Если у вас взломали почту — то вы потеряете и доступ к большей части сайтов вместе с ней. Т.к. "ресет пароля".
если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).
К сожалению, опять же, большинство сервисов не позволят вам сменить почту / телефон, пока вы не зайдете в старую, и не подтвердите смену.
В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсыТак ведь и при обычном способое взломщик может получить доступ ко всем привязанным аккаунтам через востановление пароля.
Владелец сайта при создании/внедрении алгоритма восстановления пароля должен учитывать что почта может быть взломана (привет «Секретные вопросы» например)
Секретные вопросы
Еще один излюбленный инструмент садиста. Я с большей долей вероятности забуду "Имя первой учительницы", чем сгенерерованный 64'ех символьный пароль.
P.s. менеджер секретных вопросов может стать неплохим стартапом.
P.S. Другой вопрос OAuth. Вот это конечно удобная штука.
У меня почта первый ссылается и собирается в один ящик, и это поисходит не быстро. Вижу минус в том, что входа на сайт, мне придётся ждать от 2 и более минут, пока дойдёт мэйл авторизации.
А если я хочу передать доступ к аккаунту кому-то (другу, коллеге)? Мне придется дать доступ к своей почте или менять почту на другую, специально созданную для этого сервиса?
слишком муторно каждый раз лазить в почту, чтобы получить ссылку на необходимый ресурсКаждый раз лазить в менеджер паролей чтобы получить пароль ещё более муторно.
Для «взлома» нужно знать, что пользователь с конкретным адресом почты зарегистрирован на ресурсе. Весь профит, который получит «взломщик» — информацию о том, что я отписан от новостей спорта. Мой же профит в отсутствии необходимости запоминать очередную связку логин / пароль.
Это еще более упрощенный вариант. Но тут прямо на лицо огромная дыра в безопасности. Хотя все зависит от ваших потребностей.
Всецело поддерживаю Art3. Мейлы у всех разные, коллизии пользователей не будет, как в случае, когда выше предлагали оставить только пароль. Т.е. надо разрешить пустой пароль, что означает его отсутствие, а кому важна безопасность, тот пароль введёт.
Мы ведь пользуемся кучей не критичных сайтов, где просто хотим, чтобы сайт нас "узнал". Меня не волнует, что в интернет-магазине кто-то случайно или со зла зайдёт в аккаунт и узнает, какой кошачий корм я заказала и адрес доставки. Да и пожалуйста. Пакости типа отмены заказа я узнаюю по смс-уведомлениями магазина.
И вообще, кому это надо делать? Большинство из нас на таких сайтах "неуловимые Джо".
Информация, которую получит взломщик, позволит ему подписать Вас на рассылку, например — таким образом, чтобы срабатывали исключения спам-фильтра. А это деньги рекламодателей в кулхацкерский общак, формирование мнений, вбросы и прочие радости, обессмысливающие любую фильтрацию контента. В случае с интернет-магазином, Ваша учётка — это, очевидно, ещё и такая ответственность, как отзывы о товарах. Рекомендательный механизм компрометируется… Вообще, туманное стремление виртуальных жителей растворить свою уникальность ради "удобства" — занятный социопсихологический феномен...
Славно.
На большинстве ресурсов у меня разные сложные пароли. Дома они все хранятся в браузере, доступны в любой момент через 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.
И что?
Почему иногда, если пароль можно менять часто?
"Иногда" — "на некоторых сервисах". Потому что стоимость смены логина (точнее говоря, публичного идентификатора; стоимость смены частного логина как раз пренебрежимая) достаточно высока.
Всё равно, если пароль был хорошим, никто не подберёт логин — ни случайно, ни намеренно.
Почему "никто"? Есть вероятность, с увеличением числа людей в системе она увеличивается, причем нелинейно (опять возвращаемся к парадоксу дней рождений).
Но она не одинакова же, в варианте с только паролем пароль длиннее.
А откуда вы это взяли? Почему в варианте с только паролем пароль длиннее? Что мешает владельцу связки логин-пароль увеличить длину?
А если мы про брутфорс (потенциально бесконечный), то это совсем другое.
Чексумма это дополнительная сущность, разве одного хеша не должно быть достаточно?
Чтобы избежать описанной атаки, одного хеша недостаточно.
Какова вероятность для 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+ символа с равным соотношением спец. символов, цифр, букв, и уж тем более еще меньший процент готов приводить свои пароли в соотвествие с техническими рекомендациями по безопасности. Чаще запоминают мнемонические пароли, или пароли как ответы на вопросы (день рождения, имя жены, домашнего животного, и.т.д)
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)
Скорее, я надеюсь, что пользователь, ознакомившись с принципом авторизации, придумает действительно надёжный пароль.
"Действительно надежный пароль" — это случайный пароль определенной длины. Вероятность его совпадения повышается по мере увеличения числа пользователей. Дальше читаем про парадокс дней рождений и ужасаемся.
Однако является ли это проблемой?
Ну да, это неудобно пользователю.
Это неудобно. Более того, это упрощает словарные атаки.
Но и не менее неудобно. Зачем мне решение, которое не приносит пользы?
Представьте, что вы подошли к торговцу/за́мку/чему-то ещё и должны назвать секретное слово, которое сообщили только Вам и его знаете только Вы, и тогда на Вас снизойдут всякие бонусы.
Одноразовое?
Но ведь если кодовое слово длинное и угадать его затруднительно, проблемы нет, не так ли?
Проблема есть — мне надо это слово запомнить.
В текущем примере — думаю да, т.к. бонус даётся единожды
Для одноразовых бонусов разницы нет.
А вообще мог бы быть и многоразовым.
А для многоразовых начинаются проблемы безопасности.
А как же запоминание пароля?
Когда есть запоминание пароля, есть и запоминание логина, только мне еще и подсказывают, от какого логина пароль, так что в этом кейсе два разных поля выгоднее.
Теперь можно заменить слова логин и пароль на ИД и ключ и на этом успокоиться. Или нет? :)
Мы исходим из предположения, что злоумышленник может получить такую возможность)
Сознательными могут быть и злоумышленники, и обычные пользователи, также как и несознательными. Не стоит уповать на одни только успешные сценарии поведения пользователя
Первичная обработка пароля должна производиться на клиенте по сценарию, удовлетворяющему минимальным требованиям безопасности, например PBKDF2 с большим числом циклов и уникальной для сайта «солью», и отправляться на сервер только в хешированном виде.
Оу, до меня только сейчас дошло. Вот отправляется на сервер пароль в хешированном виде. А что с ним дальше происходит?
то надо по этому хешу найти пользователя
Каким образом? Вот конкретно, прямо по шагам: у нас есть сервер, ему прилетел с клиента хеш пользовательского пароля. Что сервер делает дальше?
Омг. Вы понимаете, что этот ваш "хеш" — это на самом деле простой пароль (не важно, как пользователь его получил), и ваш сервер хранит его в БД в открытом виде? А это значит, что одна утечка БД — и можно залогиниться на сайт под любым пользователем вообще.
Радужная таблица радостно возвращает нас к открытым паролям.
А зачем своя для каждого сайта? У вас тривиальное H(data), радужная таблица для H достаточна.
Это не важно. С точки зрения сервера приходит готовый ключ data. Как он сформирован — не важно, и злоумышленник может сразу передавать этот ключ, не заморачиваясь поиском пользовательского пароля. Поэтому на уровене сервера у вас обычные несоленые хэши, со всеми вытекающими.
Серверная соль уже может быть уникальной для каждого пользователя
Каким образом, если вы пользователя не знаете?
(а если она неуникальна, то возвращаемся к пониженной криптостойкости)
А разве нельзя иметь на сервере соль, одинаковую для всех пользователей, но которую знает только сервер?
Нельзя. Все, что доступно серверу, может быть украдено.
На какое время заполнения таблицы Вы рассчитываете?
Так прикол в том, что нам не надо заполнять таблицу целиком (если мы, конечно, не делаем атаку на конкретного пользователя). Мы просто начинаем генерить ее с нуля, и для каждого варианта сразу проверяем, есть ли он хотя бы у какого-нибудь пользователя. Есть — ура, у нас есть одна жертва. И так далее.
И почему бы просто не увеличить вычислительную сложность хеширования пароля (в адекватных пределах, конечно, но не обязательно, чтобы это происходило прям мгновенно)?
Потому что чем выше вычислительная стоимость логина, тем ближе вы к DoS-атаке.
Тогда почему Вы не боитесь, что у каждого пользователя будет своя соль, но взломщик просто будет брать соль каждого, генерить его хеш с нуля и проверять на наличие?
Потому что проверять на наличие бесполезно — поскольку у всех других пользователей другая соль, полученный пароль не подойдет. Проверять можно будет только на равенство хеша.
И в случае с авторизацией только по паролю пароли всё-таки должны быть уникальными, так что не получится за один раз найти пароль сразу нескольких пользователей.
Зато пароль случайного пользователя найти дешевле.
Либо Вы просто заботитесь о безопасности и неприкосновенности БД
Это бесполезно.
предварительно создав на сервере новую соль и обновив все хеши в своей БД
Это же невозможно. Чтобы обновить хеш, вам надо знать, из чего он посчитан.
Какая разница, кто под кем залогиниться, если у вас утекла БД?
Фундаментальная же. Во-первых, авторизационная БД не обязательно совпадает с бизнесовой, во-вторых, можно же делать кучу всего нового от имени пользователя.
Так что после утечки БД надо менять пароли всем пользователям
Вот только для этого надо узнать, что она утекла.
А если мы не хотим, чтобы взломщик узнал пароли пользователей и смог с их помощью зайти на другой сайт
Вот это меня как раз совершенно не волнует.
Будет ли пароль, который не составило труда добавить в радужную таблицу, настолько уникальным, чтобы не совпадать ни с чьим чужим паролем на том же сайте?
Не понимаю вопроса.
Нет, т.к. если взломали БД, это значит лишь, что о её безопасности недостаточно хорошо заботились.
Если подходить с этой точки зрения, то можно вообще ничего не хешировать и хранить в плейнтексте. Но так почему-то не делают. БД утекают регулярно, и будут утекать дальше.
Вы знаете: старый хеш был посчитан из отправленного пользователем хеша и старой серверной соли, а новый должен быть посчитан из этого старого хеша в БД и новой серверной соли.
В этот момент вы (а) полностью убили обратную совместимость с клиентами и (б) если кто-то увел предыдущую БД, у него теперь есть готовые пароли прямо для входа.
А Вы об этом не знаете и считаете, что незнание об этом OK?
Это данность. Когда считаются возможные атаки, такой кейс надо учитывать.
В нашем случае, либо пароль настолько плох, что может совпасть с чужим паролем и такие пароли архитектурно запрещены, либо он настолько сложный, что вряд ли взломщик добавит его в свою радужную таблицу.
Нам не важно, насколько сложный пароль. Нам важно, что он дает нужный хеш. Поэтому вероятность попадания пароля в радужную таблицу (ну или, в общем случае, в таблицу хешей) не зависит от его сложности.
Нет, надо сделать всё по максимуму, но не перегибая палку.
Нынешнее "по максимуму" — индивидуальная соль на каждый пароль.
… Ведь Вы считаете, что заполнить радужную таблицу на стопицотмиллиардов паролей так просто.
Я считаю, что атаковать БД, в которой соли нет (или соль одна и та же), проще, чем ту, в которой для каждой строчки уникальная соль.
Если Вы реально хорошо обезопасили свою БД
Я точно знаю, что нет никакого "реально хорошо".
Почему в этой БД должен быть логин, скорее всего, одинаковый для всех сайтов?
Потому что утечка логина не представляет опасности (логин — это публично доступная информация и так).
У клиента будет старая серверная соль в качестве 2-й соли
Так для этого надо клиент обновить.
если кто-то увёл БД, Вы должны 1) узнать об этом, 2) принять меры.
Это не всегда возможно, поэтому нельзя на это закладываться. А если вы можете на это заложиться, то можно вообще ничего на сервере не шифровать.
OK, если злоумышленник получит доступ к БД только на чтение, то Вы правы на счёт уникальной соли для каждого пользователя. А почему Вы не учитываете, что он сможет получить доступ к БД и на запись?
Потому что получить доступ на запись сложнее.
Что злоумышленник будет делать с этим хешем?
Возьмет то, из чего он (хэш) получился и пошлет в систему в качестве пароля.
Из этого следует необходимость пользователя ввести свой логин или ID, а это уже перегибание палки.
Для вас — да. Но не для остальных людей.
Точнее, перегибанием является запрет авторизации только по паролю на основании только того, что у Вас может утечь БД.
Не только этого. Есть и еще соображения.
Вот только ничто не мешает Вам вместо запрета этого варианта обезопасить свою БД.
Конечно же, мешает. Полная "безопасность БД" -это иллюзия.
Проще, но насколько? Взломщику всё равно придётся создать хеши для всех возможных паролей после того как он узнает соль на сервере. Сильно ли легче ему станет только от того, что на каждом пароле ему надо будет передать одну и ту же соль вместо разных для разных пользователей, но список которых у него всё равно есть?
В разы проще. Сравните два алгоритма:
(1) для каждой строчки в БД берем ее соль, дальше начинаем рассчитывать варианты хэшей с учетом этой соли, пока не подберем хэш, совпадающий с хэшом в строчке
(2) берем общую соль, начинаем рассчитывать варианты хэшей. Для каждого получившегося хэша проверяем, есть ли он в БД, если да — записываем в успешные, идем дальше.
Почему вообще, в этом случае, Вы не согласны с тем, что сложность надо увеличить?
Потому что увеличние сложности повышает уязвимость к DoS.
Она публично доступна только в случае, когда логин всегда равен никнейму
Это "очень часто". А когда логин равен емейлу — еще чаще. А когда целевая атака — всегда.
Ну, если Вы не хотите приложить всех требуемых усилий не только чтобы обезопасить БД от взлома, но и чтобы узнать об этом
Я не "не хочу", я "не могу".
А если Вам не подходят ни надёжные пароли, ни бо́льшая вычислительная сложность хеширования, ни защита БД от взлома, то я даже не знаю, чем могу Вам помочь(
Вы не хотите понять одного простого факта: для любого предложенного вами решения (надежные пароли, большая вычислительная сложность, защита БД), вариант с уникальной солью будет менее уязвим, чем вариант с общей солью.
Но возможно же
Все возможно. Даже одновременное падение метеоритов на все дата-центры. Вопрос вероятности.
И всё же я не понимаю, как сложный пароль попал в радужную таблицу.
Да не пароль попал, а хеш от него. А какой пароль к этому хешу привел — не важно.
Какие?
Публичный идентификатор, например. Удобство построения БД.
можно просто исключить плохие звенья и достичь максимальной безопасности
Самое плохое звено в безопасности — человек. Вы не можете исключить операторов.
Но даже с общей солью создать хешей придётся всё равно много.
В m раз меньше, где m — число пользователей, атака от лица которых нам интересна.
Тогда остаётся только увеличивать сложность на клиенте, хотя это неэтично.
Это бесполезно, потому что для сервера пароль — то, что прислал клиент, не важно, сколько раундов было на клиенте.
Очень часто ≠ так и нужно.
Это, как говорилось выше, удобно.
Я не имел ввиду случаи, когда в качестве логина используется email
… а их много.
Откуда Вы знаете, что, если Вас взломали, то взломали потому что такова жизнь и законы ИБ, а не потому что Вы защитились всё же недостаточно хорошо?
Как раз наоборот: я знаю, что меня взломали потому, что я защитился недостаточно хорошо. И это и есть жизнь и законы ИБ. Вопрос в том, были ли у меня ресурсы на "достаточно хорошо"?
А почему у Вас она именно такая, что взломщик не сделал ничего от имени пользователя, и главное не дать ему залогиниться под пользователем, не больше и не меньше?
Чтобы сделать что-то от имени пользователя, надо как раз залогиниться (ну, я сейчас не рассматриваю перехват сессии). Если не дать залогиниться — мы не дадим действовать (в рамках системы) от имени пользователя.
Я, конечно, не особо разбираюсь в радужных таблицах, но думаю, буду прав, сказав, что из воздуха такой хеш появиться не может. Только случайно, но вероятность этого очень мала.
Вероятность этого ровно такая, какая у любого другого хэша (исходя из того, что хэш криптографический, конечно). Вероятность совпадения — по парадоксу дней рождений.
Публичный идентификатор не имеет и не должен иметь отношения к делам авторизации.
Где записано, что "не должен"?
Операторов чего?
Системы, БД, бэкапов, ДЦ, далее продолжать.
Значит, чтобы усложнить работу взломщика, надо увеличить пароль на 3 байта.
С момента, как у вас пароль превысил 64 байта, любое последующее увеличение ничего не дает (я считал для 512-битового хэша). А это не так много символов.
Зато взломщику придётся проделать больше раундов, чтобы заполнить свою радужную таблицу.
Конечно, нет. Мы оперируем тем, и только тем, что получает сервер, нам все равно, что делает клиент.
А мне удобно авторизоваться на сайте с помощью картинок, одноразовых паролей и запроса на мой домашний комп как на личный сервер авторизации (в зависимости от ситуации и настроения), но почему-то нигде этого нет.
Потому что вы в меньшинстве.
А в чём проблема?
В недостатке ресурсов, очевидно.
Гугл, техническая документация, огромная общедоступная база опыта множества разработчиков…
Это все не ресурсы. Ресурсы — это, грубо говоря, деньги, время и люди. Ну еще железо (но оно вытекает из денег). Когда у вас на развертывание системы неделя, а денег на собственный ДЦ нет — возможности по обеспечению безопасности становятся резко ограниченными.
Но это только когда взломщик получил доступ к БД на чтение, а доступа на запись получить не смог.
Ну да. Это более вероятный кейс, чем получение доступа на запись.
Вы имели ввиду случайные коллизии, когда H(pass)==H(something) и злоумышленник отправляет в систему something?
Я имел в виду, что нам все равно из чего получился хэш до тех пор, пока он совпадает с хэшом в БД (если мы, конечно, охотимся на систему, а не на пароль).
Увеличить длину хеш-функции
За ресурсы вы не платите, да?
Хранить в БД ещё какой-нибудь короткий хеш/чексумму (можно взять маленький кусочек хеша нормальной хеш-функции) того, что должен передать пользователь
Двойной хэш? В два раза увеличили уязвимость к DoS.
Проверить то, что передал пользователь, на длину
А откуда вы знаете, какая она должна быть?
Кстати, я не очень понял, как злоумышленник передаст «что угодно», если сервер использует ещё, как минимум, соль.
Мы же с этой солью и считали.
Где записано, что «не должен»? — В Вашем комментарии, слове «Публичный».
Нет, из него это никак не вытекает.
Вас же не принуждают хранить в БД хеши современных популярных алгоритмов? Вы можете разработать свой.
Плохая идея. Если вы не специалист в криптографии, вы сделаете только хуже.
Это не обоснование.
Это как раз разумное обоснование, почему для вас никто не пишет систему входа — это невыгодно.
Ясно. Тогда остаётся лишь [....] надо просто с душой подходить к процессу и стараться не делать ошибок)
Этого недостаточно.
Вот только из этого следует, что БД может утечь.
Да, именно так.
И то, что под юзером кто-то залогинится, намного менее серьёзно, чем украдут приватные данные множества пользователей.
Нет. Потому что (а) приватные данные могут быть в другой системе и (б) имперсонация вообще может натворить ужасных дел.
Кто виноват?
Вы правильно ответили, все виноваты. Использование на каждом этапе продуманного и уже оцененного специалистами решения выгоднее, чем изобретение велосипедов (до тех пор, пока вы сам не специалист, конечно).
Почему Вы не используете его, а используете именно тот, в котором сайт взломали?
Потому что если сайт не взломали, у нас нет атаки, и обсуждать нечего.
Эта плата несравнима с той, которую придётся заплатить взломщику, чтобы заиметь рабочую радужную таблицу больше.
Расчеты двух разных "плат" в студию.
А как иначе Вы справитесь с атакой по радужной таблице?
Добавление индивидуальной соли к каждому паролю делает бесполезным расчет радужных таблиц.
Ведь даже если пароль пользователя захеширован с его собственной солью, взломщик просто найдёт набор байт, который, после хеширования с той же солью, даст нужный хеш
Брутфорсом, ага. Дорого.
Обычно хеш-функции дают результат фиксированной длины
То есть вы предлагаете строго зафиксировать длину пароля? В этот момент вы радостно упростили работу взломщику, спасибо вам.
Не очень понятно, кто «мы». Если имеется ввиду взломщик, то для начала ему надо будет найти радужную таблицу.
Взломщик, взломщик. Возьмет и построит.
Серьёзно? Пароль является средством аутентификации, а логин не является? Почему же?
Во-первых, насколько я помню, логин является средством идентификации, а не аутентификации. Но не важно, потому что, во-вторых, не всякое средство аутентификации должно быть сокрытым.
Отличная идея, если Вы хотите на 100% обезопаситься от атаки радужными таблицами
Нет, самописная хэш-функция не дает стопроцентной защиты от атаки через радужные таблицы.
Наверное, надо им стать… только не говорите, что на это недостаточно ресурсов
Именно так. Это отдельное специальное образование — и оно мне, будем честными, неинтересно.
Либо Вы делаете это, либо имеете риск попасть под атаку с использованием радужной таблицы
Я всегда имею риск попасть под атаку с использованием радужной таблицы. Просто некоторые решения этот риск уменьшают — например, использование соли, лучше всего — индивидуальной.
Значит соответствие ника и пароля используется часто потому что это выгодно (в том же смысле, в как в цитате выше). Это и есть Ваше «обоснование»?
Ну да. Использование логина и пароля выгодно, потому что это устоявшаяся практика, решающая сразу много вопросов в архитектуре системы.
Вы это проверяли?
Да, я проверял. Благих намерений недостаточно для построения защищенной системы. Еще нужны знания, опыт и ресурсы.
Вы уже попробовали если не удалить все ненадёжные звенья на раз,
Нет, не пробовал, потому что для удаления всех ненадежных звеньев нужно слишком много денег. Кстати, хочу заметить, что вся самописная криптография как раз попадает под определение "ненадежное звено" и выпиливается первой.
Ну, это не есть нормально.
Это расчет модели угроз.
A. Вас не должно касаться, есть они в другой системе или нет, Ваше дело — обеспечение безопасности своей системы, потому что пользователь доверил Вам свои данные.
Вы не поняли, о чем я говорю. Если у меня в системе есть данные разной степени конфиденциальности/бизнес-импакта, я могу разнести их по разным подсистемам, таким образом, чтобы утечка одних (например, аутентификации) не приводила к утечке других (например, бизнес-данных). А еще, кстати, бизнес-данные можно просто насмерть зашифровать. Очень дорого, но можно.
Да, имперсонация + кража данных хуже одной только кражи данных. Но одна только кража данных хуже отсутствия кражи данных.
Спасибо, кэп.
Из этого следует, что, что бы ты не придумал, надо молчать и не показывать этого. Никому. И никуда этого не кидать. Что бы это ни было.
Нет, не следует.
Так почему Вы предполагаете, что сайт взломали и у нас есть атака?
Потому что это возможный случай, который надо рассматривать. Если его не рассматривать, то на очень много методов защиты (включая серверное хэширование паролей вообще) можно забить.
А если рассматривать, какие могут быть атаки, то надо рассматривать и атаку на запись.
А атака на запись нам просто не интересна, потому что от атаки на запись в хранилище аутентификационных данных защиты с помощью аутентификационных данных не существует (ну или я ее не знаю).
Каждый инструмент применяется на своем уровне.
Только после того как Вы объясните, откуда у взломщика пригодная для взлома радужная таблица
Самый простой ответ — посчитал.
Потому что пары pass+salt всегда разные?
Потому что соль всегда разная. Сейчас объясню.
Почему здесь брутфорс, а в случае с одной солью на сайт нет?
Так вот, объясняю. Представьте себе таблицу с аутентификационными данными, хешом Hx и солью Sx ((H1, S1), (H2, S2), (H3, S3), ..., (Hn, Sn)).
Если ни одна соль не повторяется (S1 != S2 != S3… != Sn), то чтобы подобрать Px, такой, чтобы Hx=H(Px, Sx), необходимо взять соответствующую Sx, и осуществить подбор; т.е., для каждого возможного Pi выполнить H(Pi, Sx) и сравнить с Hx. Для этого, несомненно, можно использовать радужную таблицу, посчитанную для H и Sx — если она у вас есть. Если у вас ее нет, вам придется ее построить, и — если я не ошибаюсь — время этого построения сопоставимо с простым перебором, описанным выше. Что важно, так это то, что для другого x (другого Sx) всю эту процедуру придется повторять заново.
Теперь возьмем случай, когда S фиксирована (S1=S2=S3...=Sn=S). В этом случае процесс идет с другой стороны: для каждого возможного Pi мы считаем Hi=H(Pi, S), и сравниваем этот Hi с каждым известным нам Hx. Если совпадение найдено, значит, Px=Pi, фиксируем и переходим к следующему Pi. Если у нас есть таблица, расчитанная для S — мы можем ее использовать. Или мы можем ее рассчитать, это, как уже говорилось, сопоставимо по времени с перебором Pi. Важно то, что перебор Pi (построение таблицы) нам надо сделать один раз, а в результате мы получим все пароли из хранилища — в противовес первому сценарию, где для получения всех паролей перебор надо делать столько раз, сколько паролей (с небольшой оптимизацией, конечно).
У вас взломщик шлёт какую-то фигню вместо пароля, которую сервер хеширует с солью
Взломщик шлет набор байтов, который неотличим от потенциального пароля (потому что в вашей схеме "пароль" — это произвольный набор байтов, не так ли?).
Так вот, у Вас взломщик настолько крут, что находит коллизию не для какого-то алгоритма хеширования, а PBKDF2 со множеством итераций.)
Не находит коллизию, а находит такое P, которое после наложения H(P, S) дает хэш, совпадающий с хранящимся в БД (упрощенный вариант preimage attack).
Оказывается, ему стало проще найти такую фигню с фиксированной длиной, к тому же неизвестной вплоть до взлома сайта, чем если бы он мог найти такую фигню с любой длиной?
Конечно, проще. Множество P с длиной n меньше, чем множество P с длиной 1..m, где m >= n, значит, и перебор короче.
А длина, конечно же, известна до взлома сайта, потому что реверсинжиниринг вашего фронта прекрасно показывает, какую длину вы шлете на сервер.
Тогда см. часть про периодическое нарастание соли
Это та часть, где мы выяснили, что утекшая предыдущая версия БД автоматически дает доступ на сайт?
Давайте по существу, а не по формальностям.
Тогда не вижу смысла обсуждать это разделение, перейдем сразу к пункту 2.
"во-вторых, не всякое средство аутентификации должно быть сокрытым."
Обоснуйте. Вы же доказывали мне, что логин+пароль лучше только пароля, потому что, чтобы войти в аккаунт, мало угадать только пароль, надо угадать ещё и логин, и таким образом он является дополнительной мерой защиты.
Надо угадать не логин, а сочетание логина с паролем. Вот смотрите, вы знаете все логины от сайта, и один пароль от этого же сайта, причем пароль гарантированно рабочий. С какой вероятностью вы войдете на сайт с первой попытки? Правильно, 1/n (где n — число логинов). Поменяем местами, один логин и все пароли? То же самое. А ведь вам известны и логин, и пароль.
(и, что характерно, от обеих этих атак есть некоторые способы защиты)
Поэтому даже если логин открытый, вероятность подбора все равно не выше, чем при полном отсутствии логина (аутентификация только по паролю), но при этом сразу появляются дополнительные способы защиты.
Суть в том, что для самописной хеш-функции взломщику придётся создавать с нуля радужную таблицу и он не сможет использовать уже готовую.
Это не защита от атаки, это всего лишь понижение выгоды этой конкретной атаки.
А каким образом индивидуальная соль уменьшает этот риск в данном случае?
См. выше: при индивидуальной соли таблицу можно будет применить только к тому единственному хэшу, для соли которого эта таблица посчитана.
Но устоявшаяся практика тоже не синоним правильности.
Устоявшаяся практика — это (в данном случае) набор решений, для которых был проведен анализ безопасности, на который можно опираться при разработке своих решений.
Судя по части далее, не проверяли.
Вы сказали, "надо просто с душой подходить к процессу и стараться не делать ошибок". Я сказал, что этого недостаточно. Вы спросили "Вы это проверяли?". Я понял этот вопрос как "проверял ли я, достаточно ли просто подходить с душой к процессу и стараться не делать ошибок". Это я проверял.
А может, слишком много денег нужно для решения Вашей конкретной задачи, вместо которой можно взять какую-нибудь другую, попроще?
Но предыдущая-то задача останется нерешенной — что и будет примером того, что для решения определенных задач нужны ресурсы.
По такой логике никто никогда в принципе не должен самостоятельно создавать ничего криптографического.
Тоже нет (все это рассказывают на первом занятии курса по криптографии, кстати). Создавать-то можно, просто прежде чем использовать, надо пройти определенный процесс доказательства.
Но тогда пользуйтесь не самописной криптографией — наймите кого-нибудь, пусть он вам сделает алгоритм, или проверит Ваш и проч.
А зачем, если можно просто взять готовое коробочное решение?
я и предложил вариант, не требующий денег, людей и проч.
И не выдерживающий определенную категорию атак, да. Кстати, утверждение, что этот вариант не требует ни денег, ни людей, неверно.
Позволить создать угрозу (или повысить её вероятность), а потом рассчитывать её модель
А где я повысил вероятность какой-то угрозы?
А почему Вы опираетесь на то, что взломщик украдёт БД с какими-то данными входа [...], чтобы лишь написать что-то от лица пользователя, вместо того чтобы украсть бизнес-данные?
Я опираюсь на то, что кража первого не должна означать автоматической кражи второго и наоборот. Возможны оба сценария, оба надо рассматривать и оценивать — но от второго (кражи хранилища бизнес-данных) механизм аутентификации защитить не может.
Ключ расшифровки будет храниться у пользователя или у Вас в БД?
У пользователя, конечно — это его пароль (в паранояльном варианте — отдельный пароль).
Но мне, если честно, не очень верится, что Вы будете на это готовы
Зависит от требований. Я такого не делал, потому что таких требований по защите никто не выдвигал.
А следует «из этого» во всех случаях…
Снова нет.
Сначала делаем такую же атаку на I, как раньше (т.е., перебираем все S, пока не найдем I в БД). Дальше, если client_salt известна, мы получили K. А как вы сделаете, чтобы она была неизвестна, если она должна быть повторяема при каждом входе этого пользователя с любого устройства?
А в случае, когда вместо K используется пароль, ситуация лучше?
Нет.
Вообще, какой алгоритм авторизации по паролю Вы считаете безопасным?
Алгоритм аутентификации по паролю я знаю ровно один: сравните пароль с хранящейся информацией о нем, если совпали — пароль верный.
А этот вариант решает не проблему брутфорса или использования радужной таблицы, он решает проблему поиска пользователя только по хешу пароля без возможности раскрытия самого пароля
Вы не можете искать пользователя только по хешу пароля без снижения уровня защищенности. Если вам хочется не раскрывать пароль — то не раскрывайте его, используйте производную генерацию на клиенте. Только это к серверу отношения не имеет, для сервера паролем будет ваша производная.
А еще есть сертификаты...
А что это за информация о нём и как сравнивается?
Сейчас принято хранить соленый хэш, сравнение должно быть неуязвимо к time-based attacks.
Если Вы про то, что в логине+пароле больше информации, чем в только пароле
Нет, я про соленые хэши.
Но мы тут обсуждаем пароли же…
Ну так вам же хочется пароли не раскрывать. Сертификаты для этого прекрасно подходят.
Ну, в этом варианте хеш тоже получается из того, что передал пользователь, с использованием уникальной соли. А I — аналог логина, просто помогает найти пользователя в БД.
Вот только этот "аналог логина" позволяет вычислить исходный ключ, полностью нивелируя вашу индивидуальную соль.
Что не так с солёными хешами?
С ними все так. Если их правильно готовить.
Сертификат [...] не так просто сменить, как пароль
Да точно так же.
Если мне хочется не раскрывать пароли, это не значит, что какому-то другому пользователю будет удобно использовать не пароль.
Я и не предлагаю всем сертификаты использовать.
Я не против использования сайтами паролей, т.к. это их право. Просто в таком случае сайт не должен иметь доступа к паролю
Одно противоречит другому. Если сайт использует пароль, то он имеет к нему доступ.
однако нет гарантии, что сайт не будет использовать его никак иначе (и уж если мы подходим к безопасности серьёзно, то не надо давать сайту таких возможностей).
… что решается созданием для сайта уникального пароля. Обиспользуйся. И да, ваше решение — это тоже создание для сайта уникального пароля, ничем не отличается.
И всё же: откуда у взломщика радужная таблица с паролями, пригодными для использования в такой авторизации?
Посчитал.
Что не так в моём процессе их приготовления?
Вы не используете уникальную соль для каждого пользователя.
Если сертификат подписывается сайтом, то мб, почти так же. Но всё равно не совсем. Вам привычно наличие логина, а мне привычно отсутствие требования сохранять какой-то файл, а потом устанавливать его в браузер
А не надо сохранять никакой файл, относитесь к сертификату, как к длинному паролю.
(на самом деле, правильнее было бы сказать не "сертификат", а "ключевая пара", а в качестве клиентского подтверждения использовать закрытый ключ)
Вот поэтому сервер сайта должен использовать не пароль. Правда, фронтенд сайта всё равно будет использовать пароль, но код фронтенда можно проверить.
В общем случае — нельзя, потому что современный фронтенд сайта с завидной регулярностью является API или мобильным клиентом.
И как их все помнить?
Специальные приложения.
Это создание уникального пароля для пользователя, а не для сайта.
Если у вас пароль уникален для пользователя, но не уникален между сайтами, то один сайт может использовать его на другом, тем самым нарушая вашу же задачу. Так что нет.
Сколько времени это займёт и где он будет её хранить?
В абсолютных величинах — без понятия.
Если я буду использовать уникальную соль для каждого пользователя, то как его найду по одному только паролю?
Никак. Я вам сразу сказал, что ваш вариант не позволяет так сделать, и это ведет к уязвимости.
И помнить всё его содержмое?
Это ничем не отличается от "помнить достаточно сильный пароль".
Лично я тоже считаю, что закрытый ключ у клиента лучше чем сертификат у клиента.
Фундаментальной разницы нет.
Однако как Вы будете искать пользователя в БД по одному только ключу?
Никак.
Или он всё же должен вводить логин?
Да, должен.
Если так, то зачем Вы предложили мне это вместо только паролей
Я вам это предложил не вместо "только паролей", а как решение задачи "не давать сайту доступа к паролю".
В тех случаях, где нельзя, конечно, пользователь не сможет безопасно использовать один и тот же пароль.
В нынешних реалиях это означает "всегда", потому что сайты без API чем дальше, тем менее конкурентноспособны. Но это, конечно, мое личное мнение. Но я систем без API не разрабатывал очень давно.
Тогда будет помнить компьютер, а не пользователь.
А я и не считаю, что пользователь может запомнить сильный пароль. Это ваше предположение было.
Но сайт не сможет использовать пароль, если будет знать только его хеш, но не сам пароль.
Я уже говорил: с точки зрения сайта, паролем является то, что ему отдали. Если хэш генерится для всех сайтов одинаково, значит, вы опять получили один пароль на все сайты. Если хэш генерится по-разному — вы как раз и сделали способ получения множества паролей из одного мастера.
А Вы, тем временем, не ответили на вопрос:
Я не вижу смысла на него отвечать, потому что я не утверждал, что вы такое предлагаете.
Достаточно, использовать что-то вроде jwt-токена
… и куда вы его денете?
Вместо ссылки https://example.com/signin/callback/email/{{token}} делать ссылку вида https://example.com/signin/callback/email/{{jwt_token({expired_at:1213141,email:xxx@xxx.xxx})}}
(типа так https://example.com/signin/callback/email/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzaWduaW4iLCJlbWFpbCI6ImFsZXhAbWFpbC5jb20iLCJleHAiOjEyNTIzMjU1Nn0.cy7DZ3gQHPINbeKbjvZTl8FmdzRyCWd8InG097ICQ7k)
На сервере просто проверяется цифровая подпись и авторизуется по указанному в емейлу.
… а как вы будете обеспечивать однократное применение?
Если меня сайт на попытку входа будет отправлять в почту, в которую вообще не факт что быстро придёт письмо (или вообще придёт), и ненулевая вероятность что его придётся искать в спаме или в проводах, в которых оно застряло, я наверняка в какой-то момент захочу испить крови гения, который этот бред придумал. Пароли может и не самое удачное решение проблемы, и менеджеры может и костыли, но предложенное решение ещё хуже. Я уж молчу про безопасность, учитывая, что smtp у нас не самый защищённый протокол — более, чем в одном смысле.
Сервис мне выдает какой-то email, и закрепляет его за мной. Подчеркиваю — не временный, пока я сам его не захочу сменить/вернуть.
Когда письмо приходит на этот алиас, оно перенаправляется мне в мой ящик через обычную отправку почты, в поле reply-to стоит специальный сгенерированный адрес.
Я отвечаю на письмо на адрес из reply-to. Письмо уходит на сервис на сгенерированный адрес, и сервис понимает, что это ответ на конкретное письмо, присланное на алиас, и от себя отправляет ответ, не засвечивая мой основной адрес.
Для адресата, который пишет мне на алиас, все выглядит так, будто алиас и есть мой почтовый ящик, и я с него отвечаю. Если я освобождаю алиас, перенаправление отключается, понятное дело. Тут еще есть момент, что новый пользователь может получить письмо, предназначавшееся мне, но сервис не предназначен для серьезной переписки, так что я не считаю это серьезной проблемой.
У меня была идея такого сервиса, и я не нашел похожих. Может кто сталкивался?
К тому же такая штука вроде только для корпоративной почты там, для личной не нашел. Для личной по сути придется зарегистрировать отдельный адрес и потом его привязывать.
Сам по себе феномен менеджеров паролей, это уже костыль, который должен нам был показать всю не востребованность и неэффективность повсеместного использования паролей.
Категорически не согласен. Есть множество ресурсов, для которых я храню пароли в медеджере паролей, при этом светить в них свой основной email я не хочу, а зарегистрированы такие аккаунты зачастую на одноразовую почту.
Ведь чтобы авторизовать пользователя, вам достаточно выслать ему на почту письмо со сгенерированной ссылкой, как при подтверждении аккаунта.
Лишние телодвижения с открытием почты, ожидания доставки сообщения. Зависимость от работоспособности почтовых серверов.
В качестве защиты от спама письмами, можно сделать рейт лимит, или не высылать письмо чаще чем раз в 10 минут.
И получить невозможность авторизации в течение 10 минут на другом устройстве или после закрытия браузера/выхода из аккаунта.
Как альтернативный способ авторизации, этот способ имеет место быть, на равне с OAuth, но ни в коем случае не как замена логину/паролю.
Не безопасно, собственно
Навскидку видится больше минусов, чем плюсов. Т.е настолько нестандартно, что использовать можно (на свой страх и риск) на ресурсах агрегаторах новостей например,
где важна возможность полистать ленту, посрать в комментариях, т.е нет данных кредиток и прочей компрометирующей информации.
Плюсы:
- "Удобство" аутентификации. Нет пароля, пожалуй единственная фишка подхода. Жизнеспособно для ресурсов, не компрометирующих данные пользователя
Минусы:
- Неудобно эргономически, слишком много действий на вход
- Неудобно для клиента почтового сервиса, да и для самого сервиса в частности. Замусоривается пространство почтового ящика, при этом для почтового сервиса такие аутентификационнные письма создадут дополнительную нагрузку по траффику
- Уязвимость к атакам session fixation. Здесь стоит вопрос доверия к самой ссылке. Можно банально попастся на письмо аналогичного содержания от хакеров, только с немного другим токеном. Вариантов — масса.
Можно просто подарить ID сессии злоумышенникам, либо зайти 'нетуда' и слить еще и данные других доменов через клиентский XSS. - Учитывая то, что пользователь будет уходить по такой ссылке, например, с gmail.com, это наверняка будет отслежено гуглом — банальный запрос на тот же домен почтового сервиса с последующей отдачей ответа 301. Здесь всплывает опасность MiTM.
Нельзя просто так влезать со своими интересными предложениями в область информационной безопасности. Правила безопасности вообще и информационной в том числе — написаны кровью. Почему нельзя передавать авторизационную информацию в GET запросе — не затруднит найти в интернете (причин очень много, в камент все не влезут).
В крайнем случае — присылать одноразовый код из 4-8 символов с требованием ввести его руками в форму авторизации.
Это правило АНБ и ФСБ довольно успешно навязывают дилетантам.
Уж сколько раз твердили миру, что Optimism Bias опасен и для индивида с расстройством и для окружающих его и для всего общества в целом, но только все не впрок.
И в сердце АНБ/ФСБ/КГБ/ЛГБТ (подчеркнуть нужное) всегда отыщет уголок.
Диленанту где-то бог послал кусочек безопасности;
На хостинг дилетант взгромоздился.
Обезопасить себя было совсем уж собрался.
Да подзадумался, а безопасность на *** вертел.
На ту беду, АНБ/ФСБ/КГБ/ЛГБТ (подчеркнуть нужное) близёхонько бежало.
Ну я думаю Крылова тут все читали, дальше лень перефразировать.
Мораль: важность информационной безопасности не зависит от масштаба ситуации.
Мораль: важность информационной безопасности не зависит от масштаба ситуации.Очень даже зависит. Я не буду рекоммендовать ставить промышленные решения по ИБ-защите маленьким компаниям, в которой кроме 1с и почты ничего не используется. Также, как и стандарт безопасности PCI DSS нужен редким компаниям, а не всем подряд.
На сайтах, где есть возможность получать одноразовые пароли либо логиниться в том числе через получаемые эмейлы — только так и захожу.
На смартфоне пользуюсь хромом. Пытаюсь войти на сайт, где используется эта технология. Он высылает письмо с ссылкой для входа на почту. Открываю почтовик, тыкаю на ссылку, открывается штатный сафари, где происходит авторизация. Но мне нужно в сафари, мне нужно в хроме. Иду снова в почтовик, копирую ссылку, иду в хром, вставляю, перехожу, а мне сообщается, что эта ссылка уже не работает. Иду снова на сайт, пытаюсь войти, он мне пишет, что задержка 10 минут между отправкой ссылки на вход и мне нужно подождать ещё 8 минут. Я шлю автора этой йебатении куда подальше и навсегда забываю про этот глючный сайт, куда без геморроя невозможно даже войти
> мне нужно в хроме
Нет, не нужно. :3
Кстати, совершенно реальный кейс (как раз Слак одно время так себя вел, чтоб ему пусто было).
Некоторое время назад я подумывал сделать себе подобную систему для админки сайта.
Только в варианте присылания ссылок в жаббер.
А потом гугл стал мутить с жаберо-гтолко-хэнгаутом и я забил на это дело.
При всех плюсах обсуждаемого подхода, у него есть огромный минус — если он станет популярным, то его начнут пихать везде.
А при всех недостатках парольной системы, при повсеместном использовании она лучше чем присылка временной ссылки для логина.
Это и наработками то назвать нельзя. Там была какая-то xmpp библиотечка с помощью которой я поигрался.
Это оказалось очень простым и выглядело перспективным в качестве универсального решения.
А потом ВК от него отказался, гугл стал мутить и я это дело бросил.
Хотя, из phpbb-шного форума уведомления мне в гугл-чат приходят.
Но есть проблема с доходимостью в оффлайн на клиента-бастардах и приоритетом между клиентами.
это стандартная опция phpbb по уведомлению.
дублирует e-mail уведомления.
полагаю, выковырять её оттуда не составит труда.
ну, мне этот форум был интересен, его владелец тогда купил смебе смартфон с андроидом и я предложил сделать.
завёл гуглопользователя, вручную подтвердил что хочу переписываться и вписал настройки в форум.
Но это интересный вопрос.
Возможно я что нибудь скачивал и ставил дополнительно.
Вот тут обсуждение чего-то подобного — https://www.phpbb.com/community/viewtopic.php?f=46&t=488306 .
РЕГИСТРАЦИЯ
1) Почта:
2) Вам на почту отправлен одноразовый пароль.
Пароль:
3) Ура! Вы зарегистрированы!
Вы можете задать постоянный пароль: (опционально)
АВТОРИЗАЦИЯ
Почта:
Пароль: (постоянный/одноразовый)
[выслать одноразовый пароль на почту]
ПИСЬМО НА ПОЧТЕ
бла бла бла
Ваш одноразовый пароль: F7ae2G8su
Вы можете задать постоянный пароль по [ссылке].
1. Ввести свой емэйл на сайте
2. Зайти на почту
3. Перейти по ссылке из письма на сайт.
4. Зайти обратно на почту
5. Скопировать пароль
6. Перейти обратно, авторизоваться
7. Найти в многообразии сайта настройки и смену пароля
8. Зайти в почту
9. Скопировать пароль
10. Вставить пароль и ввести новый
11. Зайти в почту
12. Подтвердить смену пароля
Обычно я просто ухожу с сайта и больше им не пользуюсь когда вижу такой способ регистрации.
- Указать почту
- Зайти на почту и скопировать пароль
- Вставить пароль на сайте
Всё. Зарегистрирован и авторизован.
На этой же странице пользователю предоставляется возможность указать постоянный пароль. Появляется соответствующее поле, которое не обязательно заполнять. Не хочешь придумывать пароль и помнить его — пароль одноразовый на почту. Не хочешь светить свою настоящую почту или каждый раз на неё заходить — указываешь постоянный. Повторюсь там же с формой регистрации! Какие ссылки, какой поиск настроек, какая смена паролей, какое подтверждения? Эээ! Вы о чём? Фантазия такое дело...
Без паролей же база становится в разы менее лакомой добычей.
1. Поясните, пожалуйста, почему Вы так считаете?
На мой взгляд это справедливо лишь для случая, когда пароли от почты совпадают с паролями от сайта. И злоумышленник сможет получить доступ к какому-то количеству почтовых ящиков.
В таком случае надо просто предупреждать пользователей при регистрации чтобы они не вводили тот же самый пароль, что и от своей почты.
token не обязан быть uuid'ом, вы можете сделать и более короткие токены, которые можно даже ввести вручную. Но в этом случае вероятность коллизии и его надежность могут значительно ухудшиться.
2. Правильно я понимаю, что token Вы храните в открытом виде?
Если так, то получив базу можно сразу (!), не тратя время на брутфорс солёного хеша, представляться любым пользователем данного сайта. Например, с целью методами соц.инженерии что-то выведать (все связи пользователей и активности между ними доступны из той же в базы).
3. Почему авторизация делается по e-mail, а не по нику?
Если предположить что Ваш метод станет массовым (и при этом подбор токена за обозримое время будет невозможен), то основным ветктором атаки будет атака на e-mail (пиьсма с вирусами, фишинг и т.п.). В этом случае e-mail лучше лишний раз нигде не афишировать.
4. Чем Ваш подход принципиально отличается от обычного с использованием пароля?
Под обычным я понимаю подход когда:
1) пользователь вводит ник и пароль на сайте
2) также указывает почту, на которую приходит ссылка с подтверждением, но не сам пароль
3) теоретически можно добавить флаг прислать пароль в открытом виде на почту
Преимущества:
- Про использование ника описано выше.
- Отсутствие пароля на почте поможет, на случай, если почта будет скомпрометирована: когда пароль будет сброшен — пользователь зайти на сайт не сможет и поймёт что почта скомпрометирована.
- Если нужно зайти на сайт на чужой машине — вводится ник и пароль. Затем в ближайшее время с надёжного компа сбрасывается пароль (не афишируя на чужой машине ни почты, ни пароля от неё).
Ваш подход:
1) ник недоступен
2) ссылка подтверждения выполняет и функцию пароля (переданного в открытом виде), фактически совмещая 2) и 3)
А продвинутые пользователи будут вынуждены придумывать специальный пароль для вашего сайта или пользоваться менеджером паролей.
Кстати, при использовании Вашего подхода никто не мешает пользователю сохранить ссылку с токеном в менеджер паролей.
На мой взгляд это справедливо лишь для случая, когда пароли от почты совпадают с паролями от сайта.
Гарантии нет, но какая-то часть пользователей будет использовать один и тот же пароль в нескольких местах.
PROFIT!!!!!11
На мой взгляд это справедливо лишь для случая, когда пароли от почты совпадают с паролями от сайта.
Есть ещё один момент.
Если у Вас уводят базу с паролями, то у Вас увели всю базу с паролями и скомпрометированы сразу ВСЕ эккаунты.
Надо суетиться, менять пароли, блочить эккаунты и т.п.
Если у Вас увели базу с емейлами — скомпрометировано НОЛЬ эккаунтов.
Поэтому пароли везде хранят в хешированном виде
"везде" — unacceptable generalization
1% убогих сайтов не в счёт.
Никогда не знаешь какой сайт окажется в списке "убогих" — https://www.kommersant.ru/doc/3082294 .
Вы просто заменяете пароль от вашего сервиса на пароль от электронной почты облегчая задачу аутентификации и сопутствующих механизмов обеспечения безопасности при усложнении для пользователей доступа. Сомнительное приобретение для них.
А вся ответственность и так на их плеча. Triple kill.
Дружище, я с тобой ) Инвайт-ссылки на вход и никакого восстановления пароля ) Делаю, работает, нравится клиентам.
2) естественно для банкинга это ни в коем случае нельзя делать
P.S. классно сделано на digitalocean, вход с помощью authenticator
Всегда нужно давать выбор. Хочешь использовать пароль? Пожалуйста. Хочешь соц, сети? Используй. И так далее.
Лично я вижу будущее в связке компьютер + телефон. Для входа нужно будет ввести email и нажать кнопку входа. После этого приходит подтверждение на айфоне в котором после снятия отпечатка или уже (face I’d) нужно только дать согласие на вход путём нажатия на кнопку, без всяких вводов чего-либо.
Пример есть: приложение battle net auth.
Но решение, предложенное в статье — бредовое. Автор просто предлагает переложить заботу о хранении пароля на чужие плечи. Частный случай OAuth. И опять же, у нас получается один мастер-пароль от всего.
Я думал будет показано какое-нибудь решение, вроде авторизации через специальную прогу-агент, храняющуюся на компе пользователя. Хотя как по мне — так всё это слишком кардинально. И от чего действительно надо избавить человека — так это от запоминания пароля. Хорошие варианты — это жесты на фотках. Составление из некоторых объектов пространственной фигуры и так далее.
Автор просто предлагает переложить заботу о хранении пароля на чужие плечи.
Так она и не слезала с их плеч. Т.е. если у вас есть сброс пароля — у вас и не было никогда пароля. Multi kill
Хорошие варианты — это жесты на фотках. Составление из некоторых объектов пространственной фигуры и так далее.
Так и вижу, как я бегаю по комнате ищя кубики, чтобы авторизоваться на хабре :).
смс стоит несколько копеек, но если для ресурса важно предотвратить доступ к аккаунту третьим лицам — могут себе позволить.
процесс авторизации одноразовым паролем выглядит так:
вводишь моб.номер на сайте, рядом телефон, тебе приходит смс и скорее всего сразу увидишь необходимый код и введешь в поле под номером телефона, даже смартфон в руки брать не придется… вполне удобно…
… почта избавит пароля, но добавит для конечного пользователя возню с почтой, кликами… а если письмо попадет в спам и т.п. и т.д… бывает письма не доходят… не пришло письмо — не зашел в личный кабинет… с смс тоже проблемы бывают, но всеже ради удобства конечного пользователя, разве не так?
Использовать телефон (СМС) гораздо доже и менее безопасно, чем почту.
А если предположить, что номер телефона может утечь, то начнется спам. А вот спам на телефон в разы более мерзкий, чем на email. Если у email сервисов уже отлажены методы борьбы со спамом, то вот у телефонов все плачевно, будете получать звонки от "пирамид" с разных номеров.
Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/… Добавьте еще риски того что:
Как можно ответственность за это переложить на почтовый сервис?
SMTP — открытый протокол. Как только почта поступила на сервера сервиса, только после этого можно говорить об ответственности.
Почта должна еще дойти до них через свободную, открытую связь.
В способе из поста мне в любом случае придётся заходить в почту, искать письмо, и переходить по ссылке, испытывая кучу сложностей по пути (Открытие 3 вкладок, потеря контекста сайта перед решением авторизоваться, возможный ввод пароля на почте, да ещё и с получением смс при двухфакторной авторизации, например).
Какой в этом смысл? Сэкономить 5 секунд при регистрации? У опытных пользователей стандартная регистрация не составляет сложностей, скорее что-то нестандартное замедлит время на регистрацию, а у новичков даже вход в почту может вызвать сложности, что уж тут про новый для них способ регистрации.
Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/… Добавьте еще риски того что:
— сервис закроется
— сервис закроют для страны (привет роскомнадзор)
— сервис закроют для пользователя (причин может быть масса)
— сервис изменится так, что его нельзя будет использовать для ваших целей
— итд
в совокупности вы получаете весьма нехилый риск с которым всеже вполне можно смириться в некритичных частях системы, однако авторизацию к таковым отнести не получится. И тут уж надо сделать так чтобы работало железобетонно, а если сломалось — то можно было починить, а не зависеть от того, что кто-то когда-то возможно исправит.
Практически все, если не все, проекты использующие oauth крупных сервисов для авторизации дублируют его возможностью классической авторизации, и это не просто от того, что могут — поверьте.
Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/
А что вам в предложенной схеме мешает использовать свой почтовый сервер, если вы не доверяете гуглу?
в совокупности вы получаете весьма нехилый риск с которым всеже вполне можно смириться в некритичных частях системы, однако авторизацию к таковым отнести не получится. И тут уж надо сделать так чтобы работало железобетонно, а если сломалось — то можно было починить, а не зависеть от того, что кто-то когда-то возможно исправит.
К сожалению, я склонен больше верить в то, что у сайта с "котиками" будет все плохо, нежели у Yandex / Google / Mail.
Практически все, если не все, проекты использующие oauth крупных сервисов для авторизации дублируют его возможностью классической авторизации, и это не просто от того, что могут — поверьте.
А почему в предложено выше варианте они не могут сосуществовать? Вы можете позволить пользователю самостоятельно сделать выбор чем он хочет пользоваться: Oauth / Email + Pass / Email.
Если же вы боитесь, что почту могут своровать, и тогда пользователь потеряет доступ и к вашему сервису, так и с паролем (на вашей стороне) не многое поменяется (как минимум — ресет пароля на почту).
В этом случае "паролем" просто является картинка. Такое уже есть, даже в банальном Windows Hello.
Остальные картинки — это не картинки других пользователей, а предустановленные в системе.
Тогда для атаки достаточно просто исключить все предустановленные картинки, и оставшиеся и будут искомым паролем.
Это не "предустановленные". И тогда вы влетаете в то, что можете получить offensive-картинку. Не говоря уже о том, что можно же, зная сервис, проверять, есть ли там такая картинка.
тогда надо просто смотреть какие картинки повторяюся — они и будут "паролем"
Но у этого метода есть одно слабое место.
Вы полагаете, что пользователь во-первых сможет запомнить что он там загружал пару лет назад, а во вторых — будет грузить на разные сайты разные картинки.
А так ещё есть один вариант — это авторизация через веб-камеру. Подобный функционал уже реализован у Битрикс24. Но тут получается необходимо, чтобы у всех пользователей была веб-камера…
а «знакомые» фото, которые он узнает и спустя десятилетия
В случае с текстовыми паролями эта гипотеза не подтвердилась.
Экспериментально было установлено, что либо паролей много и хрен их запомнишь, либо это то что не только сам человек помнит десятилетиями, но и весь остальной мир прекрасно знает — день рождения, кличка собаки и т.п.
Пытался найти похожее решение в интернете, где оно подробно описано и уже решены всякие нюансы, но не нашёл…
И ещё один большой(и самый главный) минус:
Сервисы, описанные в статье, пытаются всеми силами удержать пользователя у себя на сайте:
встраивают даже превью внешних сайтов, A/B тесты с цветами кнопок гоняют, а вы же предлагаете отправить человека на сторонний сайт, причем, в отличие от OAuth через популярные сервисы, не на специальную страницу, которая вернёт его обратно.
А что делать в случае, если я хочу авторизоваться прямо сейчас, а не через полчаса?
Не все почтовые сервисы одинаково быстры, не все антиспам сканеры одинаково качественны.
Либо: Предоставление сервиса без авторизации как есть. Действительно ли у вас такой сайт, что нужно прям идентифицировать пользователя?
Либо: Вообще забыть про пароли. Допустим, вы цветочный онлайн магазин. Предложите пользователю ввести свой телефон (заказы будут сгруппированы по нему. подтверждать телефон не обязательно). Для параноиков — предложите им придумать свой идентификатор, например «l33t0p», и всё! Допустим злобный хакер захочет взломать вас — ну подберёт он разные варианты, ну и что с того? Узнает, что некий «l33top» любит розы, а не пионы?
Либо:
1) Если уж нужно как-то юзеров идентифицировать, то предложить авторизоваться просто введя свой email. Пароль придумать не просим. Сразу предоставляем пользователю полный сервис(в пример — онлайн кинотеатры, которые дают контент без регистрации, но с рекламой). Далее авторизовываем также по почте, без пароля.
2) На почту отправляем ненавязчивое письмо с просьбо подтвердить почту, но можно и не подтверждать.
3) Когда клиент захочет оплатить какие-то услуги у вас, привязать карту там, то попросить его подтвердить почту для его же безопасности, и придумать пароль.
Хотя, опять же, выше уже замечали, что восстановление пароля по почте без контрольных вопросов — это тоже несекурно.
Сейчас очень много смс-сервисом. Можно сделать авторизацию не по email а по мобильному телефону. Мобильный телефон есть у 99% людей, а у пользователей интернета наверное и того больше. Отправлять пользователю смс-ку с номером для авторизации, и всего делов.
Не нужно лезть в почту, всё быстро и без пароля. Я так и сделал на одном проекте, правдв он пока не работает в полную силу, но тесты радуют.
Правда есть один минус, для многих, возможно, будет существенным — плата за смс-ка.
1) избавляемся таким образом от необходимость слать письмо «подтвердите вашу почту» (все ящики верифицированы таким образом по умолчанию)
2) убираем пароль
3) получаем дополнительную инфу, такую как имя
И эти кнопки пользуются популярностью — через них регистраций в несколько раз больше чем через социальные сети.
Конечно, от соцсетей есть дополнительные плюшки вроде аватарки, другой инфы, что позволяет сразу создать полноценный профиль. Но в статье речь только про авторизацию.
Комментариев слишком много, может быть кто-то уже высказывал подобную мысль. Как вы думаете, такая схема не лучше:
- Я захожу на сайт, в форму входа вбиваю свой email, отображается сообщение ожидания.
- На этот самый email приходит сообщение с ссылкой, подтверждающей вход.
- Когда я перешел по ссылке, на самом сайте обновляется страница (или редирект), что свидетельствует о том, что авторизация прошла успешно.
Над вопросом безопасности, конечно, стоит подумать. Но польза от этого подхода в том, что не обязательно подтверждать вход с того же устройства. Залогиниться можно, допустим, на компе, а подтвердить на телефоне. Потом, клиентом может быть не только браузер, но и мобильное приложение или даже телевизор.
При запросе авторизации можно отправить либо тип клиента (web, mobile, tv), либо callback url, чтобы, если клиент — web или есть url, то показать кнопку, через которую можно вернуться на сайт.
Если я вас правильно понял, вы хотите, чтобы страница (с которой отправлен запрос) сама перезагрузилась, когда вы перейдете по ссылке из письма. Идея хорошая, но тут может появиться излишние затраты либо на Long polling, либо на полноценный Web socket (запросы по таймаута — зверство, поэтому я их не рассматриваю). Но этот вариант может решить проблему с телевизорами / IoT'ами.
Можно сделать менее красивый, но и менее затратный вариант: запоминать email на который выслали письма, а после ручного рефреша страницы (или перехода на другую страницу) проверять, перешел ли пользователь по ссылке из письма и окончательно авторизовать его. Т.е. получается такая двух этапная авторизация, на первом шаге мы просто записали email в переменную сессии (localstorage / cookie / backend session), а после подтверждения активировали эту сессию.
Но нужно еще продумать о безопасность этого подхода, т.к. хранить только email в клиентской сессии, вообще не безопасно, нужно тогда возвращать какой-нибудь секрет от запроса, сгенерированный бэком, а также хранить его в sign_in_requests таблице.
С хранением на бэке, примерна такая-же история, нужно будет записывать guid сессии (cookie-based сессии) в таблицу sign_in_requests, и опять же сверять при рефреше сочетание email + secret.
С другой стороны, дико бесят сайты, где даже рефреш не помогает на одной вкладке, если зайти на другой.
А можете раскрыть почему эта техника не подходит для перечисленных платформ?
Остались варианты:
1. промежуточные почтовые сервера, через которые почта проходит в процессе доставки
2. Куча маршрутизаторов различных провайдеров и (иногда) даже стран
Вашим пользователям не нужны пароли