Зачастую, одно из первых архитектурных решений, принятых в начале разработки вашего сайта — будет использование email + password для авторизации пользователя. Эта связка прочно засела в наши головы, и мы уже на задумываемся, зачем мы заставляем людей придумывать пароль. Мы привыкли так делать.
Но давайте подумаем, возможно, вашим пользователям не нужны пароли.
Одно из возможных решений, это использовать OAuth 2.0, но не у всех пользователей может быть аккаунт в социальной сети и желание его использовать на вашем ресурсе.
Но как-же тогда избавиться от пароля? На этот вопрос, я и попробую ответить в статье.
А в чем проблема?
Единственный защищенный пароль — это тот, который вы не в силах запомнить.
Troy Hunt
Сам по себе пароль уже является проблемой. Он не выгоден, ни вам, ни вашим пользователям.
Для владельца сайта пароль не выгоден тем, что его хранение создает дополнительную уязвимость в системе. Каким бы сильным ни был ваш хеширующий алгоритм (и упаси вас господь, не использовать его) рано или поздно он станет пустяком для новых GPU, а в последствии и CPU. А если ваша база данных утечет в сеть, то это нанесет колоссальный удар по вам и вашим посетителям. Без паролей же база становится в разы менее лакомой добычей.
Для посетителей вашего сайта, пароль — это дополнительные трудности. Неопытные пользователи будут лишний раз использовать свой "обычный" пароль, повышая риск потерять его. А продвинутые пользователи будут вынуждены придумывать специальный пароль для вашего сайта или пользоваться менеджером паролей.
Сам по себе феномен менеджеров паролей, это уже костыль, который должен нам был показать всю не востребованность и неэффективность повсеместного использования паролей.
Помимо этого, вы можете дополнительно отравить жизнь вашим пользователям, заставив их периодически менять их, или запретить / заставить использовать специальные символы.
Как же быть?
Ответ — не использовать пароли. Вам достаточно знать только email пользователя.
При регистрации на сайте, вы так или иначе завязаны на пользовательской почте. Вы высылаете на нее письма с подтверждением, что пользователь является владельцем аккаунта; вы используете его для сброса пароля.
Сброс пароля уже звучит как оксюмороном. Ведь для того, чтобы задать новый пароль достаточно лишь получить письмо на email. Все. Так и зачем же вы заставляли пользователя придумывать пароль, менять его и использовать только угодные вам символы?
Ведь чтобы авторизовать пользователя, вам достаточно выслать ему на почту письмо со сгенерированной ссылкой, как при подтверждении аккаунта. Этого хватит чтобы авторизовать пользователя.
Да и современные email сервисы в разы более защищены и подготовлены к атакам, чем регулярный сайт с котиками. Доверьте хранение и защиту пароля профессионалам.
Решение
Рассмотрим пример простого сайта с PostgreSQL в качестве базы данных.
Нам будет достаточно двух таблиц (с минимальным набором полей):
users:
| Имя поля | Тип данных | Атрибуты |
|---|---|---|
| id | serial |
PRIMARY KEY |
varchar(320) |
UNIQUE |
sign_in_requests:
| Имя поля | Тип данных | Атрибуты |
|---|---|---|
| id | serial |
PRIMARY KEY |
varchar(320) |
||
| token | uuid |
UNIQUE |
| request_ip | varchar(45) |
|
| activated_at | timestamp |
NULLABLE |
| expired_at | timestamp |
Несколько комментариев на счет таблиц:
- Таблица sign_in_requests может (и должна) быть общей с "Sign Up" таблицей, т.к. в этой системе их роль идентична.
- Исходя из пункта выше, в sign_in_requests отсутствуют внешние ключи, а поле email дублируется.
- token не обязан быть uuid'ом, вы можете сделать и более короткие токены, которые можно даже ввести вручную. Но в этом случае вероятность коллизии и его надежность могут значительно ухудшиться.
- request_ip — опциональное поле, используется только для rate limit'а, или дальнейшего выяснения причин.
Процесс авторизации весьма прост:
- Пользователь вводит свой email и делает запрос.
- Вы генерируете sign_in_request, и высылаете на почту пользователя ссылку вида:
https://example.com/signin/callback/email/{{token}}. - Пользователь, перейдя по этой ссылке делает запрос к вашей базе на наличие такого token'а.
- Если такой токен есть, он не просрочен, не использован, и он последней с таким email (опциональная защита от Brute Force), то считаем, что все хорошо.
- Выставляем
activated_at=now(), чтобы предотвратить множественное использование токена. - Далее, все так-же, как и в системе с паролями, вы можете дать пользователю cookie / JWT / etc.
В качестве защиты от спама письмами, можно сделать рейт лимит, или не высылать письмо чаще чем раз в 10 минут.
Для кого?
Кому стоит использовать данную технику:
- Подавляющему большинству сайтов в интернете, в том числе блогам / новостным сайтам / форумам.
- Корпоративным сайтам, где ваши пользователи уже используют вашу внутреннюю почту.
- Сервисам, который используется периодически, но не часто: сайт интернет провайдера / оплата услуг на месяц.
И не стоит использовать данную технику:
- Когда вы сами являетесь email сервисом.
- Ваш основной клиент — это мобильное приложение / Smart TV / IoT. В этом случае, возможно, стоит оставить опциональную возможность использования пароля.
Финальные слова
Хотя, идея с отказом от пароля выглядит дико и непривычно, на первый взгляд, взамен она может дать ряд преимуществ, и облегчить жизнь вам и вашим пользователям.
Источник изображения: https://pixabay.com/en/padlock-grunge-rusty-rusting-76866/
Комментарии (497)
Sultansoy
29.10.2017 02:37Не знаю, на сколько это будет удобно, лично мне не очень хочется за каждой рабочей машиной заходить на почту. А на работе в день по несколько раз приходится менять компы.
Интересная идея сделать как в мессенджерах, через смс, но это дорого, как я понимаю.
SuperPaintman Автор
29.10.2017 02:38В целом, никто не мешает слать временны пароль на почту пользователю. Но тогда TTL такого запроса должна стать в разы короче, либо нужно будет сделать лимит на попытки ввода токена.
А СМС, да они в разы дороже, чем отправка письма.
shir
29.10.2017 11:30смс менее защищенные чем email (например к ним имеют доступ те же гос. спец. службы). Так что если делать привязку через телефон то какой-нить Authy.
lair
29.10.2017 02:42Круто, теперь, чтобы залогиниться в сервис в интернет-кафе, мне надо засветить там свой пароль от почты. Спасибо, нет.
(я уж молчу о том, что я не на каждом сайте хотел бы светить свой емейл)
SuperPaintman Автор
29.10.2017 02:44А разве входя через email + password, вы не светите email?
lair
29.10.2017 02:45А разве я обязан вводить там реальный емейл?
SuperPaintman Автор
29.10.2017 02:47Некоторые сервисы не пустят вас, пока вы не подтвердите email. Следовательно, не войдя в него, вы не сможете этого сделать.
lair
29.10.2017 02:50Ну так одноразовые емейлы же для этого и придуманы.
SuperPaintman Автор
29.10.2017 02:51А что мешает использовать одноразовый Email в этой схеме?
lair
29.10.2017 02:54То, что он протухнет через десять минут после регистрации, и любые попытки в следующий раз выслать на него ссылку обречены.
SuperPaintman Автор
29.10.2017 02:55Согласен, если вы намерены использовать этот аккаунт долгое время, то потеря доступа к email, повлечет и потерю аккаунта.
С другой же стороны, использовать временную почту для важных учеток — не очень хорошая идея.
lair
29.10.2017 02:57Хотя, если вы намерены использовать этот аккаунт долгое время, то потеря доступа к email (а временная почта это и подразумевает), повлечет и потерю аккаунта.
Почему?
С другой же стороны, использовать временную почту для важных учеток — не очень хорошая идея.
Вы же предлагаете свой подход не только "для важных учеток", а везде?
SuperPaintman Автор
29.10.2017 03:00Почему?
"Почему" потеряете доступ? Я не совсем понял этот вопрос.
Вы же предлагаете свой подход не только "для важных учеток", а везде?
Я предлагаю его как одну из альтернатив, дабы избавить пользователя от огромного количества паролей.
lair
29.10.2017 03:01"Почему" потеряете доступ? Я не совсем понял этот вопрос.
Да, почему может случиться потеря эккаунта.
Я предлагаю его как одну из альтернатив, дабы избавить пользователя от огромного количества паролей.
… ценой понижения безопасности и удобства. Спасибо, но, как говорилось выше, нет.
SuperPaintman Автор
29.10.2017 03:06Да, почему может случиться потеря эккаунта.
Почта протухнет, следовательно вы не сможете выслать на нее письмо с ссылкой на вход. Считайте, потеряли аккаунт. Разве что в саппорт писать.
… ценой понижения безопасности и удобства
А чем, помимо возможности использования одноразовых email, этот вариант менее безопасный?
lair
29.10.2017 03:07Почта протухнет, следовательно вы не сможете выслать на нее письмо с ссылкой на вход
Вы про свою систему говорите, или про существующие?
А чем, помимо возможности использования одноразовых email, этот вариант менее безопасный?
Я же уже говорил: чтобы залогиниться в сервис на чужом компьютере, необходимо зайти на нем в свою почту. Это уязвимость.
SuperPaintman Автор
29.10.2017 03:15Вы про свою систему говорите, или про существующие?
Да я все, про описанную систему выше говорю.
Я же уже говорил: чтобы залогиниться в сервис на чужом компьютере, необходимо зайти на нем в свою почту. Это уязвимость.
Да, но не большая, чем зайти даже с временной почтой и паролем.
А временные пароли по СМС / Google Authenticator / прочие 2fa могут решить эту проблему с почтой.
Да и не припомню, чтобы за последние пару лет мне хотелось авторизоваться в блоге с чужого компьютера.
lair
29.10.2017 03:19Да я все, про описанную систему выше говорю.
В вашей системе — да, так работать не будет. И это большая проблема.
Да, но не большая, чем зайти даже с временной почтой и паролем.
Эм, вы не с тем сравниваете. Сравнивать надо "мы зашли на сервис, введя почту (в худшем случае) и пароль от этого сервиса" с "мы зашли на сервис, введя почту и пароль от почты".
А временные пароли по СМС / Google Authenticator / прочие 2fa могут решить эту проблему с почтой.
Не могут. Чужой компьютер позволяет воспользоваться открытой сессией для разных странных нужд.
Да и не припомню, чтобы за последние пару лет мне хотелось авторизоваться в блоге с чужого компьютера.
Вам не приходилось, а я несколько раз за рубежом пользовался интернет-кафе и общими компьютерами в отелях.
HeadR
29.10.2017 04:10Чужой компьютер позволяет воспользоваться открытой сессией для разных странных нужд.
Элементарные правила безопасности никто не отменял. Режим инкогнито, выход из аккаунта — для кого это всё? Есть сомнения в чистоте компьютера (кейлоггеры и т.п.) — найдите другой.lair
29.10.2017 11:36+1Режим инкогнито, выход из аккаунта — для кого это всё?
Это все не помогает, если компьютер скомпрометирован.
Есть сомнения в чистоте компьютера (кейлоггеры и т.п.) — найдите другой.
Зачем мне это усложнение, если я не настолько дорожу данными сервиса, в который логинюсь?
Swiftarrow7
29.10.2017 13:43+2Мужик, если компьютер «скомпроментирован», то либо ты странный (вот на «скомпроментирован»'ном компьютере тебе не чего не поможет, чес слово такой бред несёте !), либо ты думаешь, что пароль и почта, и более того тут говориться о менеджерах паролей, не помогут! Как ты блин собираешься в кафе авторизоваться, когда у тебя все пароли в менеджере?
Говоришь надо всё равно логиниться через почту? А когда это у нас общественные компа, да и любые другие, кроме своего, стали вдруг безопасными?
P.s. не то чтобы я не доверяю любым компам, но как минимум используют режим инкогнито и отключаю всякие куки и все свои учётки активирую с помощью смс на телефон, но я это могут делать и без пароля! А идея замены на сообщение на почту как одна из функций мне лично нравится, особенно когда я сижу дома и мне лень тянуться до телефона!lair
29.10.2017 13:48Как ты блин собираешься в кафе авторизоваться, когда у тебя все пароли в менеджере?
Легко и просто: открыл менеджер на телефоне, вбил пароль в компьютер.
Говоришь надо всё равно логиниться через почту?
Нет, я говорю, что через почту логиниться не надо.
Swiftarrow7
29.10.2017 15:11Ну не логинься! Кто-то запрещает? Автор статьи говорил не про замену для всех, а для тех кому эта фича полезна, тому кому лень постоянно вводить пароль!
Для сравнения, сейчас ни кто ни заставляет вас использовать для входа смс подтверждение через телефона, но фича то есть!
Да и как по мне это удобнее чем смс на телефон, в том отношении, что я и так сижу за компом в браузере, открыть почту и посмотреть код, как например это сделано в том же Steam, не так уж и затратно по времени! А вот брать телефон, скорей всего у вас тоже так, снимать блокировку, открывать сообщение и потом вводить этот код ручками…
Полезность каждый определяет для себя сам, но как минимум — это полезная фича =)lair
29.10.2017 15:12Ну не логинься! Кто-то запрещает?
Автор, который утверждает, что пользователям не нужны пароли.
Для сравнения, сейчас ни кто ни заставляет вас использовать для входа смс подтверждение через телефона, но фича то есть!
Вы, видимо, не слышали про принудительную двухфакторную аутентификацию в онлайн-банках?
Swiftarrow7
29.10.2017 15:24Автор, который утверждает, что пользователям не нужны пароли.
Всем? Автор может так и считает, но я нет. Для меня это просто полезная фича в некоторых сервисах =)
Вы, видимо, не слышали про принудительную двухфакторную аутентификацию в онлайн-банках?
Серьёзно? То есть имея приложения для банкинга вы полезете на свой личный кошиль через хрен пойми как защищённый комп?
Зачем мне это усложнение, если я не настолько дорожу данными сервиса, в который логинюсь?
То есть ваш банковский счёт для вас это несерьёзно? Можете пояснить или я не понял, вы вроде писали, что логинетесь на сервисы данными на которых вы не дорожите, тогда зачем сейчас говорить про онлайн банки? Добавлю, что приложения на телефоне (банкинг) не плохо так защищает!!! В принципе заходите через браузер компа почти не нужно! Могу ошибаться, т.к. не пользуюсь пока!lair
29.10.2017 15:29Всем?
Статья написана так, как если бы всем.
Серьёзно? То есть имея приложения для банкинга вы полезете на свой личный кошиль через хрен пойми как защищённый комп?
Серьезно. Не подменяйте контекст, вы написали "никто не заставляет использовать смс-подтверждение" — я вам привел пример (и их много) сервисов, которые заставляют. Я вам больше того скажу, иногда приходится именно так и делать (потому что приложение для банкинга должно где-то стоять, а у этого "где-то" может не быть интернета), и вот как раз здесь принудительное подтверждение каждой операции очень помогает.
Можете пояснить или я не понял, вы вроде писали, что логинетесь на сервисы данными на которых вы не дорожите, тогда зачем сейчас говорить про онлайн банки?
Да ровно потому, что единственное, что можно украсть, когда я зашел в (хорошо сделанный) онлайн-банк — это информацию о том, где и сколько у меня денег и историю транзакций. Провести операцию без моего ведома нельзя (или очень сложно). Хотя, впрочем, я предпочту этого не делать, конечно.
Добавлю, что приложения на телефоне (банкинг) не плохо так защищает!!! В принципе заходите через браузер компа почти не нужно! Могу ошибаться, т.к. не пользуюсь пока!
Вот вы попробуйте попользоваться, когда вы находитесь в зарубежной поездке без вай-фая и сотового интернета, узнаете много интересного.
Swiftarrow7
29.10.2017 16:18-1Не подменяйте контекст, вы написали «никто не заставляет использовать смс-подтверждение» — я вам привел пример (и их много) сервисов, которые заставляют.
Во-первых не подменяю, т.к. мы с вами говорили о сервисах, данные которых для вас не важны, с этого я и начал! Во-вторых банк — это хоть и сервис, но всё таки данные там крайне важны!
Я вам больше того скажу, иногда приходится именно так и делать (потому что приложение для банкинга должно где-то стоять, а у этого «где-то» может не быть интернета), и вот как раз здесь принудительное подтверждение каждой операции очень помогает.
Вот вы попробуйте попользоваться, когда вы находитесь в зарубежной поездке без вай-фая и сотового интернета, узнаете много интересного.
Ездил не заграницу, а по России пользовался нормально. Понимаю, что Россия != Заграница, но разве нельзя купить сим-карту? Извините, но мне кажется вы тяните проблемы, которые решаются.
Если говорить о логине в банк, то вы предоставляете, скорей всего почту и пароль. Вернусь, вы всё равно подставляете важные для вас данные!
Я бы купил в аэропорту сим-карту или почитал в сети как обстоят дела с интернетом в той стране в которую лечу!
Да насчёт организованности банкинга, я вам полностью согласен. Данные передаются зашифрованными и боятся, что кто-то получит к ним доступ, не нужно, т.к. другого способа защиты попросту нет =)
P.s. Вообще есть =) Наличные деньги в сумке или потайном кармане всегда безопасней карты =)lair
29.10.2017 16:23Во-первых не подменяю, т.к. мы с вами говорили о сервисах, данные которых для вас не важны, с этого я и начал!
Так и надо было писать "никто из сервисов, данные которых для вас не важны, не заставляет пользоваться смс-подтверждениями". Впрочем, все равно не уверен, что это правда.
Ездил не заграницу, а по России пользовался нормально. Понимаю, что Россия != Заграница, но разве нельзя купить сим-карту?
Не везде можно. Не везде есть покрытие. Иногда просто жалко денег.
Если говорить о логине в банк, то вы предоставляете, скорей всего почту и пароль.
Нет, конечно. Уникальный идентификатор (в ВТБ24 — вообще цифровой) и пароль.
Я бы купил в аэропорту сим-карту
У вас много лишних денег? Ну вот купили вы сим-карту, залезли в Porthcarno, а там хрен вам, а не мобильное покрытие. А вот проводочек протянут.
Наличные деньги в сумке или потайном кармане всегда безопасней карты
Очевидно, нет. Объяснять надо?
muxa_ru
29.10.2017 17:31Вот вы попробуйте попользоваться, когда вы находитесь в зарубежной поездке без вай-фая и сотового интернета, узнаете много интересного.
Если не секрет, что это за интернет-кафе такое, где нет возможности подключить смартфон по вайфаю?
lair
29.10.2017 17:33Обычный принт-шоп в Севилье, неподалеку от Архива Индий.
muxa_ru
29.10.2017 17:44Ну вот мой пример: перед походом в принтшоп в Петрозаводске, я залил нужный мне файл на флэшку и в интернет.
Придя в принтшоп я просто продиктовал адрес и они скачали мой файл. Флэшка не понадобилась.
Вводить какие либо пароли на их компьютерах — не понадобилось.
А какой Ваш кейс, если не секрет?
lair
29.10.2017 17:46Ниже уже описал. Отличие от вашего в том, что файл не был публично доступен, поэтому я не мог продиктовать адрес.
SuperPaintman Автор
29.10.2017 16:27Автор, который утверждает, что пользователям не нужны пароли.
Видимо мы не знакомы с автором, ведь я в начале статьи явно сказал "возможно не нужны", а в конце развернуто перечислили кому эта функция могла бы быть полезна, а кому напротив.
lair
29.10.2017 16:36Видимо мы не знакомы с автором, ведь я в начале статьи явно сказал "возможно не нужны",
Заголовок статьи же.
в конце развернуто перечислили кому эта функция могла бы быть полезна
Указав там корпоративные сайты, для которых это, как уже сказано, неверно.
(да и API сейчас тоже есть много у кого)
HeadR
29.10.2017 13:43Вы самому себе противоречите. Если вы не дорожите — какая разница, скомпрометирован ли компьютер. И входя через Auth вы как раз меньше рискуете, т.к. логгер запишет временный код.
lair
29.10.2017 13:50Если вы не дорожите — какая разница, скомпрометирован ли компьютер.
Я не дорожу данными сервиса, куда логинюсь с общего компьютера, но дорожу почтой.
И входя через Auth вы как раз меньше рискуете, т.к. логгер запишет временный код.
Через OTP — да, меньше рискую. Но речь в примере шла не про OTP, а про логин через почту.
E_STRICT
29.10.2017 08:56+1Да, почему может случиться потеря эккаунта.
Email это ключ к восстановлению пароля. Если вы при регистрации использовался «одноразовый email», то восстановить пароль в случае утери будет не возможно.
Кроме того часть функционала сайта может быть не доступна без доступа к электронной почте (рассылки, уведомления и т. д.).lair
29.10.2017 11:37Email это ключ к восстановлению пароля. Если вы при регистрации использовался «одноразовый email», то восстановить пароль в случае утери будет не возможно.
Ну и пофиг, я вполне способен сам следить за своими паролями.
Кроме того часть функционала сайта может быть не доступна без доступа к электронной почте (рассылки, уведомления и т. д.).
Это меня тоже может не волновать.
smple
29.10.2017 02:52он наверно имеет ввиду сервисы которые генерируют временные ящики на 10 минут и тем самым он юзает их для регистрации не светя свой настоящий email.
и второй раз получить к тому же временному email очень мало вероятно
E_STRICT
29.10.2017 08:42+1Все популярные почтовые сервисы доступны только через HTTPS.
Germanets
29.10.2017 10:39Интернет-кафе, это не только доступ к интернету, но и чужой компьютер, которому вы не можете доверять… Никакие HTTPS не помогут на чужом устройстве.
SuperPaintman Автор
29.10.2017 10:46Мне кажется, эта проблема решилась сама собой пару лет назад, когда в каждом кофе появился Wifi.
lair
29.10.2017 11:38Далеко не в каждом, если вы посмотрите по всему миру. А уж если вам что-то напечатать надо, так и еще веселее.
Nokta_strigo
29.10.2017 13:08После введения «WiFi по паспорту» некоторые кафе перестали раздавать WiFi
Chupaka
29.10.2017 11:33я уж молчу о том, что я не на каждом сайте хотел бы светить свой емейл
Светить username+spamsite112@gmail.com и получать по факту почту на username@gmail.com не подходит под это описание?
lair
29.10.2017 11:40Не подходит. Во-первых, не у всех гмейл (а у тех, у кого гмейл, есть OpenId Connect, и им вся эта фигня с логином через емейл не нужна бы), а во-вторых, это все равно позволяет связать ящики.
Chupaka
29.10.2017 11:57Sendmail такое из коробки поддерживает, вроде как — так что привязки к Gmail особой нет. А про связь ящиков — тут уж смотря какие цели. Если цель — увести основное никому не известное мыло от направленной атаки — тогда да. Но и в таком случае можно создать ширпотребный ящик и использовать теги уже на нём :)
lair
29.10.2017 12:30Цель — не светить свою идентичность и усложнить связь учеток на разных сервисах друг с другом.
TheDarkKRONOS
30.10.2017 09:16Интересно: тут либо на каждый сервис/сайт регистрировать свою почту, чтобы «усложнить связь учеток на разных сервисах друг с другом», но это быстро надоест, а более способов я не вижу, а один E-mail уже свяжет так и так учётки между собой. Либо если сайт требует регистрацию по мобильному номеру, то как тут быть?
lair
30.10.2017 11:27Интересно: тут либо на каждый сервис/сайт регистрировать свою почту, чтобы «усложнить связь учеток на разных сервисах друг с другом», но это быстро надоест
Если надоест, значит не так уж и важно.
Либо если сайт требует регистрацию по мобильному номеру, то как тут быть?
Я без идей. Кто-то как-то говорил, что найти сервисы, имитирующие номера для смс тоже можно.
EviGL
29.10.2017 15:14На самом деле есть вариант объединить преимущества обоих подходов:
1) При регистрации попросить-таки придумать пароль, как обычно
2) При логине требовать емейл
3) Дальше предлагать либо ввести пароль либо подтверждение на почту
Все старые юзкейсы работают, но если обычный пользователь забыл пароль или не хочет париться его вспоминать-вводить, пользуется подтверждением.lair
29.10.2017 15:16Чем это (радикально) отличается от обычного "сброса пароля по почте"?
EviGL
29.10.2017 15:22Тем же, чем iPhone 1 от HTC touch :) Радикально ничем, но удобнее гораздо.
Сброс пароля заставляет вводить новый пароль, у самых умных ещё "пароль не может совпадать со старым". Новый пароль точно так же забывается когда заходишь ещё раз на сайт ещё через год.
Ну и заходить на сайт каждый раз через сброс пароля лютое неудобство и костыляторство, а тут как бы альтернативный способ: хочешь — заходи.lair
29.10.2017 15:24Сброс пароля заставляет вводить новый пароль, у самых умных ещё "пароль не может совпадать со старым".
Это если "сброс пароля" требует ввода нового пароля, а не делает автологин. Такие решения уже есть.
Впрочем, будем честными, этот описанный вами вариант реализован, например, в Slack — и вот я вам честно скажу, у меня он работает в половине случаев, а в половине глючит. А пароль работает всегда.
Tallefer
29.10.2017 15:24Удобнее — нет, если только не предлагать это прямо в процессе логина (и название сменить, да), иначе ровно то же самое. :)
E_STRICT
29.10.2017 15:22Многие так и делают когда лень запоминать или записывать пароль. Вполне себе удобно, особенно когда сайт сохраняет сессию на долго.
muxa_ru
29.10.2017 17:27-1То есть:
- у Вас есть потребность в интернете
- у Вас есть электронная почта
- при этом, у Вас нет смартфона и Вы где-то нашли интернет-кафе
Кто Вы, и как попали в наше время?
lair
29.10.2017 17:32-1Вы серьезно никогда в местах без сотового покрытия не были?
У меня смартфон-то есть, только сотового интернета нет. И дело было буквально года три назад в милом городе Севилье. И год назад на Койя-сан. И в этом году в Порткарно.
muxa_ru
29.10.2017 17:40Не могли бы Вы в точности описать решаемую Вами задачу?
А то выглядит так, что Вы хотите зайти в интернет-банк с компьютера которому не доверяете, и при этом получить смс код в местности где нет сотовой связи.
Это какой-то очень интересный кейс.
Я, как человек много путешествующий по всяким жопеням России и Европы, хотел бы понять что это за интересная ситуация и подготовиться к ней.
lair
29.10.2017 17:46Омг, да все же просто, как валенок.
Есть билет, купленный онлайн. Чтобы пройти по билету, нужна распечатка (нет, показать с устройства нельзя; и все равно на устройстве билета нет). Билет лежит в pdf в дропбоксе. Сотового интернета нет, потому что нет (вплоть до отсутствия сотовой связи вообще, так тоже бывает). Приходим в принт-шоп, у них есть компьютер, подключенный к интернету (как раз для кейсов "распечатайте мне из интернета"). Заходим в дропбокс (там пароль и 2FA, пароль в менеджере на смартфоне, 2FA в приложении на смартфоне), скачиваем файл, отдаем на печать, все.
В случае с онлайн-банкингом все то же самое, только сотовая связь есть, а сотового интернета нет (у меня так в Китае было).
muxa_ru
29.10.2017 17:52Билет лежит в pdf в дропбоксе.
То есть Вы, с таким большим, по Вашим словам, опыте и знаниях, не имеете с собой OTG и флэшки на такой случай?
StjarnornasFred
30.10.2017 01:59В чём проблема завести специальный почтовый ящик-помойку? Основная почта пусть будет для общения и важных дел, запасная — для подписок на спам и засвечивания везде, где требуется.
smple
29.10.2017 02:45+1пришел к подобному подходу довольно давно есть пару замечаний по таблице sign_in_requests:
- Колонку email заменить на users_id (связь по primarykey как то более привычно).
- Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).
- Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену
- Колонка requestIp в реальности бесполезна (если только не супер строгая система, но там такой подход вообще не подойдет).
- Добавляю колонку deleted_at где можно деактировать любую запись
Также в некоторых случаях если не охото jwt юзать или сессии, можно добавить колонку secret(Uniq) и сообщать ее пользователю и там хранить уже в куках или localstorage и отправлять этот секрет с каждым запросом, у этого подхода есть и минусы но в некоторых случаях он прекрасно подходит
Получается колонка secret это как бы session_id который не чистится и человек авторизован пока не выйдет (logout)
SuperPaintman Автор
29.10.2017 12:45+1Колонку email заменить на users_id (связь по primarykey как то более привычно).
Как я говорил выше, в этой реализации, эта таблица может также выполнять роль
sign_up_requests. А в этом случае, у вас может еще не быть пользователя с таким email.
Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).
Тоже вариант. Но у меня были случаи, когда токен нужно было в ручном сделать "долгожителем" (для нерасторопного, но очень важного для бизнеса пользователя), при этом не меняя срок жизни остальных токенов.
Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену
Вот это крутое замечание, обновил статью.
Добавляю колонку deleted_at где можно деактировать любую запись
Как я заметил в статье, это минимальный набор, и
deleted_atболее чем нужен в реальной жизни (в том числе и в таблице с пользователями), но в текущем повествовании это было лишним.
lair
29.10.2017 02:45Корпоративным сайтам, где ваши пользователи уже используют вашу внутреннюю почту.
На корпоративных сайтах обычно используется SSO.
SuperPaintman Автор
29.10.2017 02:50Но перед тем, как зайти через SSO вы ведь должны ввести email + pass. Конечно, если ваш почтовый сервис, это уже SSO, то да, вопрос отпадает.
lair
29.10.2017 02:53Но перед тем, как зайти через SSO вы ведь должны ввести email + pass.
Эээ, почему это? Если я в домене и включена доменная аутентификация, то вообще ничего вводить не надо. Если в браузере доменной аутентификации нет, но открыты корпоративные сервисы, значит, уже есть открытая сессия, и тоже ничего вводить не надо. В-третьих, в SSO не обязательно email (и даже не обязательно пароль).
HeadR
29.10.2017 03:09А в чём проблема вместо подтверждения по емейл запросить код из Google Auth?
И безопасно и помнить не нужно. Тогда и пароль нафиг не нужен. И нет необходимости в каждом интернет-кафе почту дёргать. А уж критические изменения подтверждать по е-майл.lair
29.10.2017 03:14+1И безопасно и помнить не нужно.
Небезопасно. Украли устройство — получили доступ.
А если устройство отказало — доступ не получит даже владелец.
HeadR
29.10.2017 04:03Не будем драматизировать. Во-первых я указал что критичные изменения подтверждаются по е-мейл. Для параноиков или сайтов с деньгами можно сделать выбор «пароль/auth/пароль+auth». Во-вторых — если вы забыли пароль (равноценно утере девайса) — всё равно в тот же е-мейл для восстановления полезете. И не забывайте, сервер может проверять белые списки, смотреть были ли заходы с этого ip ранее и проводить иные проверки, и при сомнениях задавать пользователю разные неожиданные вопросы из ряда секретных или требовать таки ввести пароль/пин. В общем идея хороша, и всяко девайс угнать обычно сложнее, чем пароль.
lair
29.10.2017 11:42Не будем драматизировать.
Это не "драматизировать", это реальные проблемы. Кому-то может быть на них положить, так бывает. Но не всем.
Во-первых я указал что критичные изменения подтверждаются по е-мейл.
Доступном на том же устройстве, да?
Во-вторых — если вы забыли пароль (равноценно утере девайса) — всё равно в тот же е-мейл для восстановления полезете
Это если восстановление через емейл.
В общем идея хороша, и всяко девайс угнать обычно сложнее, чем пароль.
Да нет, просто забрал со стола и все.
HeadR
29.10.2017 13:46-1Кому-то может быть на них положить, так бывает. Но не всем.
Судя по вашим сообщениям выше, вам положить. Но потроллить-то надо.
Доступном на том же устройстве, да?
Нет, на телефоне только 2fa.
Да нет, просто забрал со стола и все.
А вы не бросайте на столе телефон с 2fa, если вы такой параноик.
wyfinger
29.10.2017 03:18-1Предлагаю диаметрально противоположное — для авторизации на сайте предлагаем ввести пользователю только пароль. Действительно, зачем при авторизации нужен логин?
Email, имя и еще какие-то данные могут спрашиваться при регистрации и использоваться, например для рассылки уведомлений, но при авторизации спрашивать только пароль. Да, пароли у всех должны быть одинаковые, потому-что автогенерируемые.
P.S. Пытался опубликовать заметку на эту тему на хабре, хотя суть укладывается в одном предложении.lair
29.10.2017 03:21для авторизации на сайте предлагаем ввести пользователю только пароль. Действительно, зачем при авторизации нужен логин?
Чтобы исключить ситуации, когда пароли совпадают.
(еще чтобы усложнить перебор, конечно же)
wyfinger
29.10.2017 03:40представьте, что пароль у вас — это склеенные email и пароль.
пароли и должны быть у всех разные. если они настолько просты, что совпадают — сам себе злобный буратино.kuber
29.10.2017 08:31+1>> если они настолько просты, что совпадают
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
vladimirkolyada
29.10.2017 09:18-1А не надо проверять после выдачи, пароль генерируем сами, уникальным:) это как пример.
kuber
29.10.2017 09:42>> пароль генерируем сами, уникальным
Вам за это не один пользователь спасибо не скажет. Например, видели какие сейчас имена электронных адресов автоматически предлагают Яндекс, Google? А мы тут вроде как про удобство.
wyfinger
29.10.2017 09:19-2Для неавторизированного пользователя отображаем поле ввода пароля, человек вводит свой пароль, берем от него хеш (с солью), проверяем есть ли такой пароль в табличке, если есть — авторизуем пользователя, если нет — это новый пользователь, предлагаем ему ввести доп информацию о себе, например email или что кому нужно.
На счет одинаковых паролей, просто хочу показать, что подход с одним паролем ничем от логина и пароля не отличается, только это удобнее.kuber
29.10.2017 09:36+1>> водит свой пароль, берем от него хеш (с солью)
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.wyfinger
29.10.2017 13:14Соль или должна быть одна, общая, или генерироваться из пароля.
lair
29.10.2017 13:33Соль или должна быть одна, общая, или генерироваться из пароля.
А вы уверены, что у вас криптографическая стойкость от этого не упадет? По идее, должна бы.
kuber
29.10.2017 14:19Криптографическая стойкость при этом пострадает. Любое упрощение аутентификации не должно приводить к дырам в безопасности. Если вы уж решили ограничиться только паролем, то хотя бы его надо хранить грамотно.
vitaliy2
29.10.2017 20:37Соль должна генерироваться из логина, а не из пароля. Ну и статическую соль для всех юзеров тоже добавить.
lair
29.10.2017 11:47+1На счет одинаковых паролей, просто хочу показать, что подход с одним паролем ничем от логина и пароля не отличается, только это удобнее.
Ничем не отличается? Как вы защититесь от ситуации "ошибся в одном символе пароля, попал в чужую учетку"?
savostin
29.10.2017 12:11И как бороться с подбором пароля?
Т.е. тупым перебором можно подобрать всю базу аккаунтов.wyfinger
29.10.2017 12:52Предложу аналогию с симметричными алгоритмами шифрования. Одного пароля достаточно и, если пароль достаточно хороший «тупым» перебором его подобрать «проблематично».
savostin
29.10.2017 13:06В чем проблематичность перебора?
Если у сервера есть логин, то перебор пароля пресекается после N неудачных попыток входа в этот аккаунт — все остальные работают. Если у Вас только пароль, то можно бесконечно долго подбирать пароли — Вы не можете пресечь эти попытки, только положив весь сервер.wyfinger
29.10.2017 13:32-1Точно также как можно бесконечно брутить пароль для зашифрованного архива и если пароль достаточно сложный ничего не получить, не смотря на то что никто и никак не может ограничить попытки подбора этого пароля.
Тем более, что с брутом пароля к аккаунту на веб-сервисе все-таки есть некоторые возможности ограничить попытки брутфорса, например по ip.
И еще, я не предлагал использовать эту систему для всего, например для денежных операций. Мне кажется для различных сервисов должны использоваться разные подходы. Я скорее про те сервисы, брутить пароли для которых никому особо и не нужно (в смысле не стоит стоимости этого самого брута).savostin
29.10.2017 13:35+1В случае с паролем к архиву у Вас всего один вариант пароля.
В случае с сервисом злоумышленник может подобрать все пароли или большую часть. Особенно, если ему все равно какой аккаунт взламывать.wyfinger
29.10.2017 14:08Согласен, т.е. подбор пароля для базы из 10000 пользователей упрощает задачу на log(10000,2) = 13.3 бит. Пароль из 16 символов это около 85 бит (если только английские символы и цифры).
И еще, что если злоумышленник уже как-то слил базу с хешами и теперь ему нужно подобрать пароль к хешам.
Интересно кстати, никто еще не придумал делать табличку с хешами пользователей общедоступной?
Опять же на первый взгляд может показаться дикостью, с другой стороны можно привести аналогию с шифрованием по типу «черного ящика» и нормальным шифрованием, когда известно как шифруется и зашифрованные данные общедоступны, но расшифровать их не так-то просто.
aelaa
29.10.2017 10:47И для хеша это простейший запрос к бд, разве что строка для проверки длиннее.
kuber
29.10.2017 14:06+1>> И для хеша это простейший запрос к бд, разве что строка для проверки длиннее.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
lair
29.10.2017 11:44представьте, что пароль у вас — это склеенные email и пароль.
Представил. Чем это теперь отличается от введенного логина и пароля? Тем, что все в одном поле?
пароли и должны быть у всех разные
Ну то есть надо будет взять какой-нибудь аналог GUID, с криптографической случайностью? Вот эти пароли и правда только в менеджере хранить, а тогда уже нет разницы, сколько полей вводить.
(защита от перебора все равно усложняется)
ivlis
29.10.2017 04:48У меня все логины (где это не обяхательно имя пользователя или email) выглядят вот так: RMz-utG-7C
wyfinger
29.10.2017 05:43Но вам приходится заполнять в форме два поля, это не удобно и это излишне.
Мысль использовать только пароль, конечно, может показаться дикой, но только сначала.ivlis
29.10.2017 06:09За меня это делает автозаполянлка, ей всё равно сколько полей.
Кстати, на счёт одного пароля, это я где-то такое видел на очень древнем сайте. Просто даётся некий id и всё.wyfinger
29.10.2017 09:13Если вспомните где это видели, напишите пожалуйста здесь.
ivlis
29.10.2017 09:28Это был какой-то адовый правительственный сайт из 90ых :)
SuperPaintman Автор
29.10.2017 10:49Если не изменяет память, так делает саппорт Webmoney, он просто выдает вам токен на вход в чат.
BOM
29.10.2017 13:42+2Внимание! Введенный вами пароль уже используется пользователем Вася Пупкин. Пожалуйста, введите другой пароль.
ebragim
29.10.2017 03:51Это в разы опаснее: придётся кучу раз заходить на почту на всех компах, с которых вам потребовалось зайти на форумы или интернет-магазины.
При защите паролем — чем меньше мы его вводим, тем надёжнее.
Такая авторизация имеет смысл в паре с простым паролем, типо 4х цифр: часть функционала на нём, а все критичные действия — через авторизацию в почте.
ivlis
29.10.2017 04:46То есть, чтобы залогиниться на форум мне надо ещё и почту проверить и что-то там ткнуть, вместо того чтобы автозаполнение само за меня заполнило. У — удобство. А если учитывать, что добрые 90% моих учёток загеристрированны с почтой на 10minutemail.com то становится вдвойне весело.
powerman
29.10.2017 04:55У сброса пароля через почту всё-таки есть одна дополнительная фича — хоть взломщик и получит таким образом доступ к аккаунту (если у него уже есть доступ к почте), но владелец аккаунта тоже узнает о взломе — ведь взломщик не знает старый пароль и не сможет его восстановить, даже если другие следы (письмо со ссылкой сброса пароля) он сможет подчистить.
Что касается большого срока жизни сессии — какая разница, надо вводить пароль или нет, если это надо делать раз в год?
Ну и последнее, про менеджеры паролей. По-хорошему, если уж Вы заботитесь о безопасности пользователей, то нужно наоборот, приучать и стимулировать использовать менеджеры паролей. Что касается сложности в использовании — то с тем же KeePass всё наоборот намного проще, чем в Вашей схеме — когда я вижу форму логина на сайте я нажимаю Ctrl-Alt-A и… всё. KeePass сам определяет что это за сайт, сам вводит логин/пароль или что на этом сайте нужно, и сам отправляет форму. Так что вся "сложность" использования менеджера паролей заключается в однократном добавлении записи о новом сайте при регистрации (с процессом которой KeePass так же помогает генерируя пароль).
sayber
29.10.2017 05:13Я вам так скажу, многие сервисы, высылают пароль на почту а не генерируют новый (уже меньше таких стало, но имеют место быть. Даже в топовых интернет-магазинах).
powerman
29.10.2017 06:41-1А! В смысле, они высылают не новый случайный пароль (что тоже плохо, особенно если при этом старый пароль удаляется), а текущий пароль? Т.е. хранят пароль без хеширования, помимо прочего. Ну, что тут скажешь, в таких веб-магазинах надо голосовать рублём, удаляя аккаунт и отправляя письмо по всем доступным email-ам руководства, объясняя почему дальнейшее использование их веб-магазина не представляется возможным.
sayber
29.10.2017 13:28Да, пароли без хешей, бери и пользуйся. Высылают ваш старый пароль.
И это я говорю не про маленькие, неизвестные магазины, про крупные точки.
Tallefer
29.10.2017 05:48Идея-то может и хорошая (избавиться от множества паролей), но вот реализация…
Тут можно провести две аналогии:
- Это OAuth. Но не OAuth, а хуже. Потому что это просто почта. Кэп доволен. %)
безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты
Это менеджер паролей. Потому что в итоге — все равно нужен один пароль. Но это хуже менеджера паролей, потому что… ну вы поняли. %)
В обоих случаях есть общая черта — мы используем почту не по назначению, отсюда огребаем косяки с пограничными случаями и удобством. Отсюда вывод — надо использовать менеджеры паролей, потому что они ради этого и придуманы! Минус только один — менеджер паролей есть не у всех, и он не стандартизован (так, как почта). Хотя, с момента распространения соцсетей и смартфонов, и почты, вероятно, у кого-то уже может не быть… но это уже не проблема запоминания паролей.
И да, есть еще вариант — ключ. Это можно считать за длинный незапоминаемый логин+пароль, если угодно. Или просто хардварный ключ.
Tallefer
29.10.2017 05:58Ах да, забыл еще важный момент — почта никак не гарантирует сохранность ваших паролей! Вот у меня, к примеру, мыло.жру регулярно стало отжимать почту в этом году, но, к счастью, я там давно ничего важного из логинов уже не держал или перевел от греха подальше в короткие промежутки, пока был доступ… Или вообще контора, держащая серваки, разорится/реорганизуется и домен с почтой пропадет навсегда.
Такие дела. :)powerman
29.10.2017 06:30К счастью, пока что все основные сервисы предоставляют POP3. Плюс можно зарегать собственный домен чтобы ни от кого не зависеть. Тогда все письма будут скачиваться на личный комп и аккуратно бэкапиться в зашифрованном архиве в облако. С другой стороны, домен, наверное, тоже могут отобрать… как страшно жить, да.
ivlis
29.10.2017 06:11+1Менеджер паролей это PKI. Но не PKI, а хуже. Почему сайты не делают аутентификацию по пользовательскому сертификату — не ясно.
powerman
29.10.2017 06:35Некоторые делают: webmoney, startssl. Геморроя с этими сертификатами — море. Нет, после регистрации всё неплохо, сертификат установлен в браузер и дальше логиниться несложно. Но чтобы не остаться без доступа приходится из браузера этот сертификат выковыривать, сохранять в отдельный файл, при этом его шифруя паролем (который ещё нужно добавить в менеджер паролей, угу), импортировать его в другие свои браузеры (а что, если доступ нужен с чужого компа, кстати?) и потом ещё не забывать обновлять эти сертификаты (во всех браузерах, чтобы не скучно было) раз в 1-3 года. Спасибо, но нет!
ivlis
29.10.2017 06:42-2Ну это проблема в том, что в браузере нет удобного интерфейса, а не в сертификате. Пароль тоже надо менять. Заходить в почту или интернет банк с чужого компа я бы и так и не стал.
Electrohedgehog
29.10.2017 06:50+2Это и в самом деле очень удобный и правильный метод авторизации для не критичных сервисов. Единственно что для решения ситуации со сломанной почтой я бы оставил как альтернативу традиционный вход.
Вообще, если посмотреть на все крупные сайты, сейчас уже нормой является привязка авторизации к браузеру через куки или локальное хранилище, что принципиально ничуть не безопаснее вашего вашего метода.
aik
29.10.2017 07:06+3Увеличивается время входа на сайт. Ввести логин и пароль гораздо быстрее.
SuperPaintman Автор
29.10.2017 10:51-1Увеличивается время входа на сайт.
Вы имеете ввиду время сессии / срок действия cookie?
aik
29.10.2017 12:21Нет, сам процесс входа. Вместо «ввёл имя, ввёл пароль, нажад вход» получается «ввёл почту, открыл вкладку с почтовым ящиком/почтовый клиент, открыл письмо, нажал на ссылку».
Плюс многие сейчас почту только на телефоне читают, а пароль от почты могут даже не помнить. И им тогда придётся ручками ссылку вбивать. Лучше уж цифровой код присылать. Ну или и то и другое сразу.
В общем, хуже только вход на сайты через соцсети устроен, когда тыкаешь «войти через фэйсбук», а тебя, после подтверждения доступа на фэйсбуке, кидают на форму регистрации на самом сайте. Нахрена тогда вообще фэйсбук тут нужен был?
Tallefer
29.10.2017 12:43Нет, просто представьте, что ходите в интернет через диалап. Но сайты уже совсем не те, что были при диалапе. %)
SagePtr
29.10.2017 07:09Одно из возможных решений, это использовать OAuth 2.0, но не у всех пользователей может быть аккаунт в социальной сети и желание его использовать на вашем ресурсе.
А что мешает использовать несколько способов аутентификации? Кто хочет, тыкает «войти через facebook» и логинится через него, кто хочет — регистрируется через логин-пароль и использует их для входа на сайт? Как вариант, можно даже руководствоваться таким принципом: если соцсеть отдаёт е-мейл, привязанный к учётной записи, то считать, что соцсеть уже подтвердила принадлежность этого адреса владельцу (но предварительно проверить используемые соцсети, что они действительно проверяют при привязке почту, а не разрешают забить туда любой адрес безо всякой проверки)SuperPaintman Автор
29.10.2017 10:53Заметьте, я не сказал ни слова против OAuth. Подход описанный выше может спокойно сосуществовать с ним (в принципе, как сейчас и происходит).
niga
29.10.2017 07:15+1На сайте издательства «Манн, Иванов и Фербер» (не реклама) давно реализован похожий способ аутентификации.
SuperPaintman Автор
29.10.2017 10:54Возможно. Я к сожалению не знаком с таким ресурсом, но охотно верю, что такой подход могли применять и раньше.
MikChan
29.10.2017 07:37+2Вот я рядовой ленивый пользователь.
Я, скорее всего, зайду на сайт, введу свой мейл и… А пароль вводить? Ощущение, что на меня хотят повесить e-mail-рассылку (так, по сути, и есть, если задуматься), как-то подозрительно это, и, скорее всего, я просто покину сайт. Минус пользователь.
Пол беды. Допустим, я об этом не задумался.
Захожу на сайт, ввожу мейл, радостно тыкаю кнопку входа… И оно мне сообщает, что нужно что-то там открывать и что-то там тыкать… Ой, Господи, ну его нафиг. И просто закрою вкладку.
Ладно, это я к чему. К тому, что хоть эта схема и придумана для самых непродвинутых пользователей, именно их она и отпугнет от использования сайта, я считаю. А нормальные люди используют менеджеры паролей. Поэтому, отток пользователей после введения такой системы входа не был бы чем-то странным, по-моему.SuperPaintman Автор
29.10.2017 10:57-1Как я сказал в заключении, этот подход непривычен. Но никто не мешает вам рассказать пользователям, как пользоваться такой "фичей".
К примеру, сделать галочку "я не хочу использовать пароль". А остальное дело времени и выработки рефлексов.
svanichkin
29.10.2017 12:22Как раз искал этот комментарий что бы самому не писать… Действительно если сервис не пускает тебя сразу, а заставляет идти и тыкать ссылку где то в письмах в 99.9% случаях такой сервис не нужен никому. Первое о чём нужно думать в любой реализации это об удобстве пользователя. Да, действительно пароли и логины надоели, но перекладывать на устаревшый уже морально email это плохой вариант. Более того, даже эти несчастные смс подтверждения уже порядком надоели. А точно идентифицировать юзерское устройство нельзя (можно было бы скажем какой то ключ устройства типа IMEI использовать, но тоже мимо.
E_STRICT
29.10.2017 12:28+1Действительно если сервис не пускает тебя сразу, а заставляет идти и тыкать ссылку где то в письмах в 99.9% случаях такой сервис не нужен никому.
Мне нужен. Я один такой из тысячи?
Kane
29.10.2017 14:53На практике это будет выглядеть немного по-другому. Ты зарегистрируешься в сервисе и подтвердишь свою почту, перейдя по ссылке из письма. После перехода получишь вечную куку и больше авторизовываться тебе уже не нужно. Это ничем не отличается от обычной регистрации.
dreka5
29.10.2017 08:14+1ровно такие же мысли стали посещать, когда каждый сервис требует логина, пароля и прочего. причем, что у каждого сервиса свои требования к сложности пароля. в итоге этот набор просто не вспомнить…
эх, раньше как было. на мэйлру завел почту в 99 году. пароль был всего 3 цифры.SuperPaintman Автор
29.10.2017 10:58-1И долго вы оставались владельцем почты с паролем из 3 цифр? :)
E_STRICT
29.10.2017 08:24Хотя, идея с отказом от пароля выглядит дико и непривычно,
Вообще этой идее как миниму лет пять. И даже есть реализации для фрейворков и CMS.
nopassword.alexsmolen.comSuperPaintman Автор
29.10.2017 10:59Охотно верю, но раньше решения предложенного вами не встречал.
Да и сама статья лишь объясняет такую схему и возможное решение, а не жестко определяет реализацию. Так что они могут сосуществовать.
flatscode
29.10.2017 08:26+1В «Telegram» тоже сначала не было паролей. Но потом под давлением обстоятельств пришлось сделать, хоть и опционально.
zcasper
29.10.2017 08:49+2Вы не избавляетесь от пароля, вы перекладываете «сервис аутентификации» на сторонний ресурс (в статье это почта, некоторые еще используют sms). Из плюсов:
— Вы перекладываете написание/сопровождение аутентификатора на сторонний сервис
— Вашим пользователям не нужны пароли у них есть почта/sms
Из минусов:
— Для входа на ваш ресурс необходимо войти/проследовать в зависимый сервис
— В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Относительного последнего пункта есть оговорка, пользователь может для каждого аккаунта заводить отдельный ящик,…
но как бы проще тогда уже просто, регистрация с логином паролем и все счастливы…
Послесловие: я не считаю данный подход ущербным, но напоминаю что убирать пароль совсем, это тоже плохая идея, оставляйте хотя-бы на тот случай если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).
Спасибо за внимание…SuperPaintman Автор
29.10.2017 11:05+1вы перекладываете «сервис аутентификации» на сторонний ресурс
Так это и прекрасно. Зачем моему сайту с котиками хранить пароли от пользователей, которые могут только комментировать.
В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Да, ровно как и сейчас. Если у вас взломали почту — то вы потеряете и доступ к большей части сайтов вместе с ней. Т.к. "ресет пароля".
если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).
К сожалению, опять же, большинство сервисов не позволят вам сменить почту / телефон, пока вы не зайдете в старую, и не подтвердите смену.
E_STRICT
29.10.2017 08:59В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Так ведь и при обычном способое взломщик может получить доступ ко всем привязанным аккаунтам через востановление пароля.zcasper
29.10.2017 09:13Давай-те не будем путать алгоритм аутентификации и алгоритмом восстановления пароля. вещи таки разные (не смотря на то, что сделаны у многих рукожопо).
Владелец сайта при создании/внедрении алгоритма восстановления пароля должен учитывать что почта может быть взломана (привет «Секретные вопросы» например)SuperPaintman Автор
29.10.2017 11:09Секретные вопросы
Еще один излюбленный инструмент садиста. Я с большей долей вероятности забуду "Имя первой учительницы", чем сгенерерованный 64'ех символьный пароль.
P.s. менеджер секретных вопросов может стать неплохим стартапом.
Tallefer
29.10.2017 12:59Но это не так. :) Сколько уже было статей на тему «лучше запоминаемые длинные пароли, чем рандомный набор символов». Другой вопрос, что длиной-то многие как раз и жертвуют…
zcasper
29.10.2017 13:27дак там суть не в вопросах,. а в том чтоб задать простую фразу (не обязательно ответ) по которому система вас идентифицирует
sumanai
29.10.2017 19:06P.s. менеджер секретных вопросов может стать неплохим стартапом.
В KeePass + KeeFox можно настроить заполнение любого поля на странице. А вообще я туда забиваю случайные символы, пока в лимит не упираюсь.
DarkByte2015
29.10.2017 09:21-1Я вот только одного не могу понять: значит любой кто узнает email пользователя сможет войти в его аккаунт на сайте? Так ведь на многих сайтах даже пишут email в профиле открыто. По моему бредовая затея.
P.S. Другой вопрос OAuth. Вот это конечно удобная штука.DarkByte2015
29.10.2017 11:09upd. Кажется понял. Я невнимательно прочитал про процесс авторизации, извините.
shushu
29.10.2017 10:29Я бы еще добавил к этому функциональность «запомни меня» с двойным токеном и защитой от кражи кук.
SuperPaintman Автор
29.10.2017 11:10Это уже исключительно ваше желание, описанная реализация выше — лишь минимальный набор. Но да, я бы тоже навернул сверху дополнительных защит.
NoRegrets
29.10.2017 11:04Каким бы сильным ни был ваш хеширующий алгоритм (и упаси вас господь, не использовать его) рано или поздно он станет пустяком для новых GPU, а в последствии и CPU.
Все остальные решения по сервису тоже принимать с оглядкой на то, что может случится в ближайшие 200 лет?
Tyusha
29.10.2017 11:11У меня почта первый ссылается и собирается в один ящик, и это поисходит не быстро. Вижу минус в том, что входа на сайт, мне придётся ждать от 2 и более минут, пока дойдёт мэйл авторизации.
vkirkizh
29.10.2017 11:11А если я хочу передать доступ к аккаунту кому-то (другу, коллеге)? Мне придется дать доступ к своей почте или менять почту на другую, специально созданную для этого сервиса?
SuperPaintman Автор
29.10.2017 11:13Если разрешите позанудствовать, то "шарить" учетки, как правило, запрещено на любом сайте.
А касаемо вашего вопроса. В этой реализации вам достаточно скинуть вашему коллеге ссылку на авторизацию, которая пришла вам на почту. Он перейдя по этой ссылке сразу же станет авторизованным пользователем.
Buddser
29.10.2017 11:15+1интересный подход, однако как по мне, слишком муторно каждый раз лазить в почту, чтобы получить ссылку на необходимый ресурс. сайт по идее все равно будет хранить библиотеку емайлов, похитив которую уже можно совершать спам рассылку и в итоге претензии пользователей все равно будут направлены на обладателя сайта. по мне как будто-то в данной схеме не хватает какого-то звена (не пароля :-) ), но повторюсь подход показался интересным
E_STRICT
29.10.2017 11:52слишком муторно каждый раз лазить в почту, чтобы получить ссылку на необходимый ресурс
Каждый раз лазить в менеджер паролей чтобы получить пароль ещё более муторно.Buddser
29.10.2017 12:52могу сказать только про себя — таким сайтом я бы не стал пользоваться. менеджерами паролей не пользуюсь впринципе.
sumanai
29.10.2017 19:18Зачем туда лазить? Автозаполнение рулит.
Tallefer
29.10.2017 19:28Ну не то, что бы прям рулит (возможность взлома и перехвата), но нажать одну кнопку — точно необременительно. :)
sumanai
29.10.2017 21:12Возможность перехвата там не выше, чем при ручном заполнении, а может даже ниже, так как менеджер паролей может более строго проверять адрес страницы, чем человек.
Tallefer
29.10.2017 21:15Выше, выше. Это как с переходом улицы, вроде и зеленый свет, а посмотреть по сторонам все же не повредит. :)
Ну пока что я видел только предупреждение о незащищенной форме, а от митм менеджер вряд ли поможет, это не его профиль же…
Art3
29.10.2017 11:15Для некоторых категории сайтов (например новостных или любых других «пассивных» ресурсов) может быть достаточно вообще только email. При регистрации авторизация прилетает на почту, регистрировались — подтверждаем. Далее для входа просим полностью указывать зарегистрированный email.
Для «взлома» нужно знать, что пользователь с конкретным адресом почты зарегистрирован на ресурсе. Весь профит, который получит «взломщик» — информацию о том, что я отписан от новостей спорта. Мой же профит в отсутствии необходимости запоминать очередную связку логин / пароль.SuperPaintman Автор
29.10.2017 11:16Это еще более упрощенный вариант. Но тут прямо на лицо огромная дыра в безопасности. Хотя все зависит от ваших потребностей.
Tyusha
29.10.2017 11:51Всецело поддерживаю Art3. Мейлы у всех разные, коллизии пользователей не будет, как в случае, когда выше предлагали оставить только пароль. Т.е. надо разрешить пустой пароль, что означает его отсутствие, а кому важна безопасность, тот пароль введёт.
Мы ведь пользуемся кучей не критичных сайтов, где просто хотим, чтобы сайт нас "узнал". Меня не волнует, что в интернет-магазине кто-то случайно или со зла зайдёт в аккаунт и узнает, какой кошачий корм я заказала и адрес доставки. Да и пожалуйста. Пакости типа отмены заказа я узнаюю по смс-уведомлениями магазина.
И вообще, кому это надо делать? Большинство из нас на таких сайтах "неуловимые Джо".
Tallefer
29.10.2017 13:14Адрес доставки? Добровольно отдать? То есть квартира, где деньги лежат, уже известна злоумышленнику, только ключа и не хватает. :3
Tyusha
29.10.2017 17:20Могу ошибаться, но в квартире деньги лежат сейчас только у бабушек и дедушек. У всех остальных они в кошельке и на карточке… Ладно, иногда могу пару тысяч на комоде оставить случайно.
Tallefer
29.10.2017 17:22Я два раза писал и потом стирал дополнение «и номер карточки»… Видимо, зря. :3
Ну ладно, но — остальные вещи в квартире — можно и потерять? :)
stychos
29.10.2017 15:57У многих систем подписки именно так.
Art3
29.10.2017 22:04Поправьте если ошибаюсь, но информация по подписке приходит непосредственно на почтовый ящик, я же говорю о сторонних сайтах.
stychos
30.10.2017 00:40Может, я что-то неправильно понял, но пару раз видел такую схему: ползаешь на сайте, что-то делаешь, можешь зарегистрироваться (спросят только имейл), дальше начинают периодически сыпаться письма с этого сайта. Из письма же можно кликнуть, и тут два варианта — либо они вообще используют сторонний ресурс для подписок, на котором, опять же, отписвыаемся только по имейлу, либо у них такое же, но своё, в этом случае личный кабинет пароля не имеет, его можно добавить опционально.
Neradivy
30.10.2017 09:14Информация, которую получит взломщик, позволит ему подписать Вас на рассылку, например — таким образом, чтобы срабатывали исключения спам-фильтра. А это деньги рекламодателей в кулхацкерский общак, формирование мнений, вбросы и прочие радости, обессмысливающие любую фильтрацию контента. В случае с интернет-магазином, Ваша учётка — это, очевидно, ещё и такая ответственность, как отзывы о товарах. Рекомендательный механизм компрометируется… Вообще, туманное стремление виртуальных жителей растворить свою уникальность ради "удобства" — занятный социопсихологический феномен...
sergey-b
29.10.2017 11:29-1Вам не понадобится вводить пароль, если при каждом входе будет производиться новая регистрация.
Славно.
akadone
29.10.2017 11:32+2С подобного ресурса я лично сразу проголосую ногами. Точнее удалением закладки.
На большинстве ресурсов у меня разные сложные пароли. Дома они все хранятся в браузере, доступны в любой момент через ctrl+enter. Причём если сайт меня заставляет нажимать ctrl+enter чаще чем раз в ~месяц, то он обычно сразу удаляется из списка посещаемых. Исключение пока только у алиэкспресса, так как аналогов к сожалению нет.
А если я захожу с чужого компьютера, то 10 раз подумаю посещать ли вообще определённые сайты залогиневшись. В 99% случаев этого не требуется (ну я не человек, который не может и дня прожить не отправив минимум 20 сообщений в интернет).
И кстати. Я для регистрации на всяких помойках использую не аккаунты на 10 мин, а просто левые аккаунты с бесплатных сервисов почты, которыми пользуюсь только для регистрации на подобных ресурсах. И которые естественно сразу попадают в спам-листы. Т.е. восстановить пароль при сильном желании можно, но каждый раз туда бегать — увольте. Искать среди 100 писем о том, что я выиграл $100 ссылку на авторизацию – это бред.
Так же не приемлю давать кому-то свой телефон. Даже если тот-же гугль для россиян требует его, то я просто меняю страну обитания, и регистрируюсь без. Во-первых из-за спама, а во-вторых из-за безопасности. Перевыпустить симку и снять с карты все деньги – многим как 2 байта переслать, но для этого надо знать телефон, и быть уверенным, что игра стоит свеч — на карте много денег. Что легко вычисляется по профилю и действиям пользователя.
Так что ни какого смысла менять устоявшуюся систему – нет. Ну кроме как облегчить жизнь разработчику очередного недоресурса, перевалив бремя ответственности на других.
svanichkin
29.10.2017 12:35Вообще идея простого входа в приложение без каких либо вводов логинов и паролей или авторизаций через сторонние сервисы не нова. Но реализация фактически не возможна, если например говорить о мобильных устройствах… Скажем мы регистрируем не пользователя а его копию программы или его устройство, скажем каким то алгоритмом создающим уникальный токен устройства или копии программы и затем предоставляющий этот токен в качестве ключа для работы с сервером.
Тогда, возникает ряд вопросов… Что делать например, когда юзер на втором устройстве хочет видеть свой аккаунт? Как перенести, незная токена?
Выход, есть, это хранить например этот токен в облачной экосистеме, например если говорить о iOS то хранить например в облаке этот ключ. Но опять же… если у пользователя отключено использование iCloud?
Более того, что будет когда юзер просто удалит приложение и захочет заново получить доступ к своему аккаунту?
Да, и как быть если у юзера несколько аккаунтов на одном устройстве? Как тогда между ними переключаться?
Т.е. выходит что хранить креды в любом случае где то да надо, либо на устройстве (что как я написал выше возможно лишь в исключительных случаях), либо в голове пользователя, либо можно создать пользователю квест зайди туда нажми сюда что выливается в неудобство и потерю времени.
Так что получаем простую формулу: (Быстро… Просто… Надёжно) В ней можно подчеркнуть лишь два критерия, а третий будет как раз всегда в недостатке.
Farxial2
29.10.2017 12:48В этой схеме требуется доверять почтовому сервису. И это не только ответственность на его плечах. Где гарантия, что почтовый сервис (с любой целью, например исполнение чьей-нибудь воли) не запросит аутентификацию на сайте и не откроет письмо? В текущей схеме такой сервис может сменить пароль, но пользователь хотя бы сможет об этом узнать (кроме случая, когда сайт высылает на почту сам забытый пароль). Спасибо, но нет. Практика деятельности власть имущих против простых людей, распространённая в последнее время и выражающаяся в самых разных формах, наводит на мысль, что почти никому из них нельзя доверять. А определить, кому можно, является нетривиальной задачей.
Я считаю, напротив, что для входа не нужен email и логин. Только пароль. Пусть пользователь попробует придумать пароль «password123», который ещё никем не придуман =) Хотя это не обязательно, можно использовать email/логин, просто в случае со сложным паролем в email/логине реально нет смысла, ну, кроме помощи сайту в организации данных.
Первичная обработка пароля должна производиться на клиенте по сценарию, удовлетворяющему минимальным требованиям безопасности, например PBKDF2 с большим числом циклов и уникальной для сайта «солью», и отправляться на сервер только в хешированном виде. Если всё сделано верно, сайт порядочный и не решил пошпионить (это можно проверить путём чтения кода сайта, а ещё лучше, если сообщество реализует автоматическую или полуавтоматическую проверку, если нужно то с реестром сайтов), то пользователь сможет даже использовать один и тот же пароль, при условии, что он не будет перехватываться. Тогда можно даже не стесняться требовать от него сложный пароль.
Немножко пооффтоплю.
… А ещё пользователь может добавлять в конец/начало/середину пароля имя сайта. Вот только не нужно предлагать это пользователям, потому что когда каждый начнёт так делать, взломщики это просекут и используют. Не нужно предлагать вообще ничего. Секретный и личный пароль на то и секретный и личный, что только сам пользователь знает, как придумать его. У него должен быть оригинальный подход к созданию пароля, даже несмотря на то что таких же людей как он, с оригинальным подходом, ещё 10 миллиардов. Так-то!lair
29.10.2017 13:38+2Я считаю, напротив, что для входа не нужен email и логин. Только пароль
И как вы предлагаете бороться с входом в чужие эккаунты при ошибке ввода пароля?
Farxial2
29.10.2017 14:35Никак. Т.к. если пароль действительно хороший, шанс такой ошибки будет примерно равен шансу ввести чужой email/логин вместо своего. Хотя, конечно, было бы лучше, если бы такой проблемы не было. Но что же, только ради этого иметь доп. набор буковок (а ещё помнить, на каком сайте ты регался уже давно и под старым ником, а на каком под новым)? Можно добавить ещё одно поле… 2, 3, 4… Только чем это лучше одного хорошего пароля? Можно даже добавить в его начало свой email.
lair
29.10.2017 14:38Т.к. если пароль действительно хороший, шанс такой ошибки будет примерно равен шансу ввести чужой email/логин вместо своего
С чего бы? Во-первых, пара логин/пароль длиннее, чем пароль, во-вторых, логин не случаен.
Farxial2
29.10.2017 14:49А почему никто не боится, что в каком-нибудь Bitcoin два блока будут иметь одинаковый хеш? Потому что вероятность этого ничтожна, не так ли? 256 бит это 32 байта. Хотя я не предлагаю иметь пароль на 32 байта, но в хорошем пароле это должно быть явно не 8-12 байт.
Можно добавить email/логин в начало или конец пароля. Пользователю может быть это удобно, т.к. email/логин он уже помнит и останется только запомнить оставшуюся часть пароля. Я против принудительного дополнительного поля, не имеющего под собой технического обоснования (кроме помощи сайту в организации данных).lair
29.10.2017 14:54А почему никто не боится, что в каком-нибудь Bitcoin два блока будут иметь одинаковый хеш?
Потому что ситуации разные. Когда в биткойне новый блок имеет такой же хеш, как существующий, его можно подискардить (или сравнить по содержимому). Когда пользователь ошибся на букву и вошел в чужую учетку — это совсем другой уровень уязвимости, это уже нельзя "откатить".
в хорошем пароле это должно быть явно не 8-12 байт.
В пароле на 12 символов никак не больше 12 байт (просто потому, что с практической точки зрения пароль покрывается одним байтом на символ).
Можно добавить email/логин в начало или конец пароля.
В этот момент вы получили логин-пароль.
Я против принудительного дополнительного поля, не имеющего под собой технического обоснования
Под ним как раз есть техническое обоснование: оно разрешает коллизии, описанные выше.
Farxial2
29.10.2017 15:04Эх, ладно. А повсеместные цифровые подписи, когда подписываются не сами данные, а хеши от них?
Важно ещё, какое множество символов используется.
Но зачем, если можно просто создать хороший пароль? Даже если я всегда буду добавлять email/логин в начало или конец. Вы можете объяснить, зачем нужно поле, не имеющее отношения к паролю?
Блин...-_- Вы не согласны, что шанс коллизии примерно равен шансу ввести чужой логин, основываясь на том, что логин не случаен. Но откуда Вы знаете, что, например, кто-нибудь не введёт чужой email/логин вместо своего тупо по укурке или неверно попадая по клавишам и не проверяя ввод?lair
29.10.2017 15:11А повсеместные цифровые подписи, когда подписываются не сами данные, а хеши от них?
Там тоже сверяется, что хэш совпадает с данными. А вычислительная сложность создания таких данных, хэш которых совпадет с другими данными, избыточно высока.
Но зачем, если можно просто создать хороший пароль?
Что такое "хороший пароль"?
Вы можете объяснить, зачем нужно поле, не имеющее отношения к паролю?
Для идентификации пользователя.
Но откуда Вы знаете, что, например, кто-нибудь не введёт чужой email/логин вместо своего тупо по укурке или неверно попадая по клавишам и не проверяя ввод?
Надо же не только ввести логин, но и ввести пароль от этого логина. Их суммарная длина больше, значит, вероятность ниже.
Tallefer
29.10.2017 15:20Не то, чтобы длина больше, она заранее неизвестна. :) Просто мы как бы множим пространства имен с вводом нового логина. Это может быть и плюсом и минусом.
Farxial2
29.10.2017 15:36Речь же о случайном совпадении. Почему два разных случайных набора данных не могут иметь одинаковый хеш, если два пользователя могут случайно создать одинаковый пароль?
Такой, который невозможно сбрутить или подобрать «случайно».
Например, как считаете, какова вероятность, что два разных пользователя придумают пароль, например, такой?
NintendoNintendoNintendoNintendoNintendoNintendoNintendoNintendoNintendo 777 111 555 444 666 йакреведко, креведко
Но это простой пример, конечно.
Почему пользователь должен иметь для этого специальный набор символов или использовать свой никнейм? Никнейм нужен уже после авторизации в основной части сайта, модулю авторизации не должно быть дела до того, как зовут пользователя. А вообще, обычно настоящий ID пользователя является числом, которое даже нельзя поменять и которое зависит только от порядкового номера пользователя на сайте. Но ведь и логин, являющийся также никнеймом, часто нельзя поменять. А что, если я давно сменил свой основной никнейм? Почему нельзя поменять его там же, где пароль? А если я не доверяю сайту (и регистрируюсь там, например, только потому что без регистрации невозможно что-то скачать), то почему я должен придумывать левый никнейм, а потом сохранять его у себя в голове вместе с паролем? А если можно поменять логин там же, где пароль, то почему нельзя перенести туда все символы из пароля? Если можно, то почему нельзя наоборот?
Ниже, чем случайно подобрать длинный и сложный пароль?lair
29.10.2017 15:45Почему два разных случайных набора данных не могут иметь одинаковый хеш
Могут. Какой от этого вред?
Например, как считаете, какова вероятность, что два разных пользователя придумают пароль, например, такой?
Два разных пользователя из скольких?
А вообще, обычно настоящий ID пользователя является числом, которое даже нельзя поменять и которое зависит только от порядкового номера пользователя на сайте.
… или нет. Но этого никого не волнует вообще.
А что, если я давно сменил свой основной никнейм? Почему нельзя поменять его там же, где пароль?
Иногда можно.
А если можно поменять логин там же, где пароль, то почему нельзя перенести туда все символы из пароля?
Потому что для аутентификации нужно "кто" и "что".
Ниже, чем случайно подобрать длинный и сложный пароль?
Да, если длина пароля одинакова в обоих случаях.
Farxial2
29.10.2017 16:00Когда цифровая подпись применима к объекту, который автор подписи не подписывал? Даже не знаю…
Хоть из 10 миллиардов. Я же написал, что пример простой, так что ничего страшного даже если вероятность будет большой. Хотя я в этом сомневаюсь) Намеренно подобрать возможно, а вот случайно… У остальных людей есть свои наборы слов и прочего, которые они могут расположить как угодно.
Суть была в том, что логин ? ID.
Почему иногда, если пароль можно менять часто?
Какой это имеет смысл с технической точки зрения? Всё равно, если пароль был хорошим, никто не подберёт логин — ни случайно, ни намеренно.
Но она не одинакова же, в варианте с только паролем пароль длиннее.lair
29.10.2017 16:07Когда цифровая подпись применима к объекту, который автор подписи не подписывал? Даже не знаю…
Для того, чтобы это было работающей атакой, оба объекта под подписью должны быть значимыми объектами. Введение даже банальной чексуммы делает такую атаку невозможной.
Хоть из 10 миллиардов.
Вы же понимаете, что чем больше людей, тем больше вероятность совпадения?
Хотя я в этом сомневаюсь) Намеренно подобрать возможно, а вот случайно…
Как раз наоборот, случайно вероятность подобрать выше: мы же уже решили, что идеальный пароль — это случайная комбинация.
Суть была в том, что логин ? ID.
И что?
Почему иногда, если пароль можно менять часто?
"Иногда" — "на некоторых сервисах". Потому что стоимость смены логина (точнее говоря, публичного идентификатора; стоимость смены частного логина как раз пренебрежимая) достаточно высока.
Всё равно, если пароль был хорошим, никто не подберёт логин — ни случайно, ни намеренно.
Почему "никто"? Есть вероятность, с увеличением числа людей в системе она увеличивается, причем нелинейно (опять возвращаемся к парадоксу дней рождений).
Но она не одинакова же, в варианте с только паролем пароль длиннее.
А откуда вы это взяли? Почему в варианте с только паролем пароль длиннее? Что мешает владельцу связки логин-пароль увеличить длину?
Farxial2
29.10.2017 16:25Чексумма это дополнительная сущность, разве одного хеша не должно быть достаточно?
Да.
Но Вы не ответили на вопрос. Какова вероятность для 10ккк?) Интересно же.
Но случайная последовательность это всё-таки не «123456». И чем больше энтропии, тем меньше шанса совпасть с другой последовательностью, у которой своя энтропия.
То, что для идентификации пользователя, наверное, ему надо указывать свой внутренний ID. Что не очень удобно. Но всё же,Почему пользователь должен иметь для этого специальный набор символов или использовать свой никнейм?
Значит на некоторых других этого нельзя.
Она случайно не потому высока, что в БД идексируется строка?
В таком случае может увеличиться и вероятность подбора пары логин+пароль.
С того, что у него нет серьёзных и явно показанных оснований увеличивать длину. Не мешает, конечно, ничто. Ровно как ничто не мешает увеличить длину пароля в варианте с только паролем ещё сильнее. Преимущество только пароля в том, что можно дать пользователю чётко понять, что будет, если пароль будет слабым. В случае с логином+паролем этого нет. Ну, действительно, кто случайно введёт его email/логин вместо своего и войдёт в его аккаунт?Tallefer
29.10.2017 16:34Случайность вообще штука интересная… Если рассматривать 1 попытку, то это 50/50 при любой сложности и длине. %)
А если мы про брутфорс (потенциально бесконечный), то это совсем другое.
lair
29.10.2017 16:34Чексумма это дополнительная сущность, разве одного хеша не должно быть достаточно?
Чтобы избежать описанной атаки, одного хеша недостаточно.
Какова вероятность для 10ккк?
Лень считать, извините. Приблизительно 1 — e^(-99999999990000000000/2d), где d — число возможных паролей.
То, что для идентификации пользователя, наверное, ему надо указывать свой внутренний ID.
Нет, зачем?
Она случайно не потому высока, что в БД идексируется строка?
Нет, потому, что публично видимый идентификатор может использоваться вне системы, и поэтому будет дорого поддерживать существующие ссылки.
В таком случае может увеличиться и вероятность подбора пары логин+пароль.
Увеличиться по сравнению с чем?
С того, что у него нет серьёзных и явно показанных оснований увеличивать длину.
Есть. Вероятность подбора, математически доказанная.
Преимущество только пароля в том, что можно дать пользователю чётко понять, что будет, если пароль будет слабым. В случае с логином+паролем этого нет.
Есть, конечно. Если пароль пользователя будет слабым, целевая атака на этого пользователя будет иметь высокие шансы успеха.
Farxial2
29.10.2017 16:51А от какого блока данных берётся чексумма?
Мне тоже(( Ну ладно, тогда не важно.
Ну идентификация же.
А это уже оправдание кривой архитектуры. Кто вообще сказал разработчикам таких систем, что логин и никнейм должен быть одной и той же строкой? -_- А раз уж они сэкономили (не очень понятно даже, на чём), то можно (постараться) обновить ссылки за пределами системы. Или забить, т.к. кривая ссылка за пределами системы не приводит к проблемам непосредственно внутри системы прямым образом.
По сравнению с малым количеством людей в системе.
Многих ли это нынче волнует?
Вы уверены, что пользователь со слабым паролем считает его слабым?
А ещё некоторые считают, что никому не надо их взламывать. Ну вот не надо и всё. И совсем другое дело, когда пользоваться слабым паролем становится в принципе невозможно, когда ты создашь риск случайно войти в твой аккаунт и доставить неудобств+лулзов ;) (Хотя тем, кто хочет сам словить лулзов, напротив, будет по душе такой вариант. Не то что с логином+паролем, где угадать логин может быть труднее, чем пароль.)lair
29.10.2017 17:00А от какого блока данных берётся чексумма?
От полезной нагрузки.
Ну идентификация же.
Идентификация пользователя не обязательно означает, что он должен назвать внутренний ID.
Кто вообще сказал разработчикам таких систем, что логин и никнейм должен быть одной и той же строкой?
Пользователь, которому неохота помнить две разных.
А раз уж они сэкономили (не очень понятно даже, на чём), то можно (постараться) обновить ссылки за пределами системы.
Оу. Вы себе не представляете сложности этой задачи в общем случае.
Или забить, т.к. кривая ссылка за пределами системы не приводит к проблемам непосредственно внутри системы прямым образом.
Почему же, вполне может привести — кто-то поставил ссылку на профиль одного пользователя, а теперь она ведет на другого. Репутационный ущерб, иск, штраф.
Многих ли это нынче волнует?
Всех тех, кого вообще волнует сохранность их данных.
Вы уверены, что пользователь со слабым паролем считает его слабым?
Вот для этого и есть правила, которые не позволяют ввод слабых паролей.
И совсем другое дело, когда пользоваться слабым паролем становится в принципе невозможно
… это когда они запрещены, да? Как иначе вы этого добьетесь?
Farxial2
29.10.2017 17:24Хеш сам выполняет роль чексуммы. Поэтому в данном случае чексуммы у двух блоков полезной нагрузки одинаковы.
А если имеется ввиду чексумма чего-либо внутри подписываемых данных — это уже другой уровень абстракции. Разве тот же PGP/GPG считает, например, для MKV-файла чексуммы его потоков? Тут нужен уже дополнительный функционал.
Но и не означает, что он должен называть свой ник или какую-то дополнительную сторку, тогда как он может просто назвать свой пароль — такой, какого больше ни у кого нет.
Зачем ему помнить свой ник?
Мне безразлично. Я же не считаю допустимым объединения логина и ника, так что имею на это право.
Это уже вина современной юридически-правовой системы. Однако проблема не в только в рассматриваемом сайте, но и во внешнем источнике, не осилившем распарсить страничку профиля, взять оттуда внутренний ID пользователя (который никогда не меняется) и получить ссылку на профиль. Хотя сайт должен не только хранить ID в профиле, но и предоставить API для получения ника по ID. А если разработчику лень — ну, можно сделать ссылки на профили без ников, только по ID — это дёшево и сердито. Что я ещё могу предложить? -_-
А можно воспользоваться этими правилами для создания пароля в варианте с только паролем?
Запретить их формальной проверялкой пароля на сложность не так просто, как кажется.
Вообще, если уж утверждать, что в моём варианте можно случайно попасть не в тот профиль, то минимум 2 пользователя могут создать один и тот же пароль, он пройдёт формальную проверку на сложность, а далее после кражи пароля одного пользователя им будет возможно взломать другого. Чтобы такого не было, ни у кого не должно быть одинаковых паролей, и формальная проверка пароля на сложность не обеспечивает этого.lair
29.10.2017 17:31Хеш сам выполняет роль чексуммы.
Нет, не выполняет. У хэша другая задача.
Разве тот же PGP/GPG считает, например, для MKV-файла чексуммы его потоков?
Думаю, что не считает. Но если вы возьмете другой блоб, который дает коллизию по ЭЦП, то он не будет MKV.
Но и не означает, что он должен называть свой ник или какую-то дополнительную сторку, тогда как он может просто назвать свой пароль — такой, какого больше ни у кого нет.
Тогда это будет идентификация без аутентификации. Упс.
Зачем ему помнить свой ник?
Чтобы говорить "найди меня на сайте, ник такой-то".
Однако проблема не в только в рассматриваемом сайте, но и во внешнем источнике, не осилившем распарсить страничку профиля, взять оттуда внутренний ID пользователя (который никогда не меняется)
Кто вам сказал, что внутренний ID (а) никогда не меняется и (б) доступен на страничке профиля?
Хотя сайт должен не только хранить ID в профиле, но и предоставить API для получения ника по ID.
Нет, не должен, конечно же. С какой бы радости? Внутренний ID — это внутренняя информация, детали реализации.
А если разработчику лень — ну, можно сделать ссылки на профили без ников, только по ID — это дёшево и сердито.
… и не устраивает пользователя, которому надо диктовать "ф-е-й-с-б-у-к-точка-к-о-м-слеш-один-пять-три-восемь-нувыпоняли".
А можно воспользоваться этими правилами для создания пароля в варианте с только паролем?
Можно. Но вероятность коллизии-то выше, чем если бы был еще и логин.
минимум 2 пользователя могут создать один и тот же пароль, он пройдёт формальную проверку на сложность, а далее после кражи пароля одного пользователя им будет возможно взломать другого
… так для этого надо знать, какого пользователя взламывать. А как это узнать?
Farxial2
29.10.2017 18:05Тогда предположим, что чексумма тоже оказалась одинаковой для разных данных.
Но главное, что к нему будет применима цифровая подпись, которая ему не предназначалась.
Уже на следующем этапе, найдяпарольключ доступа в своей БД, сервер получит все нужные ему данные о пользователе.
Тогда это его проблемы, что его ник не соответствует логину, чего он, вероятно, сам хотел, но при этом свой ник он не помнит.
А разве «найди меня по логину» лучше? =)
а) Например, ВКонтактик.
Но мне всё равно, пусть меняется, просто я имел ввиду постоянный ID, который можно использовать (но если он не меняется — зачем множить сущности?). Тогда пусть сайт предоставляет уникальный и постоянный ID пользователя — и всё.
б) Скажем так, я видел это на одном сайте.
Повторюсь, мне безразлично, каким ID он будет смотреть во внешний мир. Нет, Вы не подумайте, я сам считаю, что негоже палить непонятно кому внутренние ID, но тут речь о жёсткой связи логина и ника, порождающей неудобства. И с чего бы мне сейчас держать в голове ещё и данные о хреновости современных реализаций (которые одна хреновее другой)?
Всегда приходится выбирать между чем-то. Разработчик не хочет пилить норм реализацию, желающий посетить профиль хочет простой и понятный ник, юристы хотят срубить бабок из-за того что ник будет указывать на другого пользователя… Почему крайним должен быть тот, кто хочет, чтобы данные для его входа на сайт и его имя на сайте могли быть разными строками?
Но можно же сделать пароль длиннее, чтобы вероятность коллизии сравнялась с вероятностью коллизии при неудлинённом пароле в паре логин+пароль.
А вообще мне пришла в голову ещё идеяДля аутентификации используется весь пароль в целом. Но его небольшая часть, например первые или последние 7-10 символов/байт, хешируются отдельно и также отправляются на сервер. Они могут совпадать для разных пользователей, однако в таком случае пользователю выводится предупреждение, что его пароль, возможно, небезопасен.lair
29.10.2017 18:59Тогда предположим, что чексумма тоже оказалась одинаковой для разных данных.
Не, не "предположим". При правильном подборе чексуммы и хэшфункции это невозможно.
Но главное, что к нему будет применима цифровая подпись, которая ему не предназначалась.
Но поскольку мы знаем, что цифровая подпись применялась к MKV, мы знаем, что произошла подмена, и атака не прошла.
Уже на следующем этапе, найдя пароль ключ доступа в своей БД, сервер получит все нужные ему данные о пользователе.
Это все равно идентификация, без аутентификации.
Тогда это его проблемы, что его ник не соответствует логину, чего он, вероятно, сам хотел, но при этом свой ник он не помнит.
Когда "тогда"? Научитесь уже цитировать, на какую фразу вы отвечаете.
А разве «найди меня по логину» лучше?
Лучше, чем что?
Например, ВКонтактик.
У Вконтактика не меняется. Это личное дело Вконтактик. Другие сервисы не обязаны это гарантировать.
Но мне всё равно, пусть меняется, просто я имел ввиду постоянный ID, который можно использовать (но если он не меняется — зачем множить сущности?). Тогда пусть сайт предоставляет уникальный и постоянный ID пользователя — и всё.
Вот это обычно и есть никнейм. И именно поэтому его нельзя поменять.
Скажем так, я видел это на одном сайте
То, что вы где-то видели, не означает, что все должны так делать.
тут речь о жёсткой связи логина и ника, порождающей неудобства
В обмен на удобства, да. И как-то так решили, что удобства выигрывают.
Почему крайним должен быть тот, кто хочет, чтобы данные для его входа на сайт и его имя на сайте могли быть разными строками?
Потому что он в меньшинстве.
Но можно же сделать пароль длиннее, чтобы вероятность коллизии сравнялась с вероятностью коллизии при неудлинённом пароле в паре логин+пароль.
Тем самым повысив неудобство. Чем длиннее пароль, тем неудобнее.
Угадать. С такой же вероятностью, с какой у двух пользователей будет одинаковый «сложный» пароль
Эээ, откуда вероятность-то та же? Вероятность одинакового пароля у двух произвольных пользователей считается по парадоксу дней рождений, шанс угадать пользователя, у которого нужный нам пароль — m/n, где n — число пользователей, а m — чиcло пользователей с нужным нам паролем.
Farxial2
29.10.2017 20:06Не, не «предположим». При правильном подборе чексуммы и хэшфункции это невозможно.
Всё сводится к сравнению шанса совпадения паролей у двух разных пользователей с шансом совпадения хешей (а теперь ещё и чексумм) двух разных блобов. Но ведь можно уменьшить вероятность не только для 2-го, но и для 1-го. Например, та же формальная проверка пароля на сложность, можно прделать даже на клиенте.
Но поскольку мы знаем, что цифровая подпись применялась к MKV, мы знаем, что произошла подмена, и атака не прошла.
Ну, мы не открыли MKV, которое уже не MKV, но зато считается, что какие-то левые данные подписал определённый человек, хотя на самом деле он их не подписывал. Кто будет выяснять, злоумышленник он, переименовавший левые данные в MKV, или пострадавший?
Это все равно идентификация, без аутентификации.
OK. А что в этом плохого? Если отбросить формальности, конечно. Если ID достаточно длинный и не разглашается, само знание ID означает обладание секретными данными.
Когда «тогда»? Научитесь уже цитировать, на какую фразу вы отвечаете.
«Тогда» здесь эквивалентно «в таком случае», это был ответ на это:
Чтобы говорить «найди меня на сайте, ник такой-то».
Я умею цитировать, просто забил на это, т.к. мне не очень удобно делать это всё время. Можно было не реагировать на это так резко, ну -.-
Хотя мне и самому бывает неудобно, когда собеседник не цитирует, а каждый коммент разделён на много частей, так что прошу прощения.
Лучше, чем что?
Лучше, чем просьба найти его по нику, который он не помнит?
У Вконтактика не меняется. Это личное дело Вконтактик. Другие сервисы не обязаны это гарантировать.
Как скажете. Но разве они обязаны гарантировать, что у пользователя не сменится ник, логин или адрес страницы? Тот же ВКонтактик позволяет менять адрес страницы — и что, против него в этом плане бухтели юристы? Вообще, побочные эффекты освобождения адреса страницы и оккупации некогда чужого адреса — личные проблемы двух этих пользователей, и они должны быть с ними ознакомлены. Так что проблему можно решить, просто показав при необходимости уведомление или указав это в пользовательском соглашении.
Вот это обычно и есть никнейм. И именно поэтому его нельзя поменять.
Но почему из-за особенностей простых технических решений пользователь должен быть лишён возможности смены ника?
То, что вы где-то видели, не означает, что все должны так делать.
Допустим. Но это не отменяет того, что неправильную ссылку предоставил внешний источник, а не сайт. Причём ссылка могла быть действительна на момент публикации, так что никаких нарушений с его стороны тоже нет.
В обмен на удобства, да. И как-то так решили, что удобства выигрывают.
Как это может быть удобно? Нуок, ссылки на профиль, репутация на сайте, удобство поиска — смена ника может быть запрещена, так и быть. Но почему нельзя менять логин? Может, пользователю надоело вводить свой длинный и сложный ник или надоело его палить где попало (мало ли) и он хочет сменить его на «12345» (если такой логин ещё не занят)?
Потому что он в меньшинстве.
Вынужден, но не обязан. Под «почему должен» я имел ввиду «почему обязан».
Тем самым повысив неудобство. Чем длиннее пароль, тем неудобнее.
Зато поле ввода всего одно. А поскольку пользователь так привык к двум полям и в одно он всегда вводит email/логин, ему не составит труда прибавить его к своему паролю, если он не хочет чего-то большего. Неудобство только в непривычности.
Эээ, откуда вероятность-то та же? Вероятность одинакового пароля у двух произвольных пользователей считается по парадоксу дней рождений, шанс угадать пользователя, у которого нужный нам пароль — m/n, где n — число пользователей, а m — чиcло пользователей с нужным нам паролем.
Оттуда, что если считать email/логин из совокупности логин+пароль всё же частью ключа доступа, то вероятность подобрать эту часть ключа/пароля (пусть для примера будет в начале) такая же как вероятность подобрать логин. Вообще, вероятность подобрать логин даже выше, т.к. логин имеет определённую длину и после него не следует ничего, а когда он часть ключа, то после него сразу идёт начало пароля. И попробуй понять, у пользователя ник «user» и пароль «123456» или же ник «user123» и пароль «456»)lair
30.10.2017 11:39Всё сводится к сравнению шанса совпадения паролей у двух разных пользователей с шансом совпадения хешей (а теперь ещё и чексумм) двух разных блобов.
Не сводится. Кейсы разные.
Кто будет выяснять, злоумышленник он, переименовавший левые данные в MKV, или пострадавший?
Вот для этого и делается дополнительный уровень абстракции (с чексуммами и проверками семантики), которые исключают такие проблемы.
OK. А что в этом плохого?
Понижение безопасности.
Лучше, чем просьба найти его по нику, который он не помнит?
Вот именно поэтому разделение ника и логина для пользователя неудобно.
Как это может быть удобно?
Какое "это"?
Но почему нельзя менять логин?
Потому что разделение ника и логина маловостребовано, а реализацию усложняет.
Вынужден, но не обязан. Под «почему должен» я имел ввиду «почему обязан».
Потому что он в меньшинстве.
Зато поле ввода всего одно.
Это чем-то удобнее? Нет.
ему не составит труда прибавить его к своему паролю, если он не хочет чего-то большего
Составит, потому что ему надо помнить, куда прибавлять. Лишнее усилие.
Вообще, вероятность подобрать логин даже выше, т.к. логин имеет определённую длину и после него не следует ничего
Вы, кажется, не понимаете. Подбирать логин вообще не надо, список логинов обычно можно достать с сайта. Надо найти тот логин, от которого известный пароль.
а когда он часть ключа, то после него сразу идёт начало пароля. И попробуй понять, у пользователя ник «user» и пароль «123456» или же ник «user123» и пароль «456»
Понимаете, да, что это на самом деле уязвимость, а не достоинство?
otvorot2008
29.10.2017 14:37Да, это к тому же накладывает дополнительное требование на минимальное расстояние редактирования (расстояние Левенштейна) между двумя паролями, что во сто крат хуже обычного требования на длину пароля. Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Да и при использовании тривиальных схем хэширования у нас есть шанс появления паролей-коллизий, не привязанных ни к одному email.
Farxial2
29.10.2017 14:55Да и при использовании тривиальных схем хэширования у нас есть шанс появления паролей-коллизий, не привязанных ни к одному email.
Это решаемо. Например, когда пользователь устанавливает пароль (при регистрации или меняет старый), можно проверять, не используется ли хеш пароля другим аккаунтом. Правда, придётся предупреждать и владельца другого аккаунта (и принять временные меры для его защиты) =)lair
29.10.2017 15:13Например, когда пользователь устанавливает пароль (при регистрации или меняет старый), можно проверять, не используется ли хеш пароля другим аккаунтом.
Вы стоимость этой операции представляете?
Farxial2
29.10.2017 15:40Такая же, как просто попытка входа по паролю (его хешу, конечно).
lair
29.10.2017 15:46Эээ… нет. Тут в посте уже обсуждалось, что для входа вам нужно посчитать хэш единожды, а для проверки уникальности — столько раз, сколько пользователей (потому что хэш для каждого пользователя считается с разной солью).
Farxial2
29.10.2017 16:36Хеш для разных пользователей считается с одной солью.
lair
29.10.2017 16:37Какой тогда смысл этой соли? Можно ее выкинуть с тем же успехом.
Tallefer
29.10.2017 16:40Ну в теории против радуги, но тут проблемы с радугой далеко не на первом месте. %)
lair
29.10.2017 16:41Ну да, но если мы знаем соль, то можно же рассчитать радугу для заданного сайта, а потом оптом получить все парольчики, ням-ням.
Tallefer
29.10.2017 17:01Ну, это не особо отличается от просто брутфорса. :) Ведь сила таблиц в том, что их можно заранее просчитать и потом переиспользовать.
lair
29.10.2017 17:03Все-таки малость отличается: когда можно каждый сгенеренный хэш прогонять по всем пользователям сайта "а вдруг подойдет" — это ощутимо выгоднее, чем для каждого пользователя пересчитывать.
Tallefer
29.10.2017 17:13Да, но все равно считать первый раз придется. :) Тут выгода только если спереть соль в самом начале, а потом тихо ждать новых юзеров.
otvorot2008
29.10.2017 15:49Это решаемо. Например, когда пользователь устанавливает пароль (при регистрации или меняет старый), можно проверять, не используется ли хеш пароля другим аккаунтом. Правда, придётся предупреждать и владельца другого аккаунта (и принять временные меры для его защиты) =)
Во-первых, это затратно для баз с большим кол-вом пользователей. Тем более для распределенных
Во-вторых речь шла о рисках "похожести" двух паролей когда пользователь хочет ввести feezbuzz, но ошибается и вводит fezbuzz, и логинится под другим аккаунтом. Вот как раз наличие дополнительного user id (еmail или обычный логин) нивелирует этот рискFarxial2
29.10.2017 16:10Во-первых, это затратно для баз с большим кол-вом пользователей. Тем более для распределенных
Есть такое, но разве бинарное дерево поиска не решает эту проблему? Что касается распределённых, то разве нельзя держать копии на всех машинах?
Во-вторых речь шла о рисках «похожести» двух паролей когда пользователь хочет ввести feezbuzz, но ошибается и вводит fezbuzz, и логинится под другим аккаунтом. Вот как раз наличие дополнительного user id (еmail или обычный логин) нивелирует этот риск
Но если пользователи используют действительно уникальные пароли, а не «feezbuzz» — что там может совпасть? -_-lair
29.10.2017 16:18Есть такое, но разве бинарное дерево поиска не решает эту проблему?
Нет, конечно. У вас для разных пользователей хэш одного и того же пароля должен отличаться.
(кстати, это еще одно простое техническое объяснение того, почему-таки нельзя использовать просто один пароль — как вы определите, какую соль использовать?)
Farxial2
29.10.2017 16:28-1Не должен. С чего Вы взяли, что должен? O_o
Соль может быть постоянной и уникальной для сайта, см. 2-ю часть 2-го абзаца моего 1-го здесь коммента.lair
29.10.2017 16:38Не должен. С чего Вы взяли, что должен?
С того, что иначе при краже БД можно, зная пароль одного пользователя, залогиниться под всеми пользователями, у которых совпадает хэш.
Farxial2
29.10.2017 16:54Но ведь у всех должны быть разные пароли.
А вообще правильнее было бы называть это ключами доступа. //Блин, я только что заметил необходимость этого, сорри((lair
29.10.2017 17:05Но ведь у всех должны быть разные пароли.
Пароли разные, хэш внезапно одинаковый. Правда, печаль?
(ну ладно, при разумной длине хэша это чрезвычайно маловероятно, н все же)
Но даже если на это забить, анализ украденной БД с хэшами резко упрощается.
Farxial2
29.10.2017 17:32Ну поставьте SHA512, Keccak512, хеширование кусочков пароля + перемешивание байт по определённому алгоритму + шифрование в AES + повторные хеширования, или создание нескольких версий пароля (":V1", ":V2", ...) и хеширование каждого из них, я не знаю. «Всё же» не ко мне, сорян. Вы можете уменьшать вероятность сколько угодно, моя идея не включает длину хеша. Я не против, если Вы уменьшите вероятность коллизии при разных паролях до 0%.
Но ведь при хешировании в качестве «соли» (или её части, если нужно) используется имя сайта, которое больше нигде не используется.lair
29.10.2017 17:35Я не против, если Вы уменьшите вероятность коллизии при разных паролях до 0%.
Афаик, это невозможно.
Но ведь при хешировании в качестве «соли» (или её части, если нужно) используется имя сайта, которое больше нигде не используется.
Какая разница? Для всех паролей этого сайта используется одна и та же соль, это значит, что мы можем просто гонять каждый сгенеренный хэш против всей БД.
otvorot2008
29.10.2017 17:18Есть такое, но разве бинарное дерево поиска не решает эту проблему?
Скорее не бинарное, а 2-3-4 дерево, но это так — технические подробности.
Что касается распределённых, то разве нельзя держать копии на всех машинах
И получить головную боль в виде поддержки консистентности данных пользователей?
Но если пользователи используют действительно уникальные пароли, а не «feezbuzz» — что там может совпасть? -_-
Это все скорее слишком оптимистичные сценарии, не все готовы хранить и запоминать пароли на 64+ символа с равным соотношением спец. символов, цифр, букв, и уж тем более еще меньший процент готов приводить свои пароли в соотвествие с техническими рекомендациями по безопасности. Чаще запоминают мнемонические пароли, или пароли как ответы на вопросы (день рождения, имя жены, домашнего животного, и.т.д)
kuber
29.10.2017 14:55>> Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)Farxial2
29.10.2017 15:08Ну, нет, я уже думал на эту тему и считаю это проблемой. Но всё же пароли должны быть такими, чтобы такого не происходило в принципе. Скорее, я надеюсь, что пользователь, ознакомившись с принципом авторизации, придумает действительно надёжный пароль.
lair
29.10.2017 15:15Скорее, я надеюсь, что пользователь, ознакомившись с принципом авторизации, придумает действительно надёжный пароль.
"Действительно надежный пароль" — это случайный пароль определенной длины. Вероятность его совпадения повышается по мере увеличения числа пользователей. Дальше читаем про парадокс дней рождений и ужасаемся.
Farxial2
29.10.2017 15:49Ну так длина должна быть немаленькой. Однако является ли это проблемой? Вообще, в свой пароль можно добавить не только email/логин, но и номер телефона, кличку собаки и что угодно ещё.
lair
29.10.2017 15:53Однако является ли это проблемой?
Ну да, это неудобно пользователю.
Farxial2
29.10.2017 16:30Но он же может добавить к паролю свой email/логин и пароль увеличится в длине, какие проблемы?
lair
29.10.2017 16:39Это неудобно. Более того, это упрощает словарные атаки.
Farxial2
29.10.2017 16:58Это неудобно не более, чем к паре логин+пароль — поначалу всё неудобно, но можно привыкнуть и будет не хуже (конечно, при условии, что ты готов на надёжный пароль).
lair
29.10.2017 17:06Но и не менее неудобно. Зачем мне решение, которое не приносит пользы?
Farxial2
29.10.2017 18:11А почему неудобно (кроме того, что надо привыкать)? Представьте, что вы подошли к торговцу/за?мку/чему-то ещё и должны назвать секретное слово, которое сообщили только Вам и его знаете только Вы, и тогда на Вас снизойдут всякие бонусы. Неужели Вам будет удобно, если торговец/за?мок (какая-нибудь хрень оттуда) ещё и спросит, как Вас зовут? Хотя это может быть привычно. Но ведь если кодовое слово длинное и угадать его затруднительно, проблемы нет, не так ли?
lair
29.10.2017 19:00Представьте, что вы подошли к торговцу/за?мку/чему-то ещё и должны назвать секретное слово, которое сообщили только Вам и его знаете только Вы, и тогда на Вас снизойдут всякие бонусы.
Одноразовое?
Но ведь если кодовое слово длинное и угадать его затруднительно, проблемы нет, не так ли?
Проблема есть — мне надо это слово запомнить.
Farxial2
29.10.2017 20:09В текущем примере — думаю да, т.к. бонус даётся единожды) А вообще мог бы быть и многоразовым.
А как же запоминание пароля?lair
30.10.2017 11:40В текущем примере — думаю да, т.к. бонус даётся единожды
Для одноразовых бонусов разницы нет.
А вообще мог бы быть и многоразовым.
А для многоразовых начинаются проблемы безопасности.
А как же запоминание пароля?
Когда есть запоминание пароля, есть и запоминание логина, только мне еще и подсказывают, от какого логина пароль, так что в этом кейсе два разных поля выгоднее.
Tallefer
29.10.2017 15:16Не в ту сторону думали. :) НЕЛЬЗЯ отказаться от логина, только от пароля. Либо все будут анонимы.
Farxial2
29.10.2017 15:44А я не против, чтобы все были анонимами. Как что-то плохое) Однако все не станут от этого анонимами автоматически, просто наличие/отсутствие у пользователя имени будет определяться сайтом на более подходящем уровне, чем в модуле авторизации.
Tallefer
29.10.2017 15:52Суть в том, что анонимам не нужны логины и пароли в принципе. :) Любая попытка разделить пользователей — это уже логин. С паролем или без.
Farxial2
29.10.2017 16:31Значит я неправильно Вас понял( Я понял это как просто отсутствие ников. А так — да, не нужны. Но вариант с разделением, но отсутствием ников, тоже имеет право на существование)
Tallefer
29.10.2017 16:39Он неосуществим. :) Можно только «играть» в анонимов, если сервер просто не будет показывать имена, читай — логины. Но так надо определиться, со стороны системы анонимность или пользователя.
Farxial2
29.10.2017 17:03Вообще сервер не должен знать, как зовут того или иного пользователя. Он может знать, как отображать того или иного пользователя. И тут могут быть как искусственные ограничения со стороны сервера, так и вольность менять ник любым образом, в т.ч. лишь понемногу, можно даже отображать в профиле историю ников. Проблема тут только в использовании ника сервером для идентификации пользователя где-то в своей БД.
Tallefer
29.10.2017 17:16Ну и вот, хорошо, что пришли к понятию идентификации наконец. :)
Теперь можно заменить слова логин и пароль на ИД и ключ и на этом успокоиться. Или нет? :)Farxial2
29.10.2017 18:14Ну… А почему пользователь должен помнить свой ID? ИМХО, это допустимо для ID Tox или ID своего PGP-ключа, потому что их не так много как сайтов и это действительно важные вещи. А запоминать свой ID на каждом сайте — задолбаешься же.
Tallefer
29.10.2017 19:26Вот! Вот он —
яяязьглавный вопрос — почему он должен помнить? Для решения этого вопроса и существуют менеджеры. :)
Теперь осталось только осознать, что ИД и «пароль без логина» — одно и то же. :3Farxial2
29.10.2017 20:18Я тоже пользуюсь менеджером… точнее, его примитивным аналогом) Хотя, если бы сайты хешировали пароль перед отправкой к себе и не перехватывали, чтобы можно было везде использовать один пароль, я бы от такого удобства не отказался)
Почти) У логинов есть ещё такая проблема, что их трудно менять, и в случае с ними ID постоянный. А с паролем без логина пользователь всегда имеет возможность сменить свой ID.Tallefer
29.10.2017 20:24Но… нормальные сайты так и делают. :)
Кому трудно? ИД в любом случае постоянный. И еще раз: нет никакого пароля без логина, это и есть ИД. %) И если ИД менять, то это просто новая регистрация. Те же проблемы, что и со сменой логина, или большие.
otvorot2008
29.10.2017 17:12Мы исходим из предположения, что злоумышленник может получить такую возможность)
Сознательными могут быть и злоумышленники, и обычные пользователи, также как и несознательными. Не стоит уповать на одни только успешные сценарии поведения пользователя
lair
29.10.2017 17:16Первичная обработка пароля должна производиться на клиенте по сценарию, удовлетворяющему минимальным требованиям безопасности, например PBKDF2 с большим числом циклов и уникальной для сайта «солью», и отправляться на сервер только в хешированном виде.
Оу, до меня только сейчас дошло. Вот отправляется на сервер пароль в хешированном виде. А что с ним дальше происходит?
Farxial2
29.10.2017 18:19Если не использовать логина, то надо по этому хешу найти пользователя. Если использовать логин, то можно использовать хеш как угодно, например традиционным способом — проверить на совпадение. Если пользователь найден или если хеш совпадает — авторизация пройдена.
lair
29.10.2017 19:01то надо по этому хешу найти пользователя
Каким образом? Вот конкретно, прямо по шагам: у нас есть сервер, ему прилетел с клиента хеш пользовательского пароля. Что сервер делает дальше?
Farxial2
29.10.2017 20:23Ищет, например в бинарном дереве поиска или его аналогах, структуру данных, идентифицирующую пользователя (если нужно, она может быть небольшой — например, только содержать внутренний ID пользователя). Мне что, серьёзно расписывать, как искать данные по хешу? -_- Какая СУБД хоть?
lair
30.10.2017 11:42Омг. Вы понимаете, что этот ваш "хеш" — это на самом деле простой пароль (не важно, как пользователь его получил), и ваш сервер хранит его в БД в открытом виде? А это значит, что одна утечка БД — и можно залогиниться на сайт под любым пользователем вообще.
Farxial2
30.10.2017 12:10OK, тогда можно сделать лучше: пользователь отправляет на сервер H(pass), а сервер хранит у себя в БД H(H(pass)) (функции H не обязаны быть одинаковыми для обоих уровней).
Спасибо за замечание)lair
30.10.2017 12:12Радужная таблица радостно возвращает нас к открытым паролям.
Farxial2
30.10.2017 12:16Радужные таблицы для хешей длиной 256, 512 или даже больше бит (в качестве открытого текста), своя для каждого сайта?
lair
30.10.2017 12:18А зачем своя для каждого сайта? У вас тривиальное H(data), радужная таблица для H достаточна.
Farxial2
30.10.2017 12:51Своя «соль» у каждого сайта, чтобы пользователь мог (при условии, что всё реализовано правильно) использовать на разных сайтах один и тот же пароль.
lair
30.10.2017 13:41Это не важно. С точки зрения сервера приходит готовый ключ data. Как он сформирован — не важно, и злоумышленник может сразу передавать этот ключ, не заморачиваясь поиском пользовательского пароля. Поэтому на уровене сервера у вас обычные несоленые хэши, со всеми вытекающими.
Farxial2
30.10.2017 14:03OK, тогда — H2(H1(pass, client_salt), server_salt). Серверная соль уже может быть уникальной для каждого пользователя. (Но не моя идея, я видел использование серверной соли в движке одного (того же) сайта.)
lair
30.10.2017 14:05Серверная соль уже может быть уникальной для каждого пользователя
Каким образом, если вы пользователя не знаете?
(а если она неуникальна, то возвращаемся к пониженной криптостойкости)
Farxial2
30.10.2017 14:30Не знаю.
Хотя у меня есть компромисс, но погодите… А разве нельзя иметь на сервере соль, одинаковую для всех пользователей, но которую знает только сервер? Мб криптостойкость и понижена по сравнению с уникальной для каждого пользователя солью, но только после того как злоумышленник получит эту соль, он сможет свою радужную таблицу заполнить. На какое время заполнения таблицы Вы рассчитываете? И почему бы, если это время достаточно маленькое, просто не увеличить вычислительную сложность хеширования пароля (в адекватных пределах, конечно, но не обязательно, чтобы это происходило прям мгновенно)?lair
30.10.2017 14:34А разве нельзя иметь на сервере соль, одинаковую для всех пользователей, но которую знает только сервер?
Нельзя. Все, что доступно серверу, может быть украдено.
На какое время заполнения таблицы Вы рассчитываете?
Так прикол в том, что нам не надо заполнять таблицу целиком (если мы, конечно, не делаем атаку на конкретного пользователя). Мы просто начинаем генерить ее с нуля, и для каждого варианта сразу проверяем, есть ли он хотя бы у какого-нибудь пользователя. Есть — ура, у нас есть одна жертва. И так далее.
И почему бы просто не увеличить вычислительную сложность хеширования пароля (в адекватных пределах, конечно, но не обязательно, чтобы это происходило прям мгновенно)?
Потому что чем выше вычислительная стоимость логина, тем ближе вы к DoS-атаке.
Farxial2
30.10.2017 15:00Так прикол в том, что нам не надо заполнять таблицу целиком (если мы, конечно, не делаем атаку на конкретного пользователя). Мы просто начинаем генерить ее с нуля, и для каждого варианта сразу проверяем, есть ли он хотя бы у какого-нибудь пользователя. Есть — ура, у нас есть одна жертва. И так далее.
Тогда почему Вы не боитесь, что у каждого пользователя будет своя соль, но взломщик просто будет брать соль каждого, генерить его хеш с нуля и проверять на наличие?
И в случае с авторизацией только по паролю пароли всё-таки должны быть уникальными, так что не получится за один раз найти пароль сразу нескольких пользователей.
Потому что чем выше вычислительная стоимость логина, тем ближе вы к DoS-атаке.
Тут уже только выбирать: либо больше вычислительных операций на сервере, либо на клиенте. Либо Вы просто заботитесь о безопасности и неприкосновенности БД ;)
Ещё вариант — со временем увеличивать количество циклов хеширования и количество солей.
Т.е., допустим, Вы только создали сайт и изначально у вас публичная соль у клиента и секретная у сервера. Кто-то решает Вас взломать и начинает заполнять свою радужную таблцу. Проходит полгода (например), его таблица уже готова и… Тут Вы вываливаете свою секретную серверную соль клиенту и она становится публичной и теперь он должен провести уже 2 этапа хеширования (ладно, не надо повышать сложность на клиенте =)), предварительно создав на сервере новую соль и обновив все хеши в своей БД. Так готовая радужная таблица станет бесполезна.lair
30.10.2017 15:32Тогда почему Вы не боитесь, что у каждого пользователя будет своя соль, но взломщик просто будет брать соль каждого, генерить его хеш с нуля и проверять на наличие?
Потому что проверять на наличие бесполезно — поскольку у всех других пользователей другая соль, полученный пароль не подойдет. Проверять можно будет только на равенство хеша.
И в случае с авторизацией только по паролю пароли всё-таки должны быть уникальными, так что не получится за один раз найти пароль сразу нескольких пользователей.
Зато пароль случайного пользователя найти дешевле.
Либо Вы просто заботитесь о безопасности и неприкосновенности БД
Это бесполезно.
предварительно создав на сервере новую соль и обновив все хеши в своей БД
Это же невозможно. Чтобы обновить хеш, вам надо знать, из чего он посчитан.
Farxial2
30.10.2017 16:09Потому что проверять на наличие бесполезно — поскольку у всех других пользователей другая соль, полученный пароль не подойдет. Проверять можно будет только на равенство хеша.
Не подойдёт к чему? А, да...А это значит, что одна утечка БД — и можно залогиниться на сайт под любым пользователем вообще.
Изначально я хотел ответить на это по-другому (некоторые заготовки своих ответов я держу в Notepad++, так что ответ уже готов)Какая разница, кто под кем залогиниться, если у вас утекла БД? Утечка БД — это такой удар по сайту, что после него — только разгребать последствия. Аналогия: если человеку прострелят жизненно важные органы, ему будет немного не до увлажнения кожи и Боржоми. Так что после утечки БД надо менять пароли всем пользователям (хотя я не согласен с теми, кто не оставляет предыдущей копии, чтобы пользователь хоть как-то мог доказать админу, что это он, и убедить восстановить доступ).lair
30.10.2017 16:21Какая разница, кто под кем залогиниться, если у вас утекла БД?
Фундаментальная же. Во-первых, авторизационная БД не обязательно совпадает с бизнесовой, во-вторых, можно же делать кучу всего нового от имени пользователя.
Так что после утечки БД надо менять пароли всем пользователям
Вот только для этого надо узнать, что она утекла.
А если мы не хотим, чтобы взломщик узнал пароли пользователей и смог с их помощью зайти на другой сайт
Вот это меня как раз совершенно не волнует.
Будет ли пароль, который не составило труда добавить в радужную таблицу, настолько уникальным, чтобы не совпадать ни с чьим чужим паролем на том же сайте?
Не понимаю вопроса.
Нет, т.к. если взломали БД, это значит лишь, что о её безопасности недостаточно хорошо заботились.
Если подходить с этой точки зрения, то можно вообще ничего не хешировать и хранить в плейнтексте. Но так почему-то не делают. БД утекают регулярно, и будут утекать дальше.
Вы знаете: старый хеш был посчитан из отправленного пользователем хеша и старой серверной соли, а новый должен быть посчитан из этого старого хеша в БД и новой серверной соли.
В этот момент вы (а) полностью убили обратную совместимость с клиентами и (б) если кто-то увел предыдущую БД, у него теперь есть готовые пароли прямо для входа.
Farxial2
30.10.2017 17:12Фундаментальная же. Во-первых, авторизационная БД не обязательно совпадает с бизнесовой, во-вторых, можно же делать кучу всего нового от имени пользователя.
Вот только для этого надо узнать, что она утекла.
Да, надо. А Вы об этом не знаете и считаете, что незнание об этом OK? Ничего, что злоумышленник захватил контроль над сервером и, в общем-то, уже может вести несанкционированную активность от имени пользователя или уже её произвёл?
Не понимаю вопроса.
В нашем случае, либо пароль настолько плох, что может совпасть с чужим паролем и такие пароли архитектурно запрещены, либо он настолько сложный, что вряд ли взломщик добавит его в свою радужную таблицу.
Если подходить с этой точки зрения, то можно вообще ничего не хешировать и хранить в плейнтексте. Но так почему-то не делают. БД утекают регулярно, и будут утекать дальше.
Нет, надо сделать всё по максимуму, но не перегибая палку.
И почему бы просто не увеличить вычислительную сложность хеширования пароля (в адекватных пределах, конечно, но не обязательно, чтобы это происходило прям мгновенно)?
… Ведь Вы считаете, что заполнить радужную таблицу на стопицотмиллиардов паролей так просто. Если Вы реально хорошо обезопасили свою БД, то можно не увеличивать сложность генерации хеша. А если плохо, то надо увеличить сложность генерации хеша. А какие ещё есть варианты? -_- Вангую, что Вы предложите отказаться от данной схемы. Но вот в ходе срачика постепенно выяснилось, что БД-то к злоумышленнику утечёт. Почему в этой БД должен быть логин, скорее всего, одинаковый для всех сайтов?
(а) полностью убили обратную совместимость с клиентами
У клиента будет старая серверная соль в качестве 2-й соли, после того как он обновит страницу входа, однако можно доставить информацию о обновлении и через WebSocket или аналоги.
(б) если кто-то увел предыдущую БД, у него теперь есть готовые пароли прямо для входа.
Если под паролем Вы имели ввиду то, что пользователь отправляет на сервер, т.е. хеш от символьного пароля, то повторюсь — если кто-то увёл БД, Вы должны 1) узнать об этом, 2) принять меры.lair
30.10.2017 17:17А Вы об этом не знаете и считаете, что незнание об этом OK?
Это данность. Когда считаются возможные атаки, такой кейс надо учитывать.
В нашем случае, либо пароль настолько плох, что может совпасть с чужим паролем и такие пароли архитектурно запрещены, либо он настолько сложный, что вряд ли взломщик добавит его в свою радужную таблицу.
Нам не важно, насколько сложный пароль. Нам важно, что он дает нужный хеш. Поэтому вероятность попадания пароля в радужную таблицу (ну или, в общем случае, в таблицу хешей) не зависит от его сложности.
Нет, надо сделать всё по максимуму, но не перегибая палку.
Нынешнее "по максимуму" — индивидуальная соль на каждый пароль.
… Ведь Вы считаете, что заполнить радужную таблицу на стопицотмиллиардов паролей так просто.
Я считаю, что атаковать БД, в которой соли нет (или соль одна и та же), проще, чем ту, в которой для каждой строчки уникальная соль.
Если Вы реально хорошо обезопасили свою БД
Я точно знаю, что нет никакого "реально хорошо".
Почему в этой БД должен быть логин, скорее всего, одинаковый для всех сайтов?
Потому что утечка логина не представляет опасности (логин — это публично доступная информация и так).
У клиента будет старая серверная соль в качестве 2-й соли
Так для этого надо клиент обновить.
если кто-то увёл БД, Вы должны 1) узнать об этом, 2) принять меры.
Это не всегда возможно, поэтому нельзя на это закладываться. А если вы можете на это заложиться, то можно вообще ничего на сервере не шифровать.
Farxial2
30.10.2017 19:24Это данность. Когда считаются возможные атаки, такой кейс надо учитывать.
OK, если злоумышленник получит доступ к БД только на чтение, то Вы правы на счёт уникальной соли для каждого пользователя. А почему Вы не учитываете, что он сможет получить доступ к БД и на запись? Или, если у Вас установка пароля в отдельной функции, не сможет получить над ней контроль? Или Вы надеетесь, что кто-либо из пользователей заметит это и сообщит Вам? А что если нет?
Нам не важно, насколько сложный пароль. Нам важно, что он дает нужный хеш. Поэтому вероятность попадания пароля в радужную таблицу (ну или, в общем случае, в таблицу хешей) не зависит от его сложности.
Что злоумышленник будет делать с этим хешем?
Нынешнее «по максимуму» — индивидуальная соль на каждый пароль.
Из этого следует необходимость пользователя ввести свой логин или ID, а это уже перегибание палки. Точнее, перегибанием является запрет авторизации только по паролю на основании только того, что у Вас может утечь БД. Нет, такой вариант авторизации по-своему хорош, хотя и по-своему плох тоже. Вот только ничто не мешает Вам вместо запрета этого варианта обезопасить свою БД. А если Вы не можете обезопасить свою БД, это не значит, что вариант плох по сравнению с другим, который позволяет Вам недостаточно хорошо обезопасить свою БД без последствий. Да, можно говорить, что невозможно обезопасить свою БД на 100%, но если Вы её хоть как-то обезопасили, потом можно обезопасить ещё и так далее…
Небольшое отклонение от темыПонятно, что бесконечно заниматься этим невозможно, в т.ч. потому что после того, как она будет обезопашена на 100%, дальнейшие попытки обезопасить её будут нерациональны (а Вы не будете знать, что она уже полностью обезопашена). Но всё намного проще: надо просто с душой подходить к процессу и стараться не делать ошибок)lair
30.10.2017 21:11OK, если злоумышленник получит доступ к БД только на чтение, то Вы правы на счёт уникальной соли для каждого пользователя. А почему Вы не учитываете, что он сможет получить доступ к БД и на запись?
Потому что получить доступ на запись сложнее.
Что злоумышленник будет делать с этим хешем?
Возьмет то, из чего он (хэш) получился и пошлет в систему в качестве пароля.
Из этого следует необходимость пользователя ввести свой логин или ID, а это уже перегибание палки.
Для вас — да. Но не для остальных людей.
Точнее, перегибанием является запрет авторизации только по паролю на основании только того, что у Вас может утечь БД.
Не только этого. Есть и еще соображения.
Вот только ничто не мешает Вам вместо запрета этого варианта обезопасить свою БД.
Конечно же, мешает. Полная "безопасность БД" -это иллюзия.
Проще, но насколько? Взломщику всё равно придётся создать хеши для всех возможных паролей после того как он узнает соль на сервере. Сильно ли легче ему станет только от того, что на каждом пароле ему надо будет передать одну и ту же соль вместо разных для разных пользователей, но список которых у него всё равно есть?
В разы проще. Сравните два алгоритма:
(1) для каждой строчки в БД берем ее соль, дальше начинаем рассчитывать варианты хэшей с учетом этой соли, пока не подберем хэш, совпадающий с хэшом в строчке
(2) берем общую соль, начинаем рассчитывать варианты хэшей. Для каждого получившегося хэша проверяем, есть ли он в БД, если да — записываем в успешные, идем дальше.
Почему вообще, в этом случае, Вы не согласны с тем, что сложность надо увеличить?
Потому что увеличние сложности повышает уязвимость к DoS.
Она публично доступна только в случае, когда логин всегда равен никнейму
Это "очень часто". А когда логин равен емейлу — еще чаще. А когда целевая атака — всегда.
Ну, если Вы не хотите приложить всех требуемых усилий не только чтобы обезопасить БД от взлома, но и чтобы узнать об этом
Я не "не хочу", я "не могу".
А если Вам не подходят ни надёжные пароли, ни бо?льшая вычислительная сложность хеширования, ни защита БД от взлома, то я даже не знаю, чем могу Вам помочь(
Вы не хотите понять одного простого факта: для любого предложенного вами решения (надежные пароли, большая вычислительная сложность, защита БД), вариант с уникальной солью будет менее уязвим, чем вариант с общей солью.
Farxial2
30.10.2017 22:12Потому что получить доступ на запись сложнее.
Но возможно же.
Возьмет то, из чего он (хэш) получился и пошлет в систему в качестве пароля.
И всё же я не понимаю, как сложный пароль попал в радужную таблицу. Я сейчас взял свой пример из ветки выше
NintendoNintendoNintendoNintendoNintendoNintendoNintendoNintendoNintendo 777 111 555 444 666 йакреведко, креведко
получил от него множество хешей разных типов, включая популярные (в HashTab, сохранив строку в файл в UTF-8 без BOM) и строку, состоящую из соединённых пробелом хешей, скормил Гуглу — и Гугл ничего не нашёл.
Строка поискаB6C33C68 646B0FD2B2B49A563B56236FD54EE7724C080390943E5224FEC4F7B52F130F1B C32A98141EF1CCAA2255709EFC3A71932F9411E5 23965115 99675677F4CA56E1 F3FAF057E73774EF37C00270B4952963 F40342CBC8C0A709F05F229F87EB942BC20A4D824FB3265F5A392856F10D2117 DB287E2D96F227C7E20C41BFB6162F7755041004DCE08897544C73CE 7AEA7F5964CD637AA5C54C0BC1DBA91FE5CDC2B982997C7E7FE91FBDD32B6CD8 59E680C36B9AF637BBBC7E09AAA5A8FC0959C2B18A6780D0C478D777E271DD5DF117976C11859EF04F9C3F1C18CCEBA6 07F2D8E5B159C3E30A24E7DDDEA33649DFA7E5DEFD4F23D1DA59FA84882C163C4E02E5312D4AA814F893AACC8305F488E55C31E9A08D6A18A4C0A847EF943F3D 40D75A1BAE3DE0824AA2F89113B884B4 F3FAF057E73774EF37C00270B4952963 EE5AC95CD364FD7BA18326BB75853364 DDB24FA67222FC8135988B3AFB5B14B9 6000CD8682F90C37507ABFAC91CA4E32FA1D9E00 9E19405FB4EDEB2751EA86DCC0CFA1F1620D79BF4E1875B3BA850695E3516FFE 200B443963CDBAD4E003B6FB559A5FF11ACE7AD42E6EDEB05D764304365A7E0AB08C38A14E2835E4 FB3299D2AD9EE5E4F4A718BA53D9F27A54E0382C 73C179206B2D9B8154C1BDA08193E0AB527DDD9CE4256DC55316C6E9787253D7 c8F5IGstm4FUwb2ggZPgq1J93ZzkJW3FUxbG6XhyU9c= 161BD68C840086732DFEDF01A36F1836CF11AADD251071E002C28630748BF64B12B983BCB69E4202F7AFBF8E514C89B2 DCD086775F15C58B5E8710AF0A605B39B109E012B140905401A3053D0D5A46F3ABA24C2992A18ADF71737A1A0EB914DA7D12A2907668189183FBD875232A74CD D79F5E9FABB8219EA14704C2DBD39E039B31410B16478A89420B1731 795127A22CD831DC25F84FDD2EB3ACCDC3F87016C8295028BB25B829CB188F90 CC3E1EFEFEADE02F5A32850DA4FA7326B24A2E0D8765DE449746291D36E071CA3292F5E189A142E5FB4D9BBCE867302D D8DB42BCF4F01EA3C3F9995BCF501FEBFEE61DA1EFF1EBFA1270424C3E5045FD89628E2046294B3FD99A05044F51B2F52C4AC20134E803B2DD517410C17E64B3 C4JVMBMC55FILTDGUNMH3DKZCQQ4AAYBKJ3JAMY 626D71541FEE290FF360C45A5E1AC9941538498A62A26ADB E873A034DF5179DF311F55C37114B33A2BFF0AB03D1F7CA04C7B9A65CE2982B0FA88A56073F87D161073165086E20B2285EAFDD5470E50B3BD6E7805FF0B6885
lair
30.10.2017 22:19Но возможно же
Все возможно. Даже одновременное падение метеоритов на все дата-центры. Вопрос вероятности.
И всё же я не понимаю, как сложный пароль попал в радужную таблицу.
Да не пароль попал, а хеш от него. А какой пароль к этому хешу привел — не важно.
Какие?
Публичный идентификатор, например. Удобство построения БД.
можно просто исключить плохие звенья и достичь максимальной безопасности
Самое плохое звено в безопасности — человек. Вы не можете исключить операторов.
Но даже с общей солью создать хешей придётся всё равно много.
В m раз меньше, где m — число пользователей, атака от лица которых нам интересна.
Тогда остаётся только увеличивать сложность на клиенте, хотя это неэтично.
Это бесполезно, потому что для сервера пароль — то, что прислал клиент, не важно, сколько раундов было на клиенте.
Очень часто ? так и нужно.
Это, как говорилось выше, удобно.
Я не имел ввиду случаи, когда в качестве логина используется email
… а их много.
Откуда Вы знаете, что, если Вас взломали, то взломали потому что такова жизнь и законы ИБ, а не потому что Вы защитились всё же недостаточно хорошо?
Как раз наоборот: я знаю, что меня взломали потому, что я защитился недостаточно хорошо. И это и есть жизнь и законы ИБ. Вопрос в том, были ли у меня ресурсы на "достаточно хорошо"?
Farxial2
30.10.2017 23:09Все возможно. Даже одновременное падение метеоритов на все дата-центры. Вопрос вероятности.
А почему у Вас она именно такая, что взломщик не сделал ничего от имени пользователя, и главное не дать ему залогиниться под пользователем, не больше и не меньше?
Да не пароль попал, а хеш от него. А какой пароль к этому хешу привел — не важно.
Я, конечно, не особо разбираюсь в радужных таблицах, но думаю, буду прав, сказав, что из воздуха такой хеш появиться не может. Только случайно, но вероятность этого очень мала.
Публичный идентификатор, например. Удобство построения БД.
Публичный идентификатор не имеет и не должен иметь отношения к делам авторизации.
Удобство построения БД зависит от многих факторов, прежде всего — от самого подхода к построению БД и какой тип СУБД Вы выбрали. Не, можно сказать «вот эта хрень делает работу с БД неудобнее, поэтому она плохая». Но можно сказать и «вот эта хрень делает работу с БД неудобнее, но она нужна и поэтому надо просто оптимизировать работу с БД так, чтобы и эта хрень осталась, и работа с БД была удобнее». И выбор 1-го варианта сам по себе не означает, что «она плохая».
Самое плохое звено в безопасности — человек. Вы не можете исключить операторов.
Операторов чего?
В m раз меньше, где m — число пользователей, атака от лица которых нам интересна.
Нуок, допустим, у Вас в БД 16777216 (0x1000000) пользователей. Значит, чтобы усложнить работу взломщика, надо увеличить пароль на 3 байта. Это очень сложно (особенно с учётом того, что в рассматриваемой нами сейчас авторизации только по паролю сами пароли должны быть настолько большими, что +3 байта не будут делать погоды)?
Это бесполезно, потому что для сервера пароль — то, что прислал клиент, не важно, сколько раундов было на клиенте.
Зато взломщику придётся проделать больше раундов, чтобы заполнить свою радужную таблицу.
Это, как говорилось выше, удобно.
А мне удобно авторизоваться на сайте с помощью картинок, одноразовых паролей и запроса на мой домашний комп как на личный сервер авторизации (в зависимости от ситуации и настроения), но почему-то нигде этого нет.
… а их много.
Но я всё равно не имел ввиду их.
Как раз наоборот: я знаю, что меня взломали потому, что я защитился недостаточно хорошо. И это и есть жизнь и законы ИБ. Вопрос в том, были ли у меня ресурсы на «достаточно хорошо»?
А в чём проблема? Гугл, техническая документация, огромная общедоступная база опыта множества разработчиков… А у Вас в профиле даже указано «Архитектор», так что, возможно, тема безопасности Вам интересна, а по нашей с Вами дисскуссии/срачику можно сказать об этом уже с уверенностью.lair
30.10.2017 23:18А почему у Вас она именно такая, что взломщик не сделал ничего от имени пользователя, и главное не дать ему залогиниться под пользователем, не больше и не меньше?
Чтобы сделать что-то от имени пользователя, надо как раз залогиниться (ну, я сейчас не рассматриваю перехват сессии). Если не дать залогиниться — мы не дадим действовать (в рамках системы) от имени пользователя.
Я, конечно, не особо разбираюсь в радужных таблицах, но думаю, буду прав, сказав, что из воздуха такой хеш появиться не может. Только случайно, но вероятность этого очень мала.
Вероятность этого ровно такая, какая у любого другого хэша (исходя из того, что хэш криптографический, конечно). Вероятность совпадения — по парадоксу дней рождений.
Публичный идентификатор не имеет и не должен иметь отношения к делам авторизации.
Где записано, что "не должен"?
Операторов чего?
Системы, БД, бэкапов, ДЦ, далее продолжать.
Значит, чтобы усложнить работу взломщика, надо увеличить пароль на 3 байта.
С момента, как у вас пароль превысил 64 байта, любое последующее увеличение ничего не дает (я считал для 512-битового хэша). А это не так много символов.
Зато взломщику придётся проделать больше раундов, чтобы заполнить свою радужную таблицу.
Конечно, нет. Мы оперируем тем, и только тем, что получает сервер, нам все равно, что делает клиент.
А мне удобно авторизоваться на сайте с помощью картинок, одноразовых паролей и запроса на мой домашний комп как на личный сервер авторизации (в зависимости от ситуации и настроения), но почему-то нигде этого нет.
Потому что вы в меньшинстве.
А в чём проблема?
В недостатке ресурсов, очевидно.
Гугл, техническая документация, огромная общедоступная база опыта множества разработчиков…
Это все не ресурсы. Ресурсы — это, грубо говоря, деньги, время и люди. Ну еще железо (но оно вытекает из денег). Когда у вас на развертывание системы неделя, а денег на собственный ДЦ нет — возможности по обеспечению безопасности становятся резко ограниченными.
Farxial2
31.10.2017 00:32Чтобы сделать что-то от имени пользователя, надо как раз залогиниться (ну, я сейчас не рассматриваю перехват сессии). Если не дать залогиниться — мы не дадим действовать (в рамках системы) от имени пользователя.
Но это только когда взломщик получил доступ к БД на чтение, а доступа на запись получить не смог.
Вероятность этого ровно такая, какая у любого другого хэша (исходя из того, что хэш криптографический, конечно). Вероятность совпадения — по парадоксу дней рождений.
Кажется, до меня дошло…
Возьмет то, из чего он (хэш) получился и пошлет в систему в качестве пароля.
Вы имели ввиду случайные коллизии, когда H(pass)==H(something) и злоумышленник отправляет в систему something?
-_-Возьмет то, из чего он (хэш) получился и пошлет в систему в качестве пароля.
Я интерпретировал «то, из чего он (хэш) получился» как «пароль», потому что у нормальных людей он именно из пароля и получается, а из чего они получаются в радужных таблицах, я не знаю и даже не задумывался -_-lair
31.10.2017 00:41Но это только когда взломщик получил доступ к БД на чтение, а доступа на запись получить не смог.
Ну да. Это более вероятный кейс, чем получение доступа на запись.
Вы имели ввиду случайные коллизии, когда H(pass)==H(something) и злоумышленник отправляет в систему something?
Я имел в виду, что нам все равно из чего получился хэш до тех пор, пока он совпадает с хэшом в БД (если мы, конечно, охотимся на систему, а не на пароль).
Увеличить длину хеш-функции
За ресурсы вы не платите, да?
Хранить в БД ещё какой-нибудь короткий хеш/чексумму (можно взять маленький кусочек хеша нормальной хеш-функции) того, что должен передать пользователь
Двойной хэш? В два раза увеличили уязвимость к DoS.
Проверить то, что передал пользователь, на длину
А откуда вы знаете, какая она должна быть?
Кстати, я не очень понял, как злоумышленник передаст «что угодно», если сервер использует ещё, как минимум, соль.
Мы же с этой солью и считали.
Где записано, что «не должен»? — В Вашем комментарии, слове «Публичный».
Нет, из него это никак не вытекает.
Вас же не принуждают хранить в БД хеши современных популярных алгоритмов? Вы можете разработать свой.
Плохая идея. Если вы не специалист в криптографии, вы сделаете только хуже.
Это не обоснование.
Это как раз разумное обоснование, почему для вас никто не пишет систему входа — это невыгодно.
Ясно. Тогда остаётся лишь [....] надо просто с душой подходить к процессу и стараться не делать ошибок)
Этого недостаточно.
Вот только из этого следует, что БД может утечь.
Да, именно так.
И то, что под юзером кто-то залогинится, намного менее серьёзно, чем украдут приватные данные множества пользователей.
Нет. Потому что (а) приватные данные могут быть в другой системе и (б) имперсонация вообще может натворить ужасных дел.
Кто виноват?
Вы правильно ответили, все виноваты. Использование на каждом этапе продуманного и уже оцененного специалистами решения выгоднее, чем изобретение велосипедов (до тех пор, пока вы сам не специалист, конечно).
Farxial2
31.10.2017 02:32Ну да. Это более вероятный кейс, чем получение доступа на запись.Но ещё более вероятный кейс — что сайт не взломают (если Вы предприняли хоть какие-то меры безопасности, а если чуть больше, то ещё лучше). Почему Вы не используете его, а используете именно тот, в котором сайт взломали?
Я имел в виду, что нам все равно из чего получился хэш до тех пор, пока он совпадает с хэшом в БД (если мы, конечно, охотимся на систему, а не на пароль).
Ну, ясно -_-
За ресурсы вы не платите, да?
Эта плата несравнима с той, которую придётся заплатить взломщику, чтобы заиметь рабочую радужную таблицу больше.
Двойной хэш? В два раза увеличили уязвимость к DoS.
А как иначе Вы справитесь с атакой по радужной таблице? Ведь даже если пароль пользователя захеширован с его собственной солью, взломщик просто найдёт набор байт, который, после хеширования с той же солью, даст нужный хеш (если хешировать с одной и той же солью у всех пользователей, можно найти нужный набор байт, верно? не важно, что это быстрее — главное, что и то и то возможно, а нам надо это исключить, раз уж можем), и без доп. хеширования Вы не узнаете, что это не настоящий пароль, а какая-то фигня.
А откуда вы знаете, какая она должна быть?
Обычно хеш-функции дают результат фиксированной длины, PBKDF2 тоже (вроде бы). Вы можете:
A. Взять хеш-функцию с результатом фиксированной длины, если это ещё не так
B. Добавить ещё один слой, скормив результат 1-й функции какой-нибудь другой, дающей результат фиксированной длины
C. Не использовать этот вариант
Мы же с этой солью и считали.
Не очень понятно, кто «мы». Если имеется ввиду взломщик, то для начала ему надо будет найти радужную таблицу. Я предложил один вариант, но он Вам не подошёл(
Я предложил тот вариант на случай использования радужных таблиц, в какой-то мере идя Вам навстречу (потому что только слабым паролям есть место в радужной таблице). А если Вам не подходят ни надёжные пароли, ни бо?льшая вычислительная сложность хеширования, ни защита БД от взлома, то я даже не знаю, чем могу Вам помочь(
Нет, из него это никак не вытекает.
Серьёзно? Пароль является средством аутентификации, а логин не является? Почему же?
Плохая идея. Если вы не специалист в криптографии, вы сделаете только хуже.
Отличная идея, если Вы хотите на 100% обезопаситься от атаки радужными таблицами,даже если Вы не специалист криптографии. Наверное, надо им стать… только не говорите, что на это недостаточно ресурсов)) Либо Вы делаете это, либо имеете риск попасть под атаку с использованием радужной таблицы (а ведь Вы ещё и не хотите проверять, фигню взломщик передал или пароль).
Это как раз разумное обоснование, почему для вас никто не пишет систему входа — это невыгодно.
Значит соответствие ника и пароля используется часто потому что это выгодно (в том же смысле, в как в цитате выше). Это и есть Ваше «обоснование»?
Этого недостаточно.
Вы это проверяли? Например, пример из комментария выше
Системы, БД, бэкапов, ДЦ, далее продолжать.
Вы уже попробовали если не удалить все ненадёжные звенья на раз, то хотя бы сказать себе «никакое ненадёжное звено не должно использоваться в моей системе, потому что иначе мою систему взломают, а мне не нужно этого» или типа того?
Да, именно так.
Ну, это не есть нормально.
Нет. Потому что (а) приватные данные могут быть в другой системе и (б) имперсонация вообще может натворить ужасных дел.
A. Вас не должно касаться, есть они в другой системе или нет, Ваше дело — обеспечение безопасности своей системы, потому что пользователь доверил Вам свои данные.
B. Да, имперсонация + кража данных хуже одной только кражи данных. Но одна только кража данных хуже отсутствия кражи данных.
Вы правильно ответили, все виноваты. Использование на каждом этапе продуманного и уже оцененного специалистами решения выгоднее, чем изобретение велосипедов (до тех пор, пока вы сам не специалист, конечно).
Из этого следует, что, что бы ты не придумал, надо молчать и не показывать этого. Никому. И никуда этого не кидать. Что бы это ни было. Короче, свести хоть какие-то свои способности на нет. Ну спасибочки))
А на самом деле в некоторых случаях, типа этого, действительно не стоит писать о таких вещах. Но именно потому, что некоторые резко на это реагируют, потому что им подавай специалиста да оцененные ими решения, которые удобнее просто потому, что взлом БД это данность, потому что они подходят со всей душой (доверяя взаимодействие с БД ненадёжным людям, ага), просто ресурсов недостаточно, но загоняющие в такие рамки не заслуживают порицания за это (наоборот, ради них надо сэкономить на производительности, а не попросить ещё денег на чуть более мощный сервер), а то, что чья-то позиция, имеющая такое же право на существование, как и другие, не удовлетворяется потому что это невыгодно это OK и «обоснование»)) (Теперь попробуйте прочитать в обратном порядке ^^) А не потому что этот вариант плохой. Просто можно прожить и с логином+паролем, вариант с только паролем не настолько критичен, чтобы тратить свои нервы. А если предположить, что этот вариант понравится достаточному количеству людей, они его у себя реализуют и в т.ч. Вы (на самом деле мб и нет, но поскольку мы обсуждаем «любой взломанный сайт» как «Ваш сайт», мне сейчас так удобнее), и у Вас взломают сайт — это будет означать ровно то же самое: Вы недостаточно хорошо озаботились безопасностью своей БД. А ещё недостаточно хорошо озаботились сохранностью хешей (да, даже несмотря на то что пилите этим меня, ведь сами-то не хотите проверить, что клиент передал пароль, а не какую-то фигню). Но виноват у некоторых буду я, несмотря ни на что, потому что «специалисты» хорошие, тот кто платит деньги тоже (даже если даёт недостаточно для Вас ресурсов), те кому нужна простая и статичная ссылка на пользователя тоже… Нафиг.
Собственно, я признал свой слив уже почти сутки назад. Что Вы ко мне опять пристали? -_- яжниспициалист, зачем Вам мнение, позиция, аргументация и прочее от ниспициалиста?
(Хотя не буду отрицать, что этот срачик возымел и пользу лично для меня вот здесь, за что Вам спасибо :3)lair
31.10.2017 15:04Почему Вы не используете его, а используете именно тот, в котором сайт взломали?
Потому что если сайт не взломали, у нас нет атаки, и обсуждать нечего.
Эта плата несравнима с той, которую придётся заплатить взломщику, чтобы заиметь рабочую радужную таблицу больше.
Расчеты двух разных "плат" в студию.
А как иначе Вы справитесь с атакой по радужной таблице?
Добавление индивидуальной соли к каждому паролю делает бесполезным расчет радужных таблиц.
Ведь даже если пароль пользователя захеширован с его собственной солью, взломщик просто найдёт набор байт, который, после хеширования с той же солью, даст нужный хеш
Брутфорсом, ага. Дорого.
Обычно хеш-функции дают результат фиксированной длины
То есть вы предлагаете строго зафиксировать длину пароля? В этот момент вы радостно упростили работу взломщику, спасибо вам.
Не очень понятно, кто «мы». Если имеется ввиду взломщик, то для начала ему надо будет найти радужную таблицу.
Взломщик, взломщик. Возьмет и построит.
Серьёзно? Пароль является средством аутентификации, а логин не является? Почему же?
Во-первых, насколько я помню, логин является средством идентификации, а не аутентификации. Но не важно, потому что, во-вторых, не всякое средство аутентификации должно быть сокрытым.
Отличная идея, если Вы хотите на 100% обезопаситься от атаки радужными таблицами
Нет, самописная хэш-функция не дает стопроцентной защиты от атаки через радужные таблицы.
Наверное, надо им стать… только не говорите, что на это недостаточно ресурсов
Именно так. Это отдельное специальное образование — и оно мне, будем честными, неинтересно.
Либо Вы делаете это, либо имеете риск попасть под атаку с использованием радужной таблицы
Я всегда имею риск попасть под атаку с использованием радужной таблицы. Просто некоторые решения этот риск уменьшают — например, использование соли, лучше всего — индивидуальной.
Значит соответствие ника и пароля используется часто потому что это выгодно (в том же смысле, в как в цитате выше). Это и есть Ваше «обоснование»?
Ну да. Использование логина и пароля выгодно, потому что это устоявшаяся практика, решающая сразу много вопросов в архитектуре системы.
Вы это проверяли?
Да, я проверял. Благих намерений недостаточно для построения защищенной системы. Еще нужны знания, опыт и ресурсы.
Вы уже попробовали если не удалить все ненадёжные звенья на раз,
Нет, не пробовал, потому что для удаления всех ненадежных звеньев нужно слишком много денег. Кстати, хочу заметить, что вся самописная криптография как раз попадает под определение "ненадежное звено" и выпиливается первой.
Ну, это не есть нормально.
Это расчет модели угроз.
A. Вас не должно касаться, есть они в другой системе или нет, Ваше дело — обеспечение безопасности своей системы, потому что пользователь доверил Вам свои данные.
Вы не поняли, о чем я говорю. Если у меня в системе есть данные разной степени конфиденциальности/бизнес-импакта, я могу разнести их по разным подсистемам, таким образом, чтобы утечка одних (например, аутентификации) не приводила к утечке других (например, бизнес-данных). А еще, кстати, бизнес-данные можно просто насмерть зашифровать. Очень дорого, но можно.
Да, имперсонация + кража данных хуже одной только кражи данных. Но одна только кража данных хуже отсутствия кражи данных.
Спасибо, кэп.
Из этого следует, что, что бы ты не придумал, надо молчать и не показывать этого. Никому. И никуда этого не кидать. Что бы это ни было.
Нет, не следует.
Farxial2
31.10.2017 20:11Потому что если сайт не взломали, у нас нет атаки, и обсуждать нечего.
Так почему Вы предполагаете, что сайт взломали и у нас есть атака? Отсутствие атаки вероятнее, чем её наличие. А если рассматривать, какие могут быть атаки, то надо рассматривать и атаку на запись. Определитесь, ну.
Расчеты двух разных «плат» в студию.
Только после того как Вы объясните, откуда у взломщика пригодная для взлома радужная таблица ;)
Добавление индивидуальной соли к каждому паролю делает бесполезным расчет радужных таблиц.
Потому что пары pass+salt всегда разные? Так в случае с уникальным в пределах сайта паролем они тоже будут всегда разными.
Брутфорсом, ага. Дорого.
Почему здесь брутфорс, а в случае с одной солью на сайт нет?
То есть вы предлагаете строго зафиксировать длину пароля? В этот момент вы радостно упростили работу взломщику, спасибо вам.
Не понимаю Вашей логики. У вас взломщик шлёт какую-то фигню вместо пароля, которую сервер хеширует с солью (И да, на всякий случай напомню, что под H подразумевается не просто хеш-функция, а, например, PBKDF2 (а в написанном мною выражении «H(pass, salt)» переданы 2 аргумента, потому что запятая ? плюс). Хотя надо было сделать это раньше, да -_- Так вот, у Вас взломщик настолько крут, что находит коллизию не для какого-то алгоритма хеширования, а PBKDF2 со множеством итераций.) и получает хеш из БД. Оказывается, ему стало проще найти такую фигню с фиксированной длиной, к тому же неизвестной вплоть до взлома сайта, чем если бы он мог найти такую фигню с любой длиной?
Взломщик, взломщик. Возьмет и построит.
Тогда см. часть про периодическое нарастание соли, вплоть до конца той части обсуждения.
Во-первых, насколько я помню, логин является средством идентификации, а не аутентификации.
Давайте по существу, а не по формальностям. Чтобы пройти авторизацию, Вы должны не только назвать правильно свой пароль, но и назвать логин, Вы не можете просто дать правильный пароль и под чужим логином войти в свой профиль (как и в чужой, впрочем, если только у вас с другим пользователем не одинаковые пароли). Значит с практической точки зрения логин является средством аутентификации. Ровно как и пароль (при условии, что он уникальный) может быть средством идентификации. Вас это смущает, почему?
Но не важно, потому что, во-вторых, не всякое средство аутентификации должно быть сокрытым.
Обоснуйте. Вы же доказывали мне, что логин+пароль лучше только пароля, потому что, чтобы войти в аккаунт, мало угадать только пароль, надо угадать ещё и логин, и таким образом он является дополнительной мерой защиты.
Нет, самописная хэш-функция не дает стопроцентной защиты от атаки через радужные таблицы.
Суть в том, что для самописной хеш-функции взломщику придётся создавать с нуля радужную таблицу и он не сможет использовать уже готовую.
Именно так. Это отдельное специальное образование — и оно мне, будем честными, неинтересно.
Ну что ж, Ваш выбор.
Я всегда имею риск попасть под атаку с использованием радужной таблицы. Просто некоторые решения этот риск уменьшают — например, использование соли, лучше всего — индивидуальной.
А каким образом индивидуальная соль уменьшает этот риск в данном случае?
Ну да. Использование логина и пароля выгодно, потому что это устоявшаяся практика, решающая сразу много вопросов в архитектуре системы.
Но устоявшаяся практика тоже не синоним правильности.
Да, я проверял. Благих намерений недостаточно для построения защищенной системы. Еще нужны знания, опыт и ресурсы.
Судя по части далее, не проверяли.
Нет, не пробовал, потому что для удаления всех ненадежных звеньев нужно слишком много денег.
А может, слишком много денег нужно для решения Вашей конкретной задачи, вместо которой можно взять какую-нибудь другую, попроще?
Кстати, хочу заметить, что вся самописная криптография как раз попадает под определение «ненадежное звено» и выпиливается первой.
По такой логике никто никогда в принципе не должен самостоятельно создавать ничего криптографического. Прикольно, чо.
Но тогда пользуйтесь не самописной криптографией — наймите кого-нибудь, пусть он вам сделает алгоритм, или проверит Ваш и проч. Это будет не «самописная» криптография (наверное). А если у Вас нет денег, то, опять же, не знаю, чем помочь в данном вопросе. У меня тоже нет денег на разработку «не самописного» алгоритма хеширования, но именно потому я и предложил вариант, не требующий денег, людей и проч.
Это расчет модели угроз.
Позволить создать угрозу (или повысить её вероятность), а потом рассчитывать её модель. Прикольно, чо. [2]
Вы не поняли, о чем я говорю. Если у меня в системе есть данные разной степени конфиденциальности/бизнес-импакта, я могу разнести их по разным подсистемам, таким образом, чтобы утечка одних (например, аутентификации) не приводила к утечке других (например, бизнес-данных).
А почему Вы опираетесь на то, что взломщик украдёт БД с какими-то данными входа (особенно учитывая, что Вас не волнует, что взломщик сможет использовать пароль пользователя на другом сайте), чтобы лишь написать что-то от лица пользователя, вместо того чтобы украсть бизнес-данные?
А еще, кстати, бизнес-данные можно просто насмерть зашифровать.
Ключ расшифровки будет храниться у пользователя или у Вас в БД?
Очень дорого, но можно.
Но мне, если честно, не очень верится, что Вы будете на это готовы, с учётом того что не хотите проверить пароль на то, что он пароль, каким-нибудь простым хешем/чексуммой из-за «повышения уязвимости к DoS».
Спасибо, кэп.
Пожалуйста ^^
Нет, не следует.
На самом деле, это так не во всех случаях. А следует «из этого» во всех случаях… кроме случая, когда ты сам специалист. А вот этого я сразу не заметил -_- Однако выпрыгивать из штанов, зарабатывая репутацию специалиста с мировым именем, только для того чтобы поделиться с другими какой-то своей идеей, я считаю иррациональным.lair
31.10.2017 23:45Так почему Вы предполагаете, что сайт взломали и у нас есть атака?
Потому что это возможный случай, который надо рассматривать. Если его не рассматривать, то на очень много методов защиты (включая серверное хэширование паролей вообще) можно забить.
А если рассматривать, какие могут быть атаки, то надо рассматривать и атаку на запись.
А атака на запись нам просто не интересна, потому что от атаки на запись в хранилище аутентификационных данных защиты с помощью аутентификационных данных не существует (ну или я ее не знаю).
Каждый инструмент применяется на своем уровне.
Только после того как Вы объясните, откуда у взломщика пригодная для взлома радужная таблица
Самый простой ответ — посчитал.
Потому что пары 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 — число логинов). Поменяем местами, один логин и все пароли? То же самое. А ведь вам известны и логин, и пароль.
(и, что характерно, от обеих этих атак есть некоторые способы защиты)
Поэтому даже если логин открытый, вероятность подбора все равно не выше, чем при полном отсутствии логина (аутентификация только по паролю), но при этом сразу появляются дополнительные способы защиты.
Суть в том, что для самописной хеш-функции взломщику придётся создавать с нуля радужную таблицу и он не сможет использовать уже готовую.
Это не защита от атаки, это всего лишь понижение выгоды этой конкретной атаки.
А каким образом индивидуальная соль уменьшает этот риск в данном случае?
См. выше: при индивидуальной соли таблицу можно будет применить только к тому единственному хэшу, для соли которого эта таблица посчитана.
Но устоявшаяся практика тоже не синоним правильности.
Устоявшаяся практика — это (в данном случае) набор решений, для которых был проведен анализ безопасности, на который можно опираться при разработке своих решений.
Судя по части далее, не проверяли.
Вы сказали, "надо просто с душой подходить к процессу и стараться не делать ошибок". Я сказал, что этого недостаточно. Вы спросили "Вы это проверяли?". Я понял этот вопрос как "проверял ли я, достаточно ли просто подходить с душой к процессу и стараться не делать ошибок". Это я проверял.
А может, слишком много денег нужно для решения Вашей конкретной задачи, вместо которой можно взять какую-нибудь другую, попроще?
Но предыдущая-то задача останется нерешенной — что и будет примером того, что для решения определенных задач нужны ресурсы.
По такой логике никто никогда в принципе не должен самостоятельно создавать ничего криптографического.
Тоже нет (все это рассказывают на первом занятии курса по криптографии, кстати). Создавать-то можно, просто прежде чем использовать, надо пройти определенный процесс доказательства.
Но тогда пользуйтесь не самописной криптографией — наймите кого-нибудь, пусть он вам сделает алгоритм, или проверит Ваш и проч.
А зачем, если можно просто взять готовое коробочное решение?
я и предложил вариант, не требующий денег, людей и проч.
И не выдерживающий определенную категорию атак, да. Кстати, утверждение, что этот вариант не требует ни денег, ни людей, неверно.
Позволить создать угрозу (или повысить её вероятность), а потом рассчитывать её модель
А где я повысил вероятность какой-то угрозы?
А почему Вы опираетесь на то, что взломщик украдёт БД с какими-то данными входа [...], чтобы лишь написать что-то от лица пользователя, вместо того чтобы украсть бизнес-данные?
Я опираюсь на то, что кража первого не должна означать автоматической кражи второго и наоборот. Возможны оба сценария, оба надо рассматривать и оценивать — но от второго (кражи хранилища бизнес-данных) механизм аутентификации защитить не может.
Ключ расшифровки будет храниться у пользователя или у Вас в БД?
У пользователя, конечно — это его пароль (в паранояльном варианте — отдельный пароль).
Но мне, если честно, не очень верится, что Вы будете на это готовы
Зависит от требований. Я такого не делал, потому что таких требований по защите никто не выдвигал.
А следует «из этого» во всех случаях…
Снова нет.
Farxial2
30.10.2017 19:47OK, вот улучшенный вариант упомянутого компромисса, доведённый до бескомпромиссности (я надеюсь))
Кроме client_salt, клиенту передаётся index_salt (не равный client_salt).
На клиенте генерируется:
S = H(pass, client_salt)
K = H(S, client_salt)
I = H(S, index_salt)
На сервер отправляется K и I.
I адресует структуру данных {
ID пользователя
user_salt — серверная соль, уникальная для пользователя
H(K, user_salt)
}
Теперь сервер может получить адрес пользователя по I, но взломщик не сможет получить из него K.
Длина I может быть любой, но, чтобы можно было не бояться коллизий, она может быть и сопоставима с длиной K.lair
30.10.2017 21:23Сначала делаем такую же атаку на I, как раньше (т.е., перебираем все S, пока не найдем I в БД). Дальше, если
client_saltизвестна, мы получили K. А как вы сделаете, чтобы она была неизвестна, если она должна быть повторяема при каждом входе этого пользователя с любого устройства?Farxial2
30.10.2017 22:27А в случае, когда вместо K используется пароль, ситуация лучше? Вообще, какой алгоритм авторизации по паролю Вы считаете безопасным? Просто я-то видел их не так много, а мне для создания алгоритма, совместимого с сабжем обсуждения, нужно на что-то опираться)
А этот вариант решает не проблему брутфорса или использования радужной таблицы, он решает проблему поиска пользователя только по хешу пароля без возможности раскрытия самого пароля (и по совместительству — без возможности авторизоваться сразу с помощью K).lair
30.10.2017 22:32А в случае, когда вместо K используется пароль, ситуация лучше?
Нет.
Вообще, какой алгоритм авторизации по паролю Вы считаете безопасным?
Алгоритм аутентификации по паролю я знаю ровно один: сравните пароль с хранящейся информацией о нем, если совпали — пароль верный.
А этот вариант решает не проблему брутфорса или использования радужной таблицы, он решает проблему поиска пользователя только по хешу пароля без возможности раскрытия самого пароля
Вы не можете искать пользователя только по хешу пароля без снижения уровня защищенности. Если вам хочется не раскрывать пароль — то не раскрывайте его, используйте производную генерацию на клиенте. Только это к серверу отношения не имеет, для сервера паролем будет ваша производная.
А еще есть сертификаты...
Farxial2
30.10.2017 23:20Алгоритм аутентификации по паролю я знаю ровно один: сравните пароль с хранящейся информацией о нем, если совпали — пароль верный.
А что это за информация о нём и как сравнивается?
Вы не можете искать пользователя только по хешу пароля без снижения уровня защищенности. Если вам хочется не раскрывать пароль — то не раскрывайте его, используйте производную генерацию на клиенте. Только это к серверу отношения не имеет, для сервера паролем будет ваша производная.
Если Вы про то, что в логине+пароле больше информации, чем в только пароле, то это я уже обсуждал с Вами ещё вчера и как бы немножко закончил.
А еще есть сертификаты...
Да, есть… Но мы тут обсуждаем пароли же… Не то что бы мне очень хотелось сейчас обсуждать сертификаты, хотя я не имею ничего против ключей асинхронной криптографии, а ещё считаю, что много разных способов аутентификации это хорошо.lair
30.10.2017 23:28А что это за информация о нём и как сравнивается?
Сейчас принято хранить соленый хэш, сравнение должно быть неуязвимо к time-based attacks.
Если Вы про то, что в логине+пароле больше информации, чем в только пароле
Нет, я про соленые хэши.
Но мы тут обсуждаем пароли же…
Ну так вам же хочется пароли не раскрывать. Сертификаты для этого прекрасно подходят.
Farxial2
31.10.2017 00:59Ну, в этом варианте хеш тоже получается из того, что передал пользователь, с использованием уникальной соли. А I — аналог логина, просто помогает найти пользователя в БД.
Что не так с солёными хешами?
1. Сертификат это файл, который надо с собой таскать, не везде загрузишь (и что если устройство перехватит его, как пароль, и его потом придётся менять?), не так просто сменить, как пароль, и можно потерять из-за внешних факторов.
2. Если мне хочется не раскрывать пароли, это не значит, что какому-то другому пользователю будет удобно использовать не пароль.
3. Я не против использования сайтами паролей, т.к. это их право. Просто в таком случае сайт не должен иметь доступа к паролю, т.к. пароль используется пользователем только для доказательства своей аутентичности, однако нет гарантии, что сайт не будет использовать его никак иначе (и уж если мы подходим к безопасности серьёзно, то не надо давать сайту таких возможностей).lair
31.10.2017 01:04Ну, в этом варианте хеш тоже получается из того, что передал пользователь, с использованием уникальной соли. А I — аналог логина, просто помогает найти пользователя в БД.
Вот только этот "аналог логина" позволяет вычислить исходный ключ, полностью нивелируя вашу индивидуальную соль.
Что не так с солёными хешами?
С ними все так. Если их правильно готовить.
Сертификат [...] не так просто сменить, как пароль
Да точно так же.
Если мне хочется не раскрывать пароли, это не значит, что какому-то другому пользователю будет удобно использовать не пароль.
Я и не предлагаю всем сертификаты использовать.
Я не против использования сайтами паролей, т.к. это их право. Просто в таком случае сайт не должен иметь доступа к паролю
Одно противоречит другому. Если сайт использует пароль, то он имеет к нему доступ.
однако нет гарантии, что сайт не будет использовать его никак иначе (и уж если мы подходим к безопасности серьёзно, то не надо давать сайту таких возможностей).
… что решается созданием для сайта уникального пароля. Обиспользуйся. И да, ваше решение — это тоже создание для сайта уникального пароля, ничем не отличается.
Farxial2
31.10.2017 02:59Вот только этот «аналог логина» позволяет вычислить исходный ключ, полностью нивелируя вашу индивидуальную соль.
И всё же: откуда у взломщика радужная таблица с паролями, пригодными для использования в такой авторизации?
С ними все так. Если их правильно готовить.
Что не так в моём процессе их приготовления?
Да точно так же.
Если сертификат подписывается сайтом, то мб, почти так же. Но всё равно не совсем. Вам привычно наличие логина, а мне привычно отсутствие требования сохранять какой-то файл, а потом устанавливать его в браузер)
Я и не предлагаю всем сертификаты использовать.
А можно конкретную цитату, где я предлагаю всем авторизовываться только по паролю?)
Одно противоречит другому. Если сайт использует пароль, то он имеет к нему доступ.
Вот поэтому сервер сайта должен использовать не пароль. Правда, фронтенд сайта всё равно будет использовать пароль, но код фронтенда можно проверить.
… что решается созданием для сайта уникального пароля. Обиспользуйся.
И как их все помнить?
И да, ваше решение — это тоже создание для сайта уникального пароля, ничем не отличается.
Это создание уникального пароля для пользователя, а не для сайта.lair
31.10.2017 15:08И всё же: откуда у взломщика радужная таблица с паролями, пригодными для использования в такой авторизации?
Посчитал.
Что не так в моём процессе их приготовления?
Вы не используете уникальную соль для каждого пользователя.
Если сертификат подписывается сайтом, то мб, почти так же. Но всё равно не совсем. Вам привычно наличие логина, а мне привычно отсутствие требования сохранять какой-то файл, а потом устанавливать его в браузер
А не надо сохранять никакой файл, относитесь к сертификату, как к длинному паролю.
(на самом деле, правильнее было бы сказать не "сертификат", а "ключевая пара", а в качестве клиентского подтверждения использовать закрытый ключ)
Вот поэтому сервер сайта должен использовать не пароль. Правда, фронтенд сайта всё равно будет использовать пароль, но код фронтенда можно проверить.
В общем случае — нельзя, потому что современный фронтенд сайта с завидной регулярностью является API или мобильным клиентом.
И как их все помнить?
Специальные приложения.
Это создание уникального пароля для пользователя, а не для сайта.
Если у вас пароль уникален для пользователя, но не уникален между сайтами, то один сайт может использовать его на другом, тем самым нарушая вашу же задачу. Так что нет.
Farxial2
31.10.2017 20:20Посчитал.
Сколько времени это займёт и где он будет её хранить?
Вы не используете уникальную соль для каждого пользователя.
Если я буду использовать уникальную соль для каждого пользователя, то как его найду по одному только паролю?
И всё-таки этот вариант недостаточно хорош( Вот модификация лучше =)I на сервере тоже надо захешировать с серверной солью, уникальной для сервера. В противном случае, взломщик сможет создать радужную таблицу для I ещё до взлома, а тут ему придётся создавать её уже после взлома.lair
31.10.2017 23:53Сколько времени это займёт и где он будет её хранить?
В абсолютных величинах — без понятия.
Если я буду использовать уникальную соль для каждого пользователя, то как его найду по одному только паролю?
Никак. Я вам сразу сказал, что ваш вариант не позволяет так сделать, и это ведет к уязвимости.
И помнить всё его содержмое?
Это ничем не отличается от "помнить достаточно сильный пароль".
Лично я тоже считаю, что закрытый ключ у клиента лучше чем сертификат у клиента.
Фундаментальной разницы нет.
Однако как Вы будете искать пользователя в БД по одному только ключу?
Никак.
Или он всё же должен вводить логин?
Да, должен.
Если так, то зачем Вы предложили мне это вместо только паролей
Я вам это предложил не вместо "только паролей", а как решение задачи "не давать сайту доступа к паролю".
В тех случаях, где нельзя, конечно, пользователь не сможет безопасно использовать один и тот же пароль.
В нынешних реалиях это означает "всегда", потому что сайты без API чем дальше, тем менее конкурентноспособны. Но это, конечно, мое личное мнение. Но я систем без API не разрабатывал очень давно.
Тогда будет помнить компьютер, а не пользователь.
А я и не считаю, что пользователь может запомнить сильный пароль. Это ваше предположение было.
Но сайт не сможет использовать пароль, если будет знать только его хеш, но не сам пароль.
Я уже говорил: с точки зрения сайта, паролем является то, что ему отдали. Если хэш генерится для всех сайтов одинаково, значит, вы опять получили один пароль на все сайты. Если хэш генерится по-разному — вы как раз и сделали способ получения множества паролей из одного мастера.
А Вы, тем временем, не ответили на вопрос:
Я не вижу смысла на него отвечать, потому что я не утверждал, что вы такое предлагаете.
Farxial2
30.10.2017 08:41Я считаю
Только лишний раз убеждаюсь, что нельзя выражать своё мнение/позицию публично, если в этом нет необходимости. Ибо сам срачик — это ещё полбеды. Мда)
Ладно, я сливаюсь, мои оппоненты победили в этой беседе.
Но моя позиция от этого не меняется, конечно. Ибо, даже если проблема коллизий имеет место — недостаточно хорошим паролям, при которых эти коллизии могут возникнуть, нет оправдания. (Хотя иметь сложный пароль для каждого сайтика тоже тяжело, но этот вопрос я тут не рассматривал, это уже другая (ещё одна) часть общей проблемы.)
Критика ч.1, ч.2.2 и ч.3, конечно, приветствуется.
kolpeex
29.10.2017 12:48Чисто технически — таблица с токенами совершенно лишняя. Это дополнительная нагрузка на базу и дополнительные сложности по ее управлению (вроде периодической чистки). Достаточно, использовать что-то вроде jwt-токена
kolpeex
29.10.2017 12:58Он, конечно, упомянут в последнем шаге, но не как способ аутентификации, а ведь можно.
lair
29.10.2017 13:36Достаточно, использовать что-то вроде jwt-токена
… и куда вы его денете?
kolpeex
30.10.2017 11:48+1Вместо ссылки
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)
На сервере просто проверяется цифровая подпись и авторизуется по указанному в емейлу.lair
30.10.2017 11:49Знаете, в некоторых браузерах (и веб-серверах) все еще есть ограничения на длину URL.
lair
30.10.2017 11:59… а как вы будете обеспечивать однократное применение?
kolpeex
30.10.2017 12:05Тогда, конечно, без хранилища не обойтись. Но вообще это так себе фича (и к теме мало относится). Мне кажется, «срока годности» более чем достаточно.
lair
30.10.2017 12:08Но вообще это так себе фича (и к теме мало относится)
К посту она относится явно, потому что там есть "чтобы предотвратить множественное использование токена". Так себе или нет — вопрос открытый, потому что с ней — безопаснее, без нее — удобнее.
Livid
29.10.2017 13:18Если меня сайт на попытку входа будет отправлять в почту, в которую вообще не факт что быстро придёт письмо (или вообще придёт), и ненулевая вероятность что его придётся искать в спаме или в проводах, в которых оно застряло, я наверняка в какой-то момент захочу испить крови гения, который этот бред придумал. Пароли может и не самое удачное решение проблемы, и менеджеры может и костыли, но предложенное решение ещё хуже. Я уж молчу про безопасность, учитывая, что smtp у нас не самый защищённый протокол — более, чем в одном смысле.
Tallefer
29.10.2017 13:23Не «может», а костыли и есть, буквально. :) Для мозга, как не самого лучшего хранителя абстрактной инфы.
eoffsock
29.10.2017 13:59Не совсем в тему, но хочу спросить, никто не встречался с сервисами почты, которые предлагают алиасы к основной почте? Объясню, как я это вижу:
Сервис мне выдает какой-то email, и закрепляет его за мной. Подчеркиваю — не временный, пока я сам его не захочу сменить/вернуть.
Когда письмо приходит на этот алиас, оно перенаправляется мне в мой ящик через обычную отправку почты, в поле reply-to стоит специальный сгенерированный адрес.
Я отвечаю на письмо на адрес из reply-to. Письмо уходит на сервис на сгенерированный адрес, и сервис понимает, что это ответ на конкретное письмо, присланное на алиас, и от себя отправляет ответ, не засвечивая мой основной адрес.
Для адресата, который пишет мне на алиас, все выглядит так, будто алиас и есть мой почтовый ящик, и я с него отвечаю. Если я освобождаю алиас, перенаправление отключается, понятное дело. Тут еще есть момент, что новый пользователь может получить письмо, предназначавшееся мне, но сервис не предназначен для серьезной переписки, так что я не считаю это серьезной проблемой.
У меня была идея такого сервиса, и я не нашел похожих. Может кто сталкивался?Tallefer
29.10.2017 14:11Гмыло? :)
eoffsock
29.10.2017 14:14Насколько я знаю, там одной кнопкой так не сделать — надо будет руками делать алиас, делать перенаправление, потом еще ответ на письмо будет с моего основного адреса, насколько я понимаю. Для разового использования можно заморочиться, но хотелось бы автоматизировать.
К тому же такая штука вроде только для корпоративной почты там, для личной не нашел. Для личной по сути придется зарегистрировать отдельный адрес и потом его привязывать.
Integior
30.10.2017 13:38Fastmail. У него алиасы именно так и работают. У меня заведено несколько алиасов, которыми пользуюсь постоянно, основной же адрес нигде не светится (кроме почтовых клиентов).
Bonio
29.10.2017 14:32Сам по себе феномен менеджеров паролей, это уже костыль, который должен нам был показать всю не востребованность и неэффективность повсеместного использования паролей.
Категорически не согласен. Есть множество ресурсов, для которых я храню пароли в медеджере паролей, при этом светить в них свой основной email я не хочу, а зарегистрированы такие аккаунты зачастую на одноразовую почту.
Ведь чтобы авторизовать пользователя, вам достаточно выслать ему на почту письмо со сгенерированной ссылкой, как при подтверждении аккаунта.
Лишние телодвижения с открытием почты, ожидания доставки сообщения. Зависимость от работоспособности почтовых серверов.
В качестве защиты от спама письмами, можно сделать рейт лимит, или не высылать письмо чаще чем раз в 10 минут.
И получить невозможность авторизации в течение 10 минут на другом устройстве или после закрытия браузера/выхода из аккаунта.
Как альтернативный способ авторизации, этот способ имеет место быть, на равне с OAuth, но ни в коем случае не как замена логину/паролю.
vlad1s
29.10.2017 14:50Это всё конечно хорошо, однако давайте откроем NIST 800-63-3, выпущен в июне 2017: «Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.»
Не безопасно, собственно
werevolff
29.10.2017 15:59-1И только старик-Google продолжал спрашивать пароль, после чего слал проверочный код через SMS и запоминал устройство, с которого был произведён вход…
otvorot2008
29.10.2017 16:04Навскидку видится больше минусов, чем плюсов. Т.е настолько нестандартно, что использовать можно (на свой страх и риск) на ресурсах агрегаторах новостей например,
где важна возможность полистать ленту, посрать в комментариях, т.е нет данных кредиток и прочей компрометирующей информации.
Плюсы:
- "Удобство" аутентификации. Нет пароля, пожалуй единственная фишка подхода. Жизнеспособно для ресурсов, не компрометирующих данные пользователя
Минусы:
- Неудобно эргономически, слишком много действий на вход
- Неудобно для клиента почтового сервиса, да и для самого сервиса в частности. Замусоривается пространство почтового ящика, при этом для почтового сервиса такие аутентификационнные письма создадут дополнительную нагрузку по траффику
- Уязвимость к атакам session fixation. Здесь стоит вопрос доверия к самой ссылке. Можно банально попастся на письмо аналогичного содержания от хакеров, только с немного другим токеном. Вариантов — масса.
Можно просто подарить ID сессии злоумышенникам, либо зайти 'нетуда' и слить еще и данные других доменов через клиентский XSS. - Учитывая то, что пользователь будет уходить по такой ссылке, например, с gmail.com, это наверняка будет отслежено гуглом — банальный запрос на тот же домен почтового сервиса с последующей отдачей ответа 301. Здесь всплывает опасность MiTM.
Goury
29.10.2017 17:15+1Мало того, что это очень мутный и крайне сомнительный метод, так он ещё и игнорирует огромную часть причин, по которым не следует передавать в GET запросе те данные, которые предназначены для POST.
Нельзя просто так влезать со своими интересными предложениями в область информационной безопасности. Правила безопасности вообще и информационной в том числе — написаны кровью. Почему нельзя передавать авторизационную информацию в GET запросе — не затруднит найти в интернете (причин очень много, в камент все не влезут).
В крайнем случае — присылать одноразовый код из 4-8 символов с требованием ввести его руками в форму авторизации.
TimsTims
30.10.2017 14:09+1А также первое правило ИБ: защиту усиливаем там, где сложность взлома сервера не сопоставима с затраченными ресурсами. Никто не будет брутфорсить пароли на мощностях АНБ от никому ненужного бложика васи пупкина. А значит для «еще-одного-сайта-в-интернете» такой метод авторизации возможен(но не утверждаю, что он удобен).
Goury
30.10.2017 14:30-1Это правило АНБ и ФСБ довольно успешно навязывают дилетантам.
Уж сколько раз твердили миру, что Optimism Bias опасен и для индивида с расстройством и для окружающих его и для всего общества в целом, но только все не впрок.
И в сердце АНБ/ФСБ/КГБ/ЛГБТ (подчеркнуть нужное) всегда отыщет уголок.
Диленанту где-то бог послал кусочек безопасности;
На хостинг дилетант взгромоздился.
Обезопасить себя было совсем уж собрался.
Да подзадумался, а безопасность на *** вертел.
На ту беду, АНБ/ФСБ/КГБ/ЛГБТ (подчеркнуть нужное) близёхонько бежало.
Ну я думаю Крылова тут все читали, дальше лень перефразировать.
Мораль: важность информационной безопасности не зависит от масштаба ситуации.
TimsTims
30.10.2017 14:38Мораль: важность информационной безопасности не зависит от масштаба ситуации.
Очень даже зависит. Я не буду рекоммендовать ставить промышленные решения по ИБ-защите маленьким компаниям, в которой кроме 1с и почты ничего не используется. Также, как и стандарт безопасности PCI DSS нужен редким компаниям, а не всем подряд.
astono0
29.10.2017 17:36Идея отличная и хотелось бы видеть ее на большем количестве ресурсов
На сайтах, где есть возможность получать одноразовые пароли либо логиниться в том числе через получаемые эмейлы — только так и захожу.
LDZ
29.10.2017 17:55-1Сходу вижу такой кейс:
На смартфоне пользуюсь хромом. Пытаюсь войти на сайт, где используется эта технология. Он высылает письмо с ссылкой для входа на почту. Открываю почтовик, тыкаю на ссылку, открывается штатный сафари, где происходит авторизация. Но мне нужно в сафари, мне нужно в хроме. Иду снова в почтовик, копирую ссылку, иду в хром, вставляю, перехожу, а мне сообщается, что эта ссылка уже не работает. Иду снова на сайт, пытаюсь войти, он мне пишет, что задержка 10 минут между отправкой ссылки на вход и мне нужно подождать ещё 8 минут. Я шлю автора этой йебатении куда подальше и навсегда забываю про этот глючный сайт, куда без геморроя невозможно даже войтиlair
29.10.2017 19:01Кстати, совершенно реальный кейс (как раз Слак одно время так себя вел, чтоб ему пусто было).
TimsTims
30.10.2017 14:10«ваше мнение очень важно (на самом деле нет) для нас, мы работаем над удобством сервиса(не работаем)»
Loki3000
31.10.2017 16:47На самом деле еще веселее: вам надо авторизоваться сидя за чужим компом, а ссылка вам приходит на мобильний почтовый клиент. А пароль от почты длинный и сложный — записан там же в мобильной ключнице. Да и вообще его вводить на чужом непонятном компьютере — так себе идея.
lxsmkv
29.10.2017 19:17разве не получается. что при таком подходе ответственность за защиту пользовательских данных переходит с сервиса на емеил провайдера. И в конце концов ложится опять на плечи пользователя, который должен обезопасить доступ к своей почте, причем еще сильнее. Я например потерял доступ к своей яндекс почте, процесс восстановления аккаунта на Яндексе такой дикий, (с авторизацией по веб камере с паспортными данными) что я плюнул на это. И что делать? Все, досвидания все сервисы завязанные на эту почту. Это не решение или во всяком случае всего лишь полумера.
SuperPaintman Автор
29.10.2017 19:27+1разве не получается. что при таком подходе ответственность за защиту пользовательских данных переходит с сервиса на емеил провайдера
maxlazar
29.10.2017 19:17+1да, идея на самом деле очень актуальная, в особенности c распространения мобильных устройств. Мы буквально неделю назад подобную опцию сделали для одного из наших проектов. Наблюдаем сейчас как будет востребованно
SuperPaintman Автор
29.10.2017 19:24Оу, это круто! Дайте мне пожалуйста знать как у вас идут дела, через месяц в личку. Мы может сможем сделать с вами вторую часть, опишем проблемы с которыми вы столкнулись в "реальной жизни".
Tallefer
29.10.2017 19:31Только желательно еще и задокументировать, КАК это было сделано, UX и вот это все.
muxa_ru
29.10.2017 21:06Некоторое время назад я подумывал сделать себе подобную систему для админки сайта.
Только в варианте присылания ссылок в жаббер.
А потом гугл стал мутить с жаберо-гтолко-хэнгаутом и я забил на это дело.
При всех плюсах обсуждаемого подхода, у него есть огромный минус — если он станет популярным, то его начнут пихать везде.
А при всех недостатках парольной системы, при повсеместном использовании она лучше чем присылка временной ссылки для логина.
Tallefer
29.10.2017 21:12Наработок по жабиру не осталось? На гитхаб бы…
muxa_ru
29.10.2017 21:26Это и наработками то назвать нельзя. Там была какая-то xmpp библиотечка с помощью которой я поигрался.
Это оказалось очень простым и выглядело перспективным в качестве универсального решения.
А потом ВК от него отказался, гугл стал мутить и я это дело бросил.
Хотя, из phpbb-шного форума уведомления мне в гугл-чат приходят.
Но есть проблема с доходимостью в оффлайн на клиента-бастардах и приоритетом между клиентами.
Tallefer
29.10.2017 21:52О, почти то, что надо. :) Это плагин для форума или форум сначала шлет куда-то еще и там уже жабир сервис? Всегда мечтал подписаться на что-то и в жабир получать напрямую.
muxa_ru
29.10.2017 22:15это стандартная опция phpbb по уведомлению.
дублирует e-mail уведомления.
полагаю, выковырять её оттуда не составит труда.
Tallefer
29.10.2017 22:22Нифигасебе, никогда не видел, чтоб ее хоть кто-то где-то предоставлял. :)
muxa_ru
29.10.2017 22:50ну, мне этот форум был интересен, его владелец тогда купил смебе смартфон с андроидом и я предложил сделать.
завёл гуглопользователя, вручную подтвердил что хочу переписываться и вписал настройки в форум.
muxa_ru
29.10.2017 22:51Но это интересный вопрос.
Возможно я что нибудь скачивал и ставил дополнительно.
Вот тут обсуждение чего-то подобного — https://www.phpbb.com/community/viewtopic.php?f=46&t=488306 .
user-vova
29.10.2017 21:14РЕГИСТРАЦИЯ
1) Почта:
2) Вам на почту отправлен одноразовый пароль.
Пароль:
3) Ура! Вы зарегистрированы!
Вы можете задать постоянный пароль: (опционально)
АВТОРИЗАЦИЯ
Почта:
Пароль: (постоянный/одноразовый)
[выслать одноразовый пароль на почту]
ПИСЬМО НА ПОЧТЕ
бла бла бла
Ваш одноразовый пароль: F7ae2G8su
Вы можете задать постоянный пароль по [ссылке].
ozonar
30.10.2017 10:53Отвратительный способ регистрации. Чтобы получить то состояние, которое я получаю при регистрации на других сайтах по умолчанию, тут я должен:
1. Ввести свой емэйл на сайте
2. Зайти на почту
3. Перейти по ссылке из письма на сайт.
4. Зайти обратно на почту
5. Скопировать пароль
6. Перейти обратно, авторизоваться
7. Найти в многообразии сайта настройки и смену пароля
8. Зайти в почту
9. Скопировать пароль
10. Вставить пароль и ввести новый
11. Зайти в почту
12. Подтвердить смену пароля
Обычно я просто ухожу с сайта и больше им не пользуюсь когда вижу такой способ регистрации.user-vova
30.10.2017 14:16+1- Указать почту
- Зайти на почту и скопировать пароль
- Вставить пароль на сайте
Всё. Зарегистрирован и авторизован.
На этой же странице пользователю предоставляется возможность указать постоянный пароль. Появляется соответствующее поле, которое не обязательно заполнять. Не хочешь придумывать пароль и помнить его — пароль одноразовый на почту. Не хочешь светить свою настоящую почту или каждый раз на неё заходить — указываешь постоянный. Повторюсь там же с формой регистрации! Какие ссылки, какой поиск настроек, какая смена паролей, какое подтверждения? Эээ! Вы о чём? Фантазия такое дело...
unanimity
29.10.2017 21:38Без паролей же база становится в разы менее лакомой добычей.
1. Поясните, пожалуйста, почему Вы так считаете?
На мой взгляд это справедливо лишь для случая, когда пароли от почты совпадают с паролями от сайта. И злоумышленник сможет получить доступ к какому-то количеству почтовых ящиков.
В таком случае надо просто предупреждать пользователей при регистрации чтобы они не вводили тот же самый пароль, что и от своей почты.
token не обязан быть uuid'ом, вы можете сделать и более короткие токены, которые можно даже ввести вручную. Но в этом случае вероятность коллизии и его надежность могут значительно ухудшиться.
2. Правильно я понимаю, что token Вы храните в открытом виде?
Если так, то получив базу можно сразу (!), не тратя время на брутфорс солёного хеша, представляться любым пользователем данного сайта. Например, с целью методами соц.инженерии что-то выведать (все связи пользователей и активности между ними доступны из той же в базы).
3. Почему авторизация делается по e-mail, а не по нику?
Если предположить что Ваш метод станет массовым (и при этом подбор токена за обозримое время будет невозможен), то основным ветктором атаки будет атака на e-mail (пиьсма с вирусами, фишинг и т.п.). В этом случае e-mail лучше лишний раз нигде не афишировать.
4. Чем Ваш подход принципиально отличается от обычного с использованием пароля?
Под обычным я понимаю подход когда:
1) пользователь вводит ник и пароль на сайте
2) также указывает почту, на которую приходит ссылка с подтверждением, но не сам пароль
3) теоретически можно добавить флаг прислать пароль в открытом виде на почту
Преимущества:
- Про использование ника описано выше.
- Отсутствие пароля на почте поможет, на случай, если почта будет скомпрометирована: когда пароль будет сброшен — пользователь зайти на сайт не сможет и поймёт что почта скомпрометирована.
- Если нужно зайти на сайт на чужой машине — вводится ник и пароль. Затем в ближайшее время с надёжного компа сбрасывается пароль (не афишируя на чужой машине ни почты, ни пароля от неё).
Ваш подход:
1) ник недоступен
2) ссылка подтверждения выполняет и функцию пароля (переданного в открытом виде), фактически совмещая 2) и 3)
А продвинутые пользователи будут вынуждены придумывать специальный пароль для вашего сайта или пользоваться менеджером паролей.
Кстати, при использовании Вашего подхода никто не мешает пользователю сохранить ссылку с токеном в менеджер паролей.muxa_ru
29.10.2017 22:17На мой взгляд это справедливо лишь для случая, когда пароли от почты совпадают с паролями от сайта.
Гарантии нет, но какая-то часть пользователей будет использовать один и тот же пароль в нескольких местах.
PROFIT!!!!!11
muxa_ru
29.10.2017 22:20+1На мой взгляд это справедливо лишь для случая, когда пароли от почты совпадают с паролями от сайта.
Есть ещё один момент.
Если у Вас уводят базу с паролями, то у Вас увели всю базу с паролями и скомпрометированы сразу ВСЕ эккаунты.
Надо суетиться, менять пароли, блочить эккаунты и т.п.
Если у Вас увели базу с емейлами — скомпрометировано НОЛЬ эккаунтов.
sumanai
30.10.2017 02:06Если у Вас уводят базу с паролями, то у Вас увели всю базу с паролями и скомпрометированы сразу ВСЕ эккаунты.
Поэтому пароли везде хранят в хешированном виде, а современные алгоритм позволяют не беспокоится о подборе пароля по хешу ближайшие лет 15.muxa_ru
30.10.2017 03:28Поэтому пароли везде хранят в хешированном виде
"везде" — unacceptable generalization
sumanai
30.10.2017 16:081% убогих сайтов не в счёт.
muxa_ru
30.10.2017 16:301% убогих сайтов не в счёт.
Никогда не знаешь какой сайт окажется в списке "убогих" — https://www.kommersant.ru/doc/3082294 .
mxms
29.10.2017 21:48Вы просто заменяете пароль от вашего сервиса на пароль от электронной почты облегчая задачу аутентификации и сопутствующих механизмов обеспечения безопасности при усложнении для пользователей доступа. Сомнительное приобретение для них.
lierchan
29.10.2017 21:59Не самое лучшее решение, так как на почтовые сервисы увеличится ответственность.
wirtwelt
30.10.2017 00:19+2Человек просто предложил авторизацию по токенам… 100500 коментов, обсуждений, споров.
Дружище, я с тобой ) Инвайт-ссылки на вход и никакого восстановления пароля ) Делаю, работает, нравится клиентам.
WeltRogg
30.10.2017 00:21+1Вот уж чего, а пароли меня устраивают. А менеджеры паролей костылем вообще неверно называть, это мода такая что ли все костылями звать. Между прочит костыли только помогают людям, если руководствоваться точной терминологией!
igontarev
30.10.2017 00:271) авторизация через соц. сеть это вообще круто, тебе не надо помнить регался ты или нет, просто кликаешь войти через ВК и все
2) естественно для банкинга это ни в коем случае нельзя делать
P.S. классно сделано на digitalocean, вход с помощью authenticator
sumanai
30.10.2017 02:09авторизация через соц. сеть это вообще круто, тебе не надо помнить регался ты или нет, просто кликаешь войти через ВК и все
Или фейсбук, или гугл+, или гитхаб… А ВК в списке может не оказаться вообще. И сиди вспоминай, через какую соцсеть регался, или имей дубли аккаунтов.
iproger
30.10.2017 00:37Всегда нужно давать выбор. Хочешь использовать пароль? Пожалуйста. Хочешь соц, сети? Используй. И так далее.
Лично я вижу будущее в связке компьютер + телефон. Для входа нужно будет ввести email и нажать кнопку входа. После этого приходит подтверждение на айфоне в котором после снятия отпечатка или уже (face I’d) нужно только дать согласие на вход путём нажатия на кнопку, без всяких вводов чего-либо.
Пример есть: приложение battle net auth.
point212
30.10.2017 00:38Посыл про «пароль не нужен» поддерживаю.
Но решение, предложенное в статье — бредовое. Автор просто предлагает переложить заботу о хранении пароля на чужие плечи. Частный случай OAuth. И опять же, у нас получается один мастер-пароль от всего.
Я думал будет показано какое-нибудь решение, вроде авторизации через специальную прогу-агент, храняющуюся на компе пользователя. Хотя как по мне — так всё это слишком кардинально. И от чего действительно надо избавить человека — так это от запоминания пароля. Хорошие варианты — это жесты на фотках. Составление из некоторых объектов пространственной фигуры и так далее.SuperPaintman Автор
30.10.2017 00:51Автор просто предлагает переложить заботу о хранении пароля на чужие плечи.
Так она и не слезала с их плеч. Т.е. если у вас есть сброс пароля — у вас и не было никогда пароля.
Multi kill
Хорошие варианты — это жесты на фотках. Составление из некоторых объектов пространственной фигуры и так далее.
Так и вижу, как я бегаю по комнате ищя кубики, чтобы авторизоваться на хабре :).
KirEv
30.10.2017 01:42Самое удобное, как по мне, это разовые пароли которые отправляются на моб.номер.
смс стоит несколько копеек, но если для ресурса важно предотвратить доступ к аккаунту третьим лицам — могут себе позволить.
процесс авторизации одноразовым паролем выглядит так:
вводишь моб.номер на сайте, рядом телефон, тебе приходит смс и скорее всего сразу увидишь необходимый код и введешь в поле под номером телефона, даже смартфон в руки брать не придется… вполне удобно…
… почта избавит пароля, но добавит для конечного пользователя возню с почтой, кликами… а если письмо попадет в спам и т.п. и т.д… бывает письма не доходят… не пришло письмо — не зашел в личный кабинет… с смс тоже проблемы бывают, но всеже ради удобства конечного пользователя, разве не так?SuperPaintman Автор
30.10.2017 02:41Использовать телефон (СМС) гораздо доже и менее безопасно, чем почту.
А если предположить, что номер телефона может утечь, то начнется спам. А вот спам на телефон в разы более мерзкий, чем на email. Если у email сервисов уже отлажены методы борьбы со спамом, то вот у телефонов все плачевно, будете получать звонки от "пирамид" с разных номеров.
vital777
30.10.2017 09:15Тут многое уже сказали про безопасность и ответственность, а вот мне кажется что главное тут совсем в друго — это дополнительная точка отказа.
Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/… Добавьте еще риски того что:
Temirlan
30.10.2017 09:15Меня беспокоит перехват почтового сообщения.
Как можно ответственность за это переложить на почтовый сервис?
SMTP — открытый протокол. Как только почта поступила на сервера сервиса, только после этого можно говорить об ответственности.
Почта должна еще дойти до них через свободную, открытую связь.
ozonar
30.10.2017 11:06Вход по openAuth стал популярен потому что он проще, чем пара логин\пароль, по факту необходимо нажать на кнопку с иконкой Фейсбука (или другого провайдера), и всё. Способ с логином\паролем теперь прост на столько же — нужно подождать пока хранилище паролей браузера заполнит поля логина и пароля и нажать на «войти».
В способе из поста мне в любом случае придётся заходить в почту, искать письмо, и переходить по ссылке, испытывая кучу сложностей по пути (Открытие 3 вкладок, потеря контекста сайта перед решением авторизоваться, возможный ввод пароля на почте, да ещё и с получением смс при двухфакторной авторизации, например).
Какой в этом смысл? Сэкономить 5 секунд при регистрации? У опытных пользователей стандартная регистрация не составляет сложностей, скорее что-то нестандартное замедлит время на регистрацию, а у новичков даже вход в почту может вызвать сложности, что уж тут про новый для них способ регистрации.
vital777
30.10.2017 12:27Тут многое уже сказали про безопасность и ответственность, а вот мне кажется что главное тут совсем в другом — это дополнительная точка отказа.
Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/… Добавьте еще риски того что:
— сервис закроется
— сервис закроют для страны (привет роскомнадзор)
— сервис закроют для пользователя (причин может быть масса)
— сервис изменится так, что его нельзя будет использовать для ваших целей
— итд
в совокупности вы получаете весьма нехилый риск с которым всеже вполне можно смириться в некритичных частях системы, однако авторизацию к таковым отнести не получится. И тут уж надо сделать так чтобы работало железобетонно, а если сломалось — то можно было починить, а не зависеть от того, что кто-то когда-то возможно исправит.
Практически все, если не все, проекты использующие oauth крупных сервисов для авторизации дублируют его возможностью классической авторизации, и это не просто от того, что могут — поверьте.SuperPaintman Автор
30.10.2017 12:50Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/
А что вам в предложенной схеме мешает использовать свой почтовый сервер, если вы не доверяете гуглу?
в совокупности вы получаете весьма нехилый риск с которым всеже вполне можно смириться в некритичных частях системы, однако авторизацию к таковым отнести не получится. И тут уж надо сделать так чтобы работало железобетонно, а если сломалось — то можно было починить, а не зависеть от того, что кто-то когда-то возможно исправит.
К сожалению, я склонен больше верить в то, что у сайта с "котиками" будет все плохо, нежели у Yandex / Google / Mail.
Практически все, если не все, проекты использующие oauth крупных сервисов для авторизации дублируют его возможностью классической авторизации, и это не просто от того, что могут — поверьте.
А почему в предложено выше варианте они не могут сосуществовать? Вы можете позволить пользователю самостоятельно сделать выбор чем он хочет пользоваться: Oauth / Email + Pass / Email.
Если же вы боитесь, что почту могут своровать, и тогда пользователь потеряет доступ и к вашему сервису, так и с паролем (на вашей стороне) не многое поменяется (как минимум — ресет пароля на почту).
Alex_Yanover
30.10.2017 12:51А как вам такая идея — пользователь при регистрации загружает n-ое кол-во картинок, которые как-то связаны с ним. Например, фото с ним, его семьёй, друзьями, фото его машины и прочее. А при авторизации ему выдаётся набор изображений среди которых он должен указать свои. Т.е. пользователь вводит свой email или номер телефона. По нему система находит его изображения и выдаёт несколько его изображений из числа загруженных и несколько не его и пользователь указывает свои. В этом случае вообще не нужен пароль.
lair
30.10.2017 13:42В этом случае "паролем" просто является картинка. Такое уже есть, даже в банальном Windows Hello.
Farxial2
30.10.2017 14:11В данном случае надёжность будет всего несколько бит, так что реализацию стоит сделать более сложной. (И ещё в Вашем варианте надо сделать защиту от троллей, а то вдруг кто-нибудь загрузит какую-нибудь бяку, которая потом выведется другим.)
Однако с самим принципом полностью согласен (сам придёрживаюсь мнения, что картинки можно использовать для аутентификации), т.к. это удобно. А ещё — если разработчикам не удаётся добиться от пользователей большого уровня энтропии в текстовой форме (хорошего пароля), можно добиваться этого в любой другой форме.Alex_Yanover
30.10.2017 14:23Предполагал, что клиент, например, загрузит 6 картинок. А при авторизации выводится от 1 до 3 его картинок и ещё сколько не хватает до 6 других картинок. Остальные картинки — это не картинки других пользователей, а предустановленные в системе. Чтобы, как вы говорите, не было всякой бяки.
lair
30.10.2017 14:29Остальные картинки — это не картинки других пользователей, а предустановленные в системе.
Тогда для атаки достаточно просто исключить все предустановленные картинки, и оставшиеся и будут искомым паролем.
Alex_Yanover
30.10.2017 15:11а как их все исключить если теоретически их бесконечное число (можно например их брать из какого-нить онлайн сервиса)
lair
30.10.2017 15:33Это не "предустановленные". И тогда вы влетаете в то, что можете получить offensive-картинку. Не говоря уже о том, что можно же, зная сервис, проверять, есть ли там такая картинка.
muxa_ru
30.10.2017 16:33тогда надо просто смотреть какие картинки повторяюся — они и будут "паролем"
Но у этого метода есть одно слабое место.
Вы полагаете, что пользователь во-первых сможет запомнить что он там загружал пару лет назад, а во вторых — будет грузить на разные сайты разные картинки.Alex_Yanover
30.10.2017 16:39тут предполагается, что он должен грузить не что попало, а «знакомые» фото, которые он узнает и спустя десятилетия.
А так ещё есть один вариант — это авторизация через веб-камеру. Подобный функционал уже реализован у Битрикс24. Но тут получается необходимо, чтобы у всех пользователей была веб-камера…muxa_ru
30.10.2017 17:11а «знакомые» фото, которые он узнает и спустя десятилетия
В случае с текстовыми паролями эта гипотеза не подтвердилась.
Экспериментально было установлено, что либо паролей много и хрен их запомнишь, либо это то что не только сам человек помнит десятилетиями, но и весь остальной мир прекрасно знает — день рождения, кличка собаки и т.п.
Alex_Yanover
30.10.2017 15:15Правда в этом случае можно вычислить картинки самого клиента (они будут чаще других появляться). Но тут всё решается с помощью ограничение числа попыток. Если кол-во попыток превысило лимит, то тогда уже можно сделать авторизацию через ссылку на почту (как описано в этой статье). После этого опять кол-во попыток возобновляется.
Пытался найти похожее решение в интернете, где оно подробно описано и уже решены всякие нюансы, но не нашёл…
strapony
30.10.2017 12:51И ещё один большой(и самый главный) минус:
Сервисы, описанные в статье, пытаются всеми силами удержать пользователя у себя на сайте:
встраивают даже превью внешних сайтов, A/B тесты с цветами кнопок гоняют, а вы же предлагаете отправить человека на сторонний сайт, причем, в отличие от OAuth через популярные сервисы, не на специальную страницу, которая вернёт его обратно.
maxru
30.10.2017 13:54А что делать в случае, если я хочу авторизоваться прямо сейчас, а не через полчаса?
Не все почтовые сервисы одинаково быстры, не все антиспам сканеры одинаково качественны.
TimsTims
30.10.2017 14:14Самая удобная авторизация:
Либо: Предоставление сервиса без авторизации как есть. Действительно ли у вас такой сайт, что нужно прям идентифицировать пользователя?
Либо: Вообще забыть про пароли. Допустим, вы цветочный онлайн магазин. Предложите пользователю ввести свой телефон (заказы будут сгруппированы по нему. подтверждать телефон не обязательно). Для параноиков — предложите им придумать свой идентификатор, например «l33t0p», и всё! Допустим злобный хакер захочет взломать вас — ну подберёт он разные варианты, ну и что с того? Узнает, что некий «l33top» любит розы, а не пионы?
Либо:
1) Если уж нужно как-то юзеров идентифицировать, то предложить авторизоваться просто введя свой email. Пароль придумать не просим. Сразу предоставляем пользователю полный сервис(в пример — онлайн кинотеатры, которые дают контент без регистрации, но с рекламой). Далее авторизовываем также по почте, без пароля.
2) На почту отправляем ненавязчивое письмо с просьбо подтвердить почту, но можно и не подтверждать.
3) Когда клиент захочет оплатить какие-то услуги у вас, привязать карту там, то попросить его подтвердить почту для его же безопасности, и придумать пароль.
aragon_sp
30.10.2017 14:46При такой аутентификации, в момент, когда пользователь кликает по пришедшей ему ссылке, токен передаётся по сети в открытом виде. Т.е. устойчивость к MITM=0
SuperPaintman Автор
30.10.2017 14:47У нас есть HTTPS, а с Lets Encrypt вообще нет ни одной причины не использовать его.
К слову, а подтверждая email переходом из того же письма, вы более устойчивы к MITM?
aragon_sp
30.10.2017 17:37Более устойчивы, с той точки зрения что почту мы подтверждаем один раз, а пользуясь этим механизмом авторизации мы делаем это при каждом входе, из разных мест и с разных устройств.
Хотя, опять же, выше уже замечали, что восстановление пароля по почте без контрольных вопросов — это тоже несекурно.
manoftheyear
31.10.2017 10:46Есть ещё одна альтернатива в наши дни.
Сейчас очень много смс-сервисом. Можно сделать авторизацию не по email а по мобильному телефону. Мобильный телефон есть у 99% людей, а у пользователей интернета наверное и того больше. Отправлять пользователю смс-ку с номером для авторизации, и всего делов.
Не нужно лезть в почту, всё быстро и без пароля. Я так и сделал на одном проекте, правдв он пока не работает в полную силу, но тесты радуют.
Правда есть один минус, для многих, возможно, будет существенным — плата за смс-ка.sumanai
31.10.2017 19:54Правда есть один минус
Их больше. Я не ввожу номер мобильного на левых сайтах, мне спама от банка было достаточно.
nelson
31.10.2017 11:52Не совсем понятно, почему OAuth рассматривается автором только в отношении социальных сетей. Этот механизм поддерживается и email-сервисами. Поэтому у меня на сайте есть кнопки «Войти без пароля через Mail.ru / Яндекс.Почту / GMail».
1) избавляемся таким образом от необходимость слать письмо «подтвердите вашу почту» (все ящики верифицированы таким образом по умолчанию)
2) убираем пароль
3) получаем дополнительную инфу, такую как имя
И эти кнопки пользуются популярностью — через них регистраций в несколько раз больше чем через социальные сети.
Конечно, от соцсетей есть дополнительные плюшки вроде аватарки, другой инфы, что позволяет сразу создать полноценный профиль. Но в статье речь только про авторизацию.
enzain
31.10.2017 13:43Эээээ
Ну, может в паролях и нет смысла, в принципе тут на вкус и цвет…
Но таки — по моему проще регистрироваться по сертификатам… ну и авторизовать
vtvz_ru
31.10.2017 19:42+1Комментариев слишком много, может быть кто-то уже высказывал подобную мысль. Как вы думаете, такая схема не лучше:
- Я захожу на сайт, в форму входа вбиваю свой email, отображается сообщение ожидания.
- На этот самый email приходит сообщение с ссылкой, подтверждающей вход.
- Когда я перешел по ссылке, на самом сайте обновляется страница (или редирект), что свидетельствует о том, что авторизация прошла успешно.
Над вопросом безопасности, конечно, стоит подумать. Но польза от этого подхода в том, что не обязательно подтверждать вход с того же устройства. Залогиниться можно, допустим, на компе, а подтвердить на телефоне. Потом, клиентом может быть не только браузер, но и мобильное приложение или даже телевизор.
При запросе авторизации можно отправить либо тип клиента (web, mobile, tv), либо callback url, чтобы, если клиент — web или есть url, то показать кнопку, через которую можно вернуться на сайт.
SuperPaintman Автор
31.10.2017 20:04Если я вас правильно понял, вы хотите, чтобы страница (с которой отправлен запрос) сама перезагрузилась, когда вы перейдете по ссылке из письма. Идея хорошая, но тут может появиться излишние затраты либо на Long polling, либо на полноценный Web socket (запросы по таймаута — зверство, поэтому я их не рассматриваю). Но этот вариант может решить проблему с телевизорами / IoT'ами.
Можно сделать менее красивый, но и менее затратный вариант: запоминать email на который выслали письма, а после ручного рефреша страницы (или перехода на другую страницу) проверять, перешел ли пользователь по ссылке из письма и окончательно авторизовать его. Т.е. получается такая двух этапная авторизация, на первом шаге мы просто записали email в переменную сессии (localstorage / cookie / backend session), а после подтверждения активировали эту сессию.
SuperPaintman Автор
31.10.2017 20:14Но нужно еще продумать о безопасность этого подхода, т.к. хранить только email в клиентской сессии, вообще не безопасно, нужно тогда возвращать какой-нибудь секрет от запроса, сгенерированный бэком, а также хранить его в
sign_in_requestsтаблице.
С хранением на бэке, примерна такая-же история, нужно будет записывать guid сессии (cookie-based сессии) в таблицу
sign_in_requests, и опять же сверять при рефреше сочетаниеemail+secret.vtvz_ru
31.10.2017 23:29Безопасность, это другой вопрос (важный, но другой). Тут главное подход. И он, как мне кажется, более гибкий и универсальный, чем тот, который описан в статье.
Tallefer
31.10.2017 20:30Ну вот например гитхаб, если войти в одной вкладке из нескольких, рисует на других страницах оповещение вверху, мол, рефрешни, раз уж залогинился. :)
С другой стороны, дико бесят сайты, где даже рефреш не помогает на одной вкладке, если зайти на другой.SuperPaintman Автор
31.10.2017 21:14Могу ошибаться, но у Github синхронизация только между табами одного устройства, и скорее всего через localstorage / cookie в браузере.
А вот с подходом, описанном выше, так не получится. Нужен сервер в любом случае.
Tallefer
31.10.2017 22:43Ну так я там по паролю логинюсь. :) А с почтой другой пример — некоторые саеты требуют подтверждения после реги, удерживая на промежуточном экране, пока ссылку не откроют, а где — не важно уже.
PaulMaly
31.10.2017 22:20> И не стоит использовать данную технику
А можете раскрыть почему эта техника не подходит для перечисленных платформ?
VlasovVV
В таком случае на почтовые сервисы ляжет двойная ответственность.
А вообще, концепция имеет место быть, тоже задумывался о таком.
SuperPaintman Автор
А на них и так вся ответственность. Если у вас предусмотрен сброс пароля, считайте у вас и нет нужды в нем.
lair
Сброс пароля бывает не только через почту.
А еще есть разница между "открыть сайт, нажать кнопку ввода пароля, войти" и "открыть сайт, нажать кнопку, пойти в почту, нажать ссылку, войти".
SuperPaintman Автор
Бесспорно, этот путь длиннее. Но если на сайте достаточно длинные сессии, то, думаю, это может нивелировать данный минус.
lair
Не может. Все равно необоснованно много операций ради чего?
SuperPaintman Автор
Ради отказа от бесконечного количества паролей и их менеджеров. Просто другой путь.
lair
Вы так говорите, как будто пароль в почту не надо менеджить (а если на него все завязано, то ведь его надо менеджить еще сильнее).
SuperPaintman Автор
Что вы понимаете под менеджментом пароля для почты? Я говорил о программах-менеджерах, которые генерируют и хранят ваши пароли от учетных записей.
А пароль от почты, да, его действительно нужно хранить очень и очень сильно, независимо ни от чего. Т.к. в текущем положении дел, он является мастер паролем (из-за возможности сбросить пароль учетной записи на сайтах, зарегистрированных на эту почту).
lair
Вот про это я и говорю. Пароль от почты же тоже надо где-то хранить; особенно учитывая, что это не единственный пароль, который надо хранить. Так что менеджер все равно нужен. А если он есть, то уже не важно, сколько паролей хранить.
SuperPaintman Автор
Сомнительно, я спокойно запомнил все пароли от своих email'ов, хоть они и сгенерированны. Это был лишь вопрос времени.
Но эта проблема проста для программистов и серьезных пользователей. А вот подавляющее большинство использует незамысловатые комбинации, и, вероятно, используют один пароль везде. И вот в этом случае, безопасность повышается в разы, т.к. такому пользователю достаточно помнить один сильный пароль от почты, и хотябы.
Но оба подхода не спасут ни от стикера на мониторе, ни от
masha123456.lair
Во-первых, пока вы его запоминаете, он все равно должен где-то храниться. Во-вторых, это работает только для часто используемых паролей. В-третьих, я не доверяю своей памяти настолько, чтобы внезапно потерять доступ к интернет-банку.
А почему вы думаете, что у такого пользователя будет сильный пароль на почту?
SuperPaintman Автор
Да я и не думаю так, но так есть хоть какая-то надежда обезопасить такого гражданина.
lair
Если у него слабый пароль на почту, то принудительно привязав сервисы к почте вы его не обезопасили, а наоборот.
SuperPaintman Автор
Ну раз мы рассматриваем такого пользователя, давайте уж будем честны, он использует свою реальную (единственную) почту. Тут уже никто не поможет.
lair
Но ухудшать-то зачем? Если на нашем сервисе сильные требования к паролям и нет возможности восстановления через почту — нам искренне пофиг, насколько слабый пароль у пользователя на почту.
SuperPaintman Автор
Да, потому, что он забудет свой "сильный пароль" или напишет его на стекер (и потеряет его), а потом будет дергать саппорт с требованием восстановить ему пароль.
А практика с "ваш пароль недостаточна сильный", я считаю одним из проявлений садизма.
lair
Пусть дергает. Это лучше, чем потеря критических данных.
Если вы можете себе позволить выдавать каждому пользователю (безотказное) устройство генерации одноразовых кодов с биометрической аутентификацией — то можете не ограничивать сложность паролей. А иначе вам как-то придется бороться со слабыми паролями.
Вопрос ведь в критериях сильного пароля, а не в самой практике.
SuperPaintman Автор
Очень спорное высказывание, т.к. зависит от множества факторов.
А зачем, пользователь все равно найдет как его "подарить".
Мне кажется, мы с вами уже уперлись в тупик обсуждения. Мне абсолютна ясна ваша позиция, и я надеюсь, что вы хотя бы допускаете, что моя теория имеет место быть.
Во всяком случае, мне было очень приятно с вами подискутировать, и обсудить возможные недостатки предложенной выше системы.
Если вы не против, продолжим завтра.
А пока, хорошего воскресения, и добрых снов :).
avost
То есть ваш подход — это всего лишь прикрытие собственной задницы перед начальством или заказчиком, когда поломают вашего пользователя, — мы не виноваты, пользователь проэ… мотал не наш пароль, а почтовый.
Не решение проблемы, а просто спихивание ответственности.
lair
Есть ситуации, когда обращение в саппорт лучше, чем потеря данных из-за компроментации емейла.
Чтобы избежать тривиальных ошибок.
muxa_ru
Да, помню эту историю.
Чувак потом рассказывал что он потерял фотографии своей дочки из-за того что кто-то сумел уболтать саппорт и получить доступ к его эпловой учётке.
Desprit
Хочется верить, что с таким подходом и пользователям искренне пофиг на вас и наш сервис, чего бы вы там ни предоставляли.
E_STRICT
Пользователям у которых много разных email аккаунтов всё равно придется запоминать или записывать связку url -> email. Конечно это проще чем url -> email / password, но все равно менеджер может еще понадобится.
helgihabr
Возможно, это сократит колличество паролей. Но Вы, видимо, подразумеваете, что почтовый клиент у пользователя забирает почту без необходимости ввода пароля. Если же нет, то человеку нужно будет пройти дополнительные шаги авторизации в почте.
Если же ориентироваться на длинную сессию в почте, то такой же подход можно применить и на сайте.
У нас на одном из сервисов сессия сохраняется более суток и подавляющему большинству пользователей не приходится часто вводить пароли.
Такой подход, возможно, больше подходит для временных аккаунтов или там, где нет необходимости в регистрации.
DrPass
Этот путь не просто длиннее, он сложнее. Вам надо ещё и сделать свой сайт настолько интересным пользователю, чтобы более сложная аутентификация не отбила желание пользоваться вашим сервисом/ресурсом. Благо, у вас скорее всего будут конкуренты без этих хлопот.
Вы же забываете, что пользователю в общем случае не сложно придумать и потом вводить пароль. И не сложно его запомнить. Знаете почему? Потому что пароль к вашему сайту у него в подавляющем большинстве случаев будет такой же, как и ко всем другим аналогичным сайтам, и вполне вероятно, к его почте и онлайн-банкингу. А вы вместо того, чтобы вводить привычное слово, предлагаете пользователям квест «зайди в почту, найди наше письмо, открой письмо, перейди по ссылке. И желательно потом не забудь удалить письмо»
sleonov
Понимаете, с одной стороны — ваша мысль интересна. С другой — неудобна. очень неудобна. Если, допустим, я каждый раз буду вынужден делать ЛИШНИЕ движения в виде проверки почтового ящика, для авторизации на каком-то ресурсе, то я просто через некоторое время перестану им пользоваться. Люди вообще ленивы сами по себе (отсюда и пульты управления бытовой техникой), поэтому любое лишнее движение будет воспринято отрицательно. Тем не менее было бы интересно провести где-то эксперимент и посмотреть на результаты.
reiser
Вечные куки в большинстве случаев решат проблему :)
Сервисы, любящие ставить куки на две недели, это отдельная беда, конечно.
mickvav
Что-то мне подсказывает, что можно (нужно и стоит) при использовании такой схемы оставить пользователю в профиле тычку/галку/слайдер вида «Помнить меня день/неделю/месяц/год/до посинения»
Karpion
Это Вы не видели игру The Settlers Online — она разлогинивается через пару часов!
Хотя вечные куки — это проблема на компьютере коллективного пользования.
vintage
А какая разница будет кука на 15 минут или на 100 лет, если через минуту за комп может сесть другой человек? Для девайсов коллективного пользования должна быть хорошо заметная кнопка "выйти".
Karpion
Ну, есть же правильное решение: кука существует до закрытия браузера. Закрыл браузер = разлогинился автоматически.
vintage
Очень не удобно на девайсе личного пользования.
Karpion
Ну так это надо оставить на усмотрение пользователя. Но по умолчанию д.б. «до закрытия браузера».
И этот выбор должен настраиваться так, что при заходе с нового устройства надо заново выставить опцию «хранить куки и после закрытия браузера». А по умолчанию на каждом новом устройстве куки хранятся до закрытия — независимо от того, какой выбор я делал на других устройствах, где работал раньше.
eugene08
Электронная почта это много независимых почтовых серверов + набор необязательных к исполнению соглашений — доставка отдельно взятого письма вообще никем и никогда не гарантируется, оно может уйти в /dev/null по дороге, доставка задержаться, упасть в спам и тп, для реализации вашей же идеи необходима идеально работающая почта.
vikarti
А уже нечто похожее например сайт издательства МИФ использует.
eoffsock
На сайте Бюро Горбунова аналогичная система. Вообще на таких сервисах это реально удобно, деструктивных действий практически нет (нельзя удалить аккаунт, перевести миллион денег на произвольный счет и так далее). Ну зайдет кто-то на МИФ, ну почитает мои книги. Карточка у меня виртуальная, купить с нее человек ничего не сможет, пока я сам туда не положу деньги.
JediPhilosopher
Western Union использует примерно то же через SMS. Для логина вводишь номер телефона, приходит код в SMS, вводишь его. Никаких паролей.
В целом неплохая система как мне кажется, а раз уж такая крупная и связанная с деньгами компания ее использует — это повод как минимум подумать и посмотреть на нее внимательнее.
vitaliy2
ага XD
ага XDXDXDXD
wiygn
Компания из Fortune 500 для вас недостаточно крупная?
susnake
Пароли через СмС не очень секьюрное решение, т.к. добавляется еще одна цепочка которому мы должны доверять — оператор сотовой связи. Я точно не помню, но по-моему передача смс не зашифрована, поправьте меня если я не прав.
Плюс СмС перехватить можно.
Но это если уже совсем ударяться в паранойю.
kalininmr
и дубль симки сделать можно(были случаи и неединожды)
deburger
вы и так доверяете оператору свои деньги, неужели доверить еще и временный пароль от социалочки такая проблема?
sumanai
250,42 рублей баланса?
deburger
и что, 250р уже не деньги?
vitaliy2
Намекается, что если компания крупная, это совсем не значит, что система у неё хорошая. Чаще бывает наоборот — компания либо ещё что-то очень крупное, но сделано что-то чуть ли не самым плохим вариантом.
Что касается конкретно данного случая, защита по смс — один из наименее безопасных вариантов из всех возможных. Получается, компания крупная, а защита минимальная.
Хотя если отслеживается перевыпуск карты, уже не совсем ужасная защита (без этого это даже защитой нельзя считать в принципе, т.?к. защита минимальна), но всё-равно, это явно не то решение, на которое нужно равняться.
За что мне поставили 4 минуса — не понимаю. Видимо, нужно было лучше объяснить.
saipr
Тогда надо использовать облако.