В свете исследования "Веб-разработчики пишут небезопасный код по умолчанию" мне подумалось, что именно так может звучать один из базовых вопросов на собеседовании с точки зрения проверки знания web-разработчика от уровня Junior до Senior.
Тема с одной стороны в общем-то простая, а с другой - многогранная. Можно сделать “на коленке”, а можно и “по-взрослому” - зависит от знаний конкретного девелопера и технического задания. Ну и не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет. Ну и отлично же! Давайте попробуем.
Я попытался разбить вопросы на три уровня. Каждый следующий уровень обязан включать все вопросы выше, т.е. уровни и вопросы отсортированы от простых к более сложным.
Как бы вы ответили на конкретный вопрос? Попробуйте проверить себя и потратить пару минут на обдумывание прежде чем читать ответ.
Восклицательным знаком ⚠ помечены вопросы, на которых можно "засыпаться" и оставить плохое впечатление о себе у интервьюера. Так же я позволил себе добавить еще пункты, которые подразумевают "Регистрацию", но по касательной. Многие ответы обрамил ссылками, которые помогут разобраться чуть глубже в конкретном вопросе, думаю будет полезно.
Итак, за вёсла!
Junior level
⚠ Нужно ли скрывать вводимый пароль на странице?
Конечно. Никто не хочет, чтобы кто-то подсматривал пароли из-за плеча, верно? У input есть специальный атрибут password для этого. Это очевидно, но это и первый пункт. Дальше будет сложнее, обещаю :)
Должны ли валидироваться поля для ввода на клиентской стороне?
Должны. Как минимум на пустые значения. Отправлять пустую форму на сервер плохая идея. Во-первых, зря нагружает бэкенд, во-вторых страдает юзабилити - вы заставляете пользователя ждать там, где можно обойтись и без запросов на сервер.
Аутентификация? Авторизация? Идентификация? В двух словах расскажите что за что отвечает.
Часто эти понятия путают, поэтому давайте кратко:
Идентификация - это проверка что такой пользователь/логин/email существует в системе.
Аутентификация - проверка связки логина и пароля, то есть проверка на то, не выдаёт ли пользователь себя за другого человека.
Авторизация - проверка прав доступа пользователя к внутренним ресурсам.
Крутую статью с примерами на енотах посоветовали в комментах.
Запрос с данными формы должен идти через GET или POST?
Правильнее делать используя метод POST. Ничего вам не мешает сделать это любым другим методом, однако правильнее всего данные формы слать именно через POST. Изначально этот тип запроса был спроектирован не идемпотентным. Это значит, что отсылая его вы не можете гарантировать, что последствия его выполнения будут одинаковыми, если вызвать его несколько раз подряд. Поэтому в случае обрыва соединения браузер переспросит вас хотите ли вы заново отослать эту форму (вы наверняка видели такую хотя бы раз). Все GET запросы же перепосылаются браузерами без подтверждения.
Так же тут стоит упомянуть, что все данные запаковываются в body, который прикрепляется к запросу, что может помочь от утечек как в системе логирования на стороне сервера так и по пути к нему.
Почитать можно тут и на стеке.
⚠ Сохраните ли вы в пароль при регистрации "как есть" в текстовом виде (plain text)?
Если да - это непрофессионально и даже преступно. Пароли должны быть зашифрованы стойким алгоритмом по ключу, идеально - если они хэшированы.
Хэширование - это преобразование данных без возможности их обратного восстановления. И кодирование Base64 тут не подойдёт, как почему-то решили некоторые ребята из исследования в начале статьи. В случае, если вашу базу выкрадут злоумышленники - у них окажутся все пароли ваших пользователей. В случае же шифрования или хэширования - им придётся изрядно дополнительно попотеть чтобы завладеть паролями даже с учётом слитых данных...
Данные статистики говорят о том, что 30-40% организаций хранят пароли в plain text. И в 2018-ом даже Twitter с его 330+млн пользователей смог. Ух.
Почитать можно тут и на Хабре.
Нужно ли проверять вводимые данные не только на UI стороне, но и на сервере? Является ли это ненужной/двойной работой?
Главное правило веб разработчика - не доверяй клиенту (браузеру). Все данные/поля могут быть отосланы/подменены другими инструментами, поэтому вам нужно обязательно делать полный цикл проверки на сервере.
Почитать развёрнутый ответ можно на стеке.
Нужна ли валидация на сложность пароля или можно позволять пользователю иметь пароль любой сложности?
Заставлять пользователя придумать пароль в соответствии с правилами - безусловно здравая идея, т.к. слишком простые пароли легко подбираются путём перебора по словарю. Но тут важна грань, т.к. знаю реальный пример, когда правила пароля настолько сложные, что пользователи потом хранят эти пароли в текстовых файлах на рабочих столах, т.к. запомнить их нереально. А это еще хуже :) Получается, заботились о безопасности, а по факту родили новый вектор атаки.
Хорошая статья про границы политики паролей есть на Хабре.
Middle level
Соединение защищено по https?
Если нет, то у меня для вас плохие новости - ваш логин и пароль может быть легко перехвачен по пути от вашего браузера к серверу. Это может быть как целенаправленная атака, так и “пассивный сниффинг данных“ публичными Wi-Fi, на уровне провайдера или даже на уровне уязвимого роутера, которым вы пользуетесь. Еще лет пять назад встречались сайты, где форма оплаты могла быть на https, а весь сайт - по http и в целом это работало безопасно (т.к. во время платежа на клиент не сохраняется никаких данных, которые впоследствии могут быть перехвачены по http каналу), однако сайты без https сегодня - это уже моветон и первый признак того, что такому сайту свои данные доверять нельзя.
Оффтоп
Кстати, буквально на днях выпустил пост о "SSL/TLS/Асимметричном шифровании на пальцах" у себя на тг канале, поэтому если интересна тема - вэлкам!
На тему вопроса есть хороший ответ на стеке
⚠ Нужно ли при неудачной попытке регистрации писать, что такой пароль уже существует в системе?
Конечно нет. Вы должны выдавать МИНИМУМ информации всего, что касается безопасности. Есть шуточная версия в виде сообщения "такой пароль уже используется пользователем %username%". Шутки шутками, но возможно где-то и внедрили, за более чем тринадцать лет опыта работы и не такое встречал.
На aws к слову максимальный уровень - после ввода логина, сразу же запрашивают пароль + второй фактор (2fa), т.е. злоумышленник даже не сможет узнать какой именно параметр не подошёл.
Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - это логин (а лучше хэш логина). Пароль - нельзя. Было уже множество громких инцидентов когда у крупных сервисов ломали системы логов и вытаскивали пароли, которые логировались в plain text (логировался весь реквест).
Примеры взломов можно глянуть тут и тут.
Если хэшировать в базе пароль, то как? Каким алгоритмом?
Хорошо, если мидл назовёт парочку, допустим md5 или sha-1/sha-256. Вопрос чем они плохи - уже скорее сеньорский левел, обсудим это ниже. Однако считаю, что для мидла и такой ответ пойдёт. Также плюсом для собеседующегося будет рассказ о том как именно нужно хэшировать - т.е. с солью. SALT - это что-то, что добавляется к паролю чтобы уменьшить риск его обратного преобразования в случае утечки данных. Многие популярные пароли уже находятся в базах (так называемые радужные таблицы или Rainbow tables) и хеши к ним подобраны, поэтому реверснуть какой-нибудь md5 без соли - дело несложное.
Вот тут хорошая статья с Хабра о хешировании паролей.
Senior level
Каким еще способом можно обезопасить форму? Что такое CSRF токен и имеет ли смысл его добавлять?
Это вопрос на самом деле в целом на понимание вида уязвимости CSRF (Cross-Site Request Forgery). Сеньор должен знать и понимать как это работает как со стороны имплементации, так и со стороны взламывающей стороны (хакера).
Безусловно, запрос должен посылаться с CSRF токеном. Это гарантирует отправку формы тем же клиентом, что её и отобразил.
Подробности тут.
update : Меня в комментариях резонно тыкнули в то, что уже лет пять проблема как фактически не актуальна, т.к. существует и поддерживается аттрибут SameSite. Резонно. Остаётся лишь вопрос к старым браузерам, где этой поддержки нет. Тут и тут есть описание проблемы и её решения.
update2 : Так же CSRF уязвимость не имеет силы при использовании JWT токенов, т.к. сам app ставит их при осуществлении запросов.
⚠ Что такое двухфакторная аутентификация (2fa) и нужна ли?
Вопрос для сеньора, однако в целом мидловский, т.к. 2fa уже прочно вошла в широкие массы и будет плохим признаком, если вы ответите в духе wtf.
Для серьёзных сервисов - 2fa is a must. Существенно снижает риск зайти в вашу учётку злоумышленником даже зная ваши логин и пароль. 2fa - это "второй фактор", обычно некий токен, который выдаётся через ваш телефон (приложение или же смс), но не ограничивается им. Могут быть и более безопасные варианты в виде usb флешек, блютус девайсов, биометрических сканеров и тп.
Почитать о 2fa можно тут.
Как бы вы хранили пароль в базе? Хешированным? Солёным? Поподробнее пожалуйста!
Пароль должен быть хеширован, притом важен алгоритм. md5 и sha-1 - уже не подходят в текущих реалиях и помечены как небезопасные (RFC 6151,RFC5246). Используйте bcrypt, PBKDF2 или SHA-256.
Что по соли - она может быть одна для всех пользователей, но в идеале - уникальная для каждого пользователя, т.е генерируется из данных самого пользователя. Плюсом будет, если упомянете тут о радужных таблицах.
Так же, кроме соли еще существует и понятие перца. Если соль может храниться рядом с данным пользователей, то перец должен храниться где-то в другом месте (об этом ниже).
Хорошая детальная статья тут.
⚠ Сможете ли сами написать алгоритм для хранения пароля?
Правильный ответ тут - не нужно изобретать криптовелосипеды, если вы не бородатый математик! Слишком просто допустить критическую ошибку в алгоритме и снизить стойкость. Хорошо, если вы сможете привести пример несложного шифрования через XOR или расскажете про AES256 и для чего нужен вектор инициализации (IV).
Ну и немного вопросов для Senior+
Что делать в случае коллизий паролей при хэшировании?
Коллизии существуют для большинства хеш-функций, но для «хороших» функций частота их возникновения близка к теоретическому минимуму. В целом - чем длиннее хэш, тем меньше шанс этой коллизии. Именно md5 и sha-1 не обеспечивают этой длины в сегодняшнем мире. Так же можно упомянуть про двойное хеширование и метод цепочек - внутрянку знать не обязательно, просто знать, что методы есть.
Если принято решение шифровать пароль, то какой тип шифрования выберете? Почему?
Вопрос на знание отличий симметричного vs асимметричного типа. Хорошо бы понимать разницу. Ответом тут на самом деле будет “it depends”, зависит от системы взаимодействия. Обычно, используют симметричное, т.к. асимметричное подразумевает валидацию второй стороной, которой скорее всего не будет. Плюс симметричное шифрование быстрее. Неплохо бы так же дополнить, что шифрование не замена хэшированию и должно применяться только в крайних случаях для кейсов подобно обсуждаемому нами.
Рекомендации по теме "Hashing vs Encryption" можно найти прямо в cheetsheets OWASP'a.
В связи с предыдущим вопросом - одинаков ли по стойкости 128-битный ключ для симметричного и асимметричного способа?
Нет, не одинаков. Природа асимметричного шифрования подразумевает, что ключ должен быть намного длиннее. Эквивалент 128 битного симметричного ключа равен 2048 асимметричного. Хорошо бы тут еще затронуть про плюсы и минусы каждого из подходов и паттерны применения (расскажите про SSL/TLS и как он устроен)
В дополнение - хороший ответ на qna Хабра тут.
Хорошая ли идея вынести аутентификацию на openid?
Безусловно да, если на сайте множество поддоменов и сервисов - это позволит упростить коммуникацию групп бэкендов/сервисов, а так же фрагментирует точки отказа в случае их возникновения. Т.е. если ляжет авторизация, все остальные узлы сервиса скорее всего будет работать, т.к. логически вынесены. Получится, что модуль аутентификации не размазан по множеству бэкендов. Плюс это более расширяемое решение и добавляет изолированности этой важной функции.
Если на аутентификацию будет один из векторов атаки - это не затронет остальные компоненты системы. К слову это частая точка для ддоса, т.к. обычно грамотная аутентификация построена на "долгих" алгоритмах и кушает и память/cpu, а значит может легко положить всю систему, если та гвоздями приколочена к основной группе сервисов. Хорошо бы еще упомянуть и про Oauth 2.0 - это второй по популярности протокол.
Что есть Rate Limiter и каким боком оно нам к форме аутентификации?
Это уже немного вне темы сабжа, но и уровень всё же со звёздочкой - добавим в тред :) Rate Limit (или Throttling) - это механизм ограничения запросов по какому-то сценарию. В случае брутфорса или же ддоса - позволит отсекать вредных клиентов и не аффектать "хороших". Все большие ребята следят за этим. Часто авторизацию прячут (как и весь сайт) за тем же Cloudflare, который берёт на себя эту функцию. Rate Limiter может быть и кастомным и быть реализован на уровне самого приложения. К примеру в виде “не принимать больше n запросов per period от такого-то пользователя с такой-то ролью”. Есть такие опции и у тех же Lambda functions от AWS, там прямо в интерфейсе можно прописать нужные цифры.
Тут можно найти общая инфу и про алгоритмы. Ну и классная статья от Яндекса об их пути рейт лимитера.
Где хранить соль и как её формировать?
Обычно, соль хранится где-то рядом с паролем. Однако в случае, если злоумышленник сможет слить базу - соль станет ему доступна. Поэтому к соли еще хорошо бы добавлять либо какую-то константу, которой нет в бд, либо проводить данные через какой-то “black-box” алгоритм, который так же не будет известен хакеру - этим вы ещё больше снижаете риск взлома хэшей, т.к. соль будет храниться в двух местах. Усложняя - можно (и нужно) комбинировать эти два метода и переменную брать, допустим из переменных окружения.
Так же важно добавлять соль после пароля, а не до. Причиной этому является одно из свойств хэширования - поточное преобразование. В случае, если соль добавлется перед паролем - злоумышленник скорее всего сможет найти соль, учесть её и вычислять уже хэши без учёта этой самой соли.
Выводы
Как мы видим - одно и то же задание может быть сделано как джуниором, так и высококлассным специалистом и результаты будут весьма разные. Позволю себе вставить пять копеек к статье об исследовании в начале сабжа : глупо ожидать серьёзного уровня реализации за 200 евро (а уж тем более за 100) на фрилансе, однако и хранить в Base64 определенно точно не стоит, если вас попросили обеспечить безопасность паролей. Нужно объяснять заказчику тезис трёх основополагающих свойств результата работы : Быстро/Качественно/Дёшево - выбрать можно только два из них.
Пожалуй, это основные моменты, которые пришли на ум. Если что-то пропустил или где-то не прав, вэлкам в комментарии ;)
ps. Если вы так же любите айтишечку как и я - буду рад видеть вас на своём Telegram канале.
Комментарии (179)
Firz
27.05.2022 03:37-7Хорошо, если мидл назовёт парочку, допустим md5 или sha-1/sha-256. Вопрос чем они плохи — уже скорее сеньорский левел, обсудим это ниже.
Как по мне, если в 2022 году кто-то скажет что нужно для хеширования использовать md5, то это уровень стажера, даже не джуна.
antoo
27.05.2022 04:10+21Мой пароль в MD5: 0b538919bf6b514958c100fc8ad1ef87
Если что-то получится - можете прямо с моего аккаунта отписать его тут в чистом виде, чтобы убедить в небезопасности :)
Firz
27.05.2022 04:38+5Смысл использования нормальных алгоритмов в том что не все делают 20 символьный пароль с иероглифами, эмодзи и прочим, по-этому нормальные/тяжелые(argon2, к примеру) алгоритмы хеширования помогут добиться нормальной сложности перебора даже для слабых паролей пользователей.
Moraiatw
27.05.2022 06:52+4Сложная длинная соль усиливает слабые пароли.
Firz
27.05.2022 08:42А хранится она конечно рядом с паролем в базе?
Bronx
27.05.2022 09:47+3Сложная соль состоит из двух частей: одна хранится в пользовательской записи рядом с хэшем, а другая — в конфиге сервера. Об этом, кстати, в статье упомянуто ближе к концу.
polearnik
27.05.2022 10:35+4Это плохая идея хранить еще в конфиге или в переменных окружения. Усложняет жизнь разработчику но не повышает безопасность. Если хакер имеет доступ к базе то по умолчанию нужно считать что у него есть доступ к всему содержимому сервера. ПОэтому соль должна быть уникальна для каждой записи и хранится рядом с паролем. Так вы максимально сусложниет жизнь подборщику паролей и максимально неусложните жизнь разработчику
Bronx
27.05.2022 12:01+1Хакер может получить доступ не к серверу, а, например, к бэкапам. Или он может получить доступ к серверу БД, но не к веб-серверу.
polearnik
27.05.2022 13:58+1по умолчанию следует считать что он получил доступ к всему серверу. так проше строить защиту и сложнее запутатся в условиях взлома. Иначе вы можете придти к выводу что раз у взломзика нет доступа к коду то можно придумать свой алгоритм хэширования и шифрования .
Bronx
28.05.2022 01:00+3по умолчанию следует считать что он получил доступ к всему серверу
По-умолчанию нужно считать соотношение «цена/бенефиты» для разных видов защит от разных видов атак, а не идеализированный сценарий. Иначе вы можете придти к выводу, что раз идеальной защиты нет, значит нужно исходить из максимы «что попало в интернет известно всему миру», и посему защищать данные вообще бессмысленно и затратно, потому что беспечные юзеры сами всё сливают, а завтра наступят квантовые компьютеры, которые расшифруют всё.Иначе вы можете придти к выводу что раз у взломзика нет доступа к коду то можно придумать свой алгоритм хэширования и шифрования .
Код, как и БД, может храниться в куче мест, где к нему имеет доступ (или могут случайно ошибочно получить доступ) большее количество людей. Т.е. периметр атаки (или ошибочной публикации) для кода и БД гораздо больше, чем для ключей к серверу, которые хранятся только у админа. И отследить источник утечки гораздо труднее.
Сценарий «базы утекли» без доступа к серверу (через дырку в авторизации web API или внутренней сети, через слишком широкие запросы в web API, через внутренний слив бэкапов и проч) случается чаще, чем сценарий «хакер получил доступ к переменным окружения веб сервера». Если простая мера в виде разделения соли на две части, хранимой в разных местах, позволяет кардинально уменьшить периметр атаки, то этим нужно пользоваться, потому что выгоды выше затрат.
BugM
28.05.2022 02:41+1Сценарий «базы утекли» без доступа к серверу (через дырку в авторизации web API или внутренней сети, через слишком широкие запросы в web API, через внутренний слив бэкапов и проч) случается чаще, чем сценарий «хакер получил доступ к переменным окружения веб сервера». Если простая мера в виде разделения соли на две части, хранимой в разных местах, позволяет кардинально уменьшить периметр атаки, то этим нужно пользоваться, потому что выгоды выше затрат.
Подпишусь. Дешево, просто и может помочь.
Если чуть дороже: Сервис работающий с паролями должен жить отдельно вообще от всего. С совсем минимальными со всех сторон правами доступа к проду, любым системам виртуализации и железу на котором он крутится. И конечно же логи аудита вообще любого чиха на проде. Которые кто-то смотрит регулярно. Доступ к настройке, хранению и тому подобному логов аудита и проду работающему с паролями должен быть у не пересекающихся групп людей. Отдельная стойка запирающаяся на отдельный ключ с отдельным журналом кто его брал тоже хорошо сюда вписывается.
Если еще дороже: Добавляем HSM модуль. На котором и лежат ключи для расшифровки строк в БД. Тогда даже при утечке всего, но без долговременного доступа злоумышленника к проду, все украденное превращается в мусор.
PS: Чувствую что не возьмут нас по этому собеседованию. Мы о каких-то непонятных вещах говорить начнем, вместо нужного рассказа: используйте https и не храните пароли плейнтектом.
Bronx
28.05.2022 03:07Ну и добавлю, что «соль из двух частей» — это, пожалуй, было некорректное выражение с моей стороны, возможно даже вводящее в заблуждение. Правильнее, «соль + шифрование», потому что pepper по своей сути является не солью, а ключом шифрования хэшей.
Bronx
28.05.2022 01:48+1Чтобы не быть голословным: OWASP Password Storage Cheat Sheet: Peppering
Firz
28.05.2022 03:13Я вот правда не понимаю, использовать «сильный» алгоритм хеширования, а потом уже добавлять поверх дополнительных плюсов к защите(соль, перец, хотя я бы и их назвал обязательными минимально необходимыми пунктами, наравне с сильным алгоритмом) разве не логичнее чем использовать MD5 и надеяться что злоумышленник не получит доступ ко всему и сразу(к тому же перцу вместе с базой)?
Напомню, ветка то началась со спора что и MD5 норм если соль и перец подкинуть.
BugM
28.05.2022 03:17+1Оставь надежду всяк сюда входящий.
Делаем все возможное чтобы злоумышленник не получил доступ к чему-либо и делаем все возможное чтобы минимизировать последствия если доступ он все таки получил.
Bronx
28.05.2022 04:18Напомню, ветка то началась со спора что и MD5 норм если соль и перец подкинуть.
За MD5 я ничего не писал — только про то, что к соли можно добавить перца, ради «defense in depth». В общем, с вами я не спорил, просто воткнул 2 копейки :)
Firz
27.05.2022 14:29+3А может получить ко всему и все, md5 хеши генерируются что-то около 6,5*10^10 на современной 3090 видеокарте.
p.s. Если так рассуждать, можно тогда вообще сразу уж считать что хакер не получит доступ ни к чему, тогда не то что md5 становится подходящим решением, а хранение в открытом виде.
Format-X22
27.05.2022 20:07Вот совсем не одно и тоже всё же доступ к базе и к конфигам где-то в енвах, если там разные способы доступа и пароли к сервисам конечно.
PsyHaSTe
28.05.2022 10:26Объясните пожалуйста смысл такой операции? Чтобы защититься от радужных таблиц достаточно соли, чтобы защититься от брутфорса пары "интересных" пользователей — если пароль достаточно сложный то кажется не так-то просто это сделать даже имея всю соль на руках.
Firz
28.05.2022 14:03По сути, смысл перца в том, что он хранится где-то в отличном от соли и хешей месте. То есть добавляется возможность что если доступ к базе с хешами и солью получили, то к перцу(по сути, второй части соли) в env сервера, возможно не получили.
PsyHaSTe
28.05.2022 14:46Я понимаю как это работает. Меня интересует практический смысл — ша256 пароль с солью точно так же не отреврсить.
Bronx
29.05.2022 06:56Смысл тут скрыть даже хэши на случай если вдруг через год появится способ брутфорса. В принципе, конечно можно усложнять реверс просто увеличивая число раундов хэширования, но использование двух разных мер защиты (хэширование + шифрование) вместо одной (только хэширование) может помочь, если у одной найдётся слабая точка.
PsyHaSTe
29.05.2022 09:53А если завтра появятся квантовые компьютеры то все RSA пойдет коту под хвост. Надо быть реалистом наверное, а не готовиться к пришествию инопланетян..
Bronx
29.05.2022 23:44Но тут-то как раз были прецеденты: когда-то MD5 и SHA-1 считались достаточно секьюрными, а потом вдруг нет, и иноприлетян с квантовыми компьютерами не понадобилось.
HappyGroundhog
27.05.2022 12:46+1Вот только ХАБР не использует md5)
В случае же аутентификации по md5 можно не брутить пароль, а найти коллизию, т.е. другой пароль, дающий тот же хеш и с ним войти. В этом проблема использования md5, а не в возможности реверса. Хотя радужных таблиц для популярных паролей под него достаточно.quwy
28.05.2022 03:15+1В случае же аутентификации по md5 можно не брутить пароль, а найти коллизию, т.е. другой пароль, дающий тот же хеш и с ним войти. В этом проблема использования md5, а не в возможности реверса.
Я конечно дико извиняюсь, сварщик я не настоящий, но, блин, уже изобрели хеш-функции, не подверженные коллизиям?
HappyGroundhog
28.05.2022 08:47Я тоже ненастоящий сварщик) Но говорят для современных хешей сложность и время нахождения коллизии превышают разумные пределы, а вот для md5 увы нет.
PsyHaSTe
28.05.2022 10:28sha-256 часто используют не обрабатывая коллизии никак. Вот вы UUID когда генерируете часто рассчитываете на них? А sha256 куда реже их имеет.
PsyHaSTe
28.05.2022 10:27В качестве проверки концепта можно просто написать сюда плейнтекст коллизии. Этого будет достаточно чтобы разгромить коммент выше про то что мд5 хорош.
krabdb
27.05.2022 04:25+10Минимум с миддла должны первыми звучать другие важные вопросы:
Для какой программно системы эта форма и какие требования этой системы к процедуре аутентификации?
Если корпоративной, то требуется ли специальная форма аутентификации: смарт-карты, ПАК с УКЭП и прочие подобные радости.
Не банковская ли это система ДБО? Если да, то требуется ли ввод дополнительных полей, указывающих на организацию аутентифицируемого? Поясню - в некоторых ДБО при одном подписанте в разных ЮЛ это должен быть один аккаунт, а в некоторых - разные.
И много подобных вопросов применительно к корпсистемам.
Хотя, с текущим низким порогом входа в ИТ это уровень архитектора, наверное :)
kubk
27.05.2022 14:11+3Так это доменная специфика корпоративных систем, зачем это знать Middle в общем случае? На этом мир разработки не замыкается. Вы бы ещё спросили как делать авторизацию через Госуслуги.
FreeNickname
27.05.2022 04:28-3По соли ещё: при конкатенации пароля и соли, вначале должен идти пароль, а потом соль. Иначе, в зависимости от длины блока хэша, длины соли и длины пароля, комбинация "соль + пароль" может не влезть в блок хэш-функции, и конец пароля обрежется. А если "пароль + соль", то обрежется соль.
alexxisr
27.05.2022 06:41+12Может просто не обрезать? и хешировать всю полученную строку. Тогда будет не важно где соль. Или я чего-то не понимаю?
FreeNickname
27.05.2022 14:40Ответил в соседней ветке. Некоторые реализации хэш-функций примут на вход всю строку, но обрежут её сами, нужно быть аккуратным.
flx0
27.05.2022 14:30+3Причина совершенно другая. Если соль идёт вначале и известна нарушителю, то можно один раз посчитать промежуточное состояние хеш-функции и дальше брутфорсить от этого состояния. Если соль в конце, то придется каждый раз пересчитывать весь хеш целиком.
Никакие входные данные хеш-функциями не обрезаются.
FreeNickname
27.05.2022 14:34+1Эту информацию давали в курсе криптографии, который я проходил, и она верна как минимум для некоторых реализаций.
https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length
С bcrypt пример не самый удачный, потому что он сам разделяет пароль и соль, но суть не меняется.
Про промежуточное состояние хэш-функции не знал, спасибо!
up40k
27.05.2022 04:45+9Пара замечаний:
"Асимметричный" - от какого слова образовано? (Подсказка: не от слова ass)
PBKDF2 - это не функция хеширования. Если какие-то данные пользователя нужно шифровать, используя пароль, следовало бы упомянуть об этом отдельно. Иначе мухи с котлетами.
OpenID/Oauth могут точно так же стать единой точкой отказа. Необходимо упомянуть о масштабировании провайдеров. Ну и вы опять же в тексте смешиваете в кучу аутентификацию с авторизацией.
"такой пароль уже существует в системе" смешно, конечно, но если аутентификация вынесена в отдельный сервис, не лишним будет использовать на этапе валидации (на сервере) базу часто используемых паролей для проверки. 2FA снижает риски, но, всё же, моё мнение, - как ещё приучить пользователей не быть безалаберными?
-
"шифрование не замена хэшированию и должно применяться только в крайних случаях для кейсов подобно обсуждаемому нами" так и не понял, что за кейс такой. Данные аутентификации нужны только для аутентификации, которая односторонняя, в чём необходимость хранить зашифрованными и возвращать их в плейне? Приведите пример.
И ещё дополнение по валидации. В дикой природе есть сервисы, которые ограничивают пароли по алфавиту и длине. Пример: личный кабинет Читай-Города. Писал им, что не стоит так делать, но воз и ныне там. Хотя нет, они вот-вот переведут аутентификацию на sms. Хрен редьки не слаще.
Про глупость такого ограничения тоже стоило бы упомянуть.
Зы Прекрасное объяснение на енотах о разнице между id/authen/author в блоге ЛК, например.
affinity
27.05.2022 10:39+2"шифрование не замена хэшированию и должно применяться только в крайних случаях для кейсов подобно обсуждаемому нами" так и не понял, что за кейс такой. Данные аутентификации нужны только для аутентификации, которая односторонняя, в чём необходимость хранить зашифрованными и возвращать их в плейне? Приведите пример.
На самом деле - любая ERP/CRM для провайдера. Самая большая беда в том, что бОльшая часть пользователей при смене ОС/роутера/etc первыми делом просит пароль... Менять их - выстрел в ногу тех.поддержке, т.к. очень быстро у юзера будет с десяток бумажек с паролем - и он всеравно не поймет какой из них нужен. И снова позвонит. А потом еще раз... "эс как доллар" - суровые реальности :-(
ПС: Очень многие такие системы хранят plain текстом пароли до сих пор. Так что хорошо бы их хотя бы шифровать. Но вот хешировать - не очень вариант
Nigrimmist Автор
27.05.2022 13:28+11) упс. исправил
2) Правильно ли я понял, что отличие только в том, что в PBKDF2 является HMAC, который есть алгоритм, который вызывает хэш-функцию и в него уже "вшита" соль (пароль) + есть возможность указать кол-во итераций?
3) > OpenID/Oauth могут точно так же стать единой точкой отказа.
it depends, как и обычно. Много "если". Но сойтись тут можно в одном - вынесенная аутентификация снижает риск падения связанных сервисов в случае отказа первой.
4) Хороший поинт, согласен.
5) > Приведите пример
"напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица.". А еще "мы хотим собрать статистику по паролям и их сложности, но это будет когда накопим данных, а не в моменте". или "засетапайте эти же пароли в 3rd party системе, чтобы они были идентичны, ну вы поняли - и чтобы пользователь смог под капотом ходить в эту систему по кредам".
Всё это конечно про коня в вакууме, однако ...
> Прекрасное объяснение на енотах о разнице между id/authen/author в блоге ЛК, например
Статья огонь. Добавил в статью.
Спасибо за дополнения!
up40k
28.05.2022 01:02+1Правильно ли я понял, что отличие только в том, что в PBKDF2 является HMAC, который есть алгоритм, который вызывает хэш-функцию и в него уже "вшита" соль (пароль) + есть возможность указать кол-во итераций?
Криптографическая хеш-функция - это просто функция свёртки, обладающая необратимостью и стойкостью к коллизиям.
HMAC - механизм проверки аутентичности сообщений. Использует под капотом хеш-функцию.
PBKDF2 - механизм деривации ключа (который затем можно использовать как угодно, но вообще задумано использовать его для симметричного шифрования). Для деривации нужен секрет и еще какие-то данные (соль). Также использует хеш-функцию внутри (как частный случай псевдослучайной функции).Понимаете, тут вопрос в применимости. Для аутентификации по паролю онлайн (в удалённой системе) необходимо и достаточно хранить необратимые и стойкие к коллизиям солёные хеши.
Никто не запрещает вам использовать scrypt, bcrypt, PBKDF2 вместо простой (относительно вышеупомянутых) необратимой функции свёртки. Но! Прошу обратить внимание:Алгоритмы деривации вычислительно сложнее. Вы тратите ресурсы CPU сервера впустую, повышая риски DDOS (даже учитывая капчу и рейт-лимит).
Всё меняется при аутентификации оффлайн. Если у атакующего есть возможность осуществить атаку на секрет, имея хеш, а также время и ресурсы, то алгоритм деривации как никогда кстати - он подразумевает соль и количество итераций (в scrypt ещё и требования по RAM), которые усложняют словарную атаку и брутфорс, соответственно. Это актуально, например, при шифровании локальных хранилищ (атака evil maid). В этом месте закономерно возражение: но ведь всё равно приходится солить простые хеши в бд (а вдруг сольют). Моё мнение - требует отдельного исследования и сравнения скорость и вычислительная сложность алгоритмов деривации vs простой хеш+соль. Всё равно придётся искать компромиссы между нагрузкой на сервер (один из трёх китов ИБ - доступность) и рисками слива бд. Ну и ко всему прочему, последнее (риски), как всегда, нужно стараться нивелировать комплексным подходом (в безопасности без этого никуда).
Что же касается моего замечания за номером 2, прошу простить за буквоедство, вы назвали алгоритм деривации хеш-функцией, и меня что-то триггернуло. Попытался объяснить своё видение =)
Теперь что касается пункта №5. То, что вы и пользователь @affinity описываете, это всё такая системная дичь, которая совсем не решается техническими методами. Криптографией в том числе. Ну, немного сложности атакующему шифрование добавит, да. Если прям нужны пароли пользователей в плейне - ИМХО, нужно хранить их совсем в отдельном месте, с доступом на чтение только оффлайн и по отдельно разработанным протоколам.
Ares_ekb
27.05.2022 06:08+3Я бы ответил, что нужно взять готовое решение типа Keycloak, Ory, Avanpost, ... Но сначала посмотреть какая система уже используется у заказчика. Если никакая, то аналитик должен определить верхнеуровневые требования (например, нужна ли в принципе на этом конкретном сайте двухфакторная аутентификация), сделать обзор по существующим в мире системам идентификации и аутентификации пользователей, оценить их на соответствие требованиям, затем написать детальные постановки (например, с требованиями к правилам валидации вводимых данных). Затем можно начинать писать код. И конечно же после всего этого я был бы послан и с позором провалил собеседование, потому что от меня ожидали рассказ про необходимость хэширования паролей, и в итоге в опроснике было поставлено ноль галочек напротив правильных ответов.
Moraiatw
27.05.2022 06:54+3Хорошая ли идея вынести аутентификацию на openid?
Безусловно да
Если на аутентификацию будет один из векторов атаки - это не затронет остальные компоненты системы.
Вспоминается история с Трампом и соцсетью Parler. Американские леваки отключили хостинг для микросервиса авторизации соцсети. В результате можно было зайти под любым логином без авторизации, что они и сделали.
SdrRos
27.05.2022 07:01+2Нужно ли скрывать вводимый пароль на странице?
По факту часто должна быть возможность посмотреть введённые данные, т.к. сложные пароли большинство не запоминает а где-нибудь хранит и при копировании могут добавляться например пробелы.
mpetrunin
27.05.2022 08:41+2Асимметричное шифрование пароля в БД? Что вы под этим подразумеваете?
InChaos
27.05.2022 10:04А почему нет. пароли шифруются по открытому ключу, хранятся в базе, а закрытый для расшифровки можно вообще забыть. Получаем хорошее стойкое хеширование.
Rsa97
27.05.2022 10:48+2У шифрования есть недостаток. Алгоритмы шифрования, как правило, реализуют для максимально быстрой работы. Специализированное хэширование scrypt, argon2id или bcrypt строится так, чтобы вычисления не были слишком быстрыми и плохо переносились на GPU или ASIC. Соответственно, брутфорс такого хэширования занимает гораздо большее время.
mpetrunin
27.05.2022 11:57Оригинальный подход. В любом случае, некорректно подобное называть асимметричным шифрованием.
0x1b6e6
27.05.2022 13:151) можно "забыть забыть"
2) а зачем использовать асимметричное шифрование, там где можно использовать хеширование?
Nigrimmist Автор
27.05.2022 16:52Да, валидный комментарий. Я скорее имел в виду, что если затрагивается симметричное, то и про ассиметричное можно/могут спросить. Но да, к паролям в бд это имеет примерно никакое отношение.
HappyGroundhog
27.05.2022 08:52+2Категорически против идеи хранить пароли шифрованными. Проверку на неповторяемость можно реализовать и на уровне хеша.Шифрование видел т у одного разработчика, причем ключ шифрования был зашит прямо в код, в итоге реверснув его можно было на любой инсталляции показывать «магию», доставая из БД пароли пользователей в открытом виде…
InChaos
27.05.2022 10:05+1При нессиметричном шифровании реверснуть не получится, даже если открытый пароль прямо в коде.
HappyGroundhog
27.05.2022 12:41Тут вопрос где хранить ключ, которым вы будете это проверять? Видел варианты «В той же БД, что и пароли»… Если в переменных окружения, то при SQL инъекции спасёт, при RCE нет.
Ассиметричные ключи не панацея, если не уметь их готовить.Nigrimmist Автор
27.05.2022 16:58А какие вообще варианты при RCE есть защитить ключ? Как ни крути он в памяти сервера. Если только это не суперизолированный закрытый отдельный сервер/железка, куда на вход приходит строка, а на выходе - шифр.
HappyGroundhog
28.05.2022 08:55+2Никаких, кроме HSM (hardware security module). Поэтому я и настоятельно рекомендую хеширование.
ZnOFF
27.05.2022 10:37+1Шифрование может потребоваться для авторизации в "сторонних" ресурсах. В случае, если там на вход подать можно только сам пароль, а не хэш.
HappyGroundhog
27.05.2022 12:42Это уже боль какая-то. Т.е. на стороннем ресурсе у пользователя такой же пароль? Зачем? Не проще ли сделать SSO? Хотя реализации всякие бываю, согласен.
ZnOFF
27.05.2022 12:54Например, ваш сервис умеет импортировать данные из стороннего API(написаного 10 лет назад), в котором для авторизации требуется пароль в открытом виде. Вам придётся его сохранить без выполнения хэширования. Иногда шифрование пароля необходимо и хэшированием не заменяется.
HappyGroundhog
27.05.2022 13:10+1Когда тебе нужно ходить в сторонний сервис с кредами это понятно, там может не быть выбора.
Я же говорил про хеширование в контексте формы логина/аутентификации.
funca
27.05.2022 08:53+3Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - это логин (а лучше хэш логина). Пароль - нельзя. Было уже множество громких ининцидентов
Примеры взломов можно глянуть тут и тут
Почитайте по второй ссылке внимательнее. Вопросы безопасности информационных систем это проблема уровня организации. Аудит и логирование: кто, когда и что делал в вашей системе - одно из требований регуляторов. Все это в том или ином виде отражено в стандарте (ISO/IEC 27001 - Information security management systems - вообще полезное чтиво). Т.е. независимо от того, джуниор вы или синьер, если к вам приходят с такого рода вопросами, а не детальной спецификацией (с какой целью, в каких случаях, куда, что и в каком виде должно логироваться), то можете сразу надевать парик и делать себе большой красный нос, чтобы адекватно смотреться в компании этих клоунов. ;)
Bone
27.05.2022 08:54+4Я бы позволил пользователю иметь пароль любой сложности, если это не какой-то супер критичный сервис, типа банковского приложения.
RomanistHere
27.05.2022 12:25+1Тру. Я делал собственный сервис, в котором регистрация особо много чего не даёт, поэтому смысла заставлять придумывать челов пароли с @$(№! никакого нет. Кому важна безопасность, всё равно используют менеджеры паролей. Просто бахнул минимум в 7 символов.
ReadOnlySadUser
27.05.2022 09:28+11О, а я оказывается Senior веб-разработки :) Хотя я в жизни ни одной странички не написал :)
Nigrimmist Автор
27.05.2022 17:03+1Поздравляю, вы приняты в профессиональные формошлёпы! Конечно, главные принципы-то плюс минус везде похожие, где есть клиент-серверное взаимодействие.
Zenj
27.05.2022 09:30+2Нужна ли валидация на сложность пароля или можно позволять пользователю иметь пароль любой сложности?
Если это личный сервис - нет, максимум - уведомление пользователю, что он использует слабый пароль. А на самом деле, политика паролей должна быть прописана в ТЗ или в требованиях службы безопасности, разработчик это решать не должен. ИМХО.
То же касается и логирования.
Nigrimmist Автор
27.05.2022 17:05+1Решать-то конечно не должен (за редким исключением, если он и есть овнер сервиса), однако понимать это полезно каждому разработчику.
Nialpe
27.05.2022 09:46+4Половина пунктов в статье из суровой реальности, когда заказчик хочет, стадия бизнес-анализ пропускается, а разработчик по сути человек-оркестр. Проходил такой этап, знакомая история. Но... Если все-таки речь идет о найме именно разработчика, специалиста в своей области, то вопрос я бы перефразировал: "Вас попросили принять участие в бизнес-анализе, создании ТЗ на разработку и спецификации формы аутентификации для сферического сайта в вакууме. Что по вашему мнение следует уточнить, учесть и какие предложения по реализации технической части у вас имеются?"
vesper-bot
27.05.2022 10:20+6Эквивалент 128 битного симметричного ключа равен 2048 ассимметричного.
С какого перепугу? Я ещё понимаю, если разговор о конкретных алгоритмах, т.е. 2048bit RSA и 128bit ECDSA/Ed25519, и то вопрос открытый, почему это перебирать 2048 или на сколько там сократили атаку на RSA математики бит (сколько помню, и близко не до 128) легче, чем 128?
Ionenice
27.05.2022 10:36+1Безусловно, запрос должен посылаться с CSRF токеном. Это гарантирует отправку формы тем же клиентом, что её и отобразил.
Не гарантирует
RomanistHere
27.05.2022 12:27+2думаю что автор заменил словом гарантирует "увеличивает вероятность настолько, что можно не париться об этом до момента, как кто-то серьёзный не захочет ломануть".
name_taken
27.05.2022 10:37А вариант «не изобретать свой велосипед и использовать openid от внешнего провайдера», это какой уровень?
warzes123
27.05.2022 10:37>>Нужно ли скрывать вводимый пароль на странице?
А меня, как пользователя, бесят эти звездочки. (и дурацкая кнопка показа, которая тут же скрывает, когда пытаешься исправить или добавить символы)
>>эти пароли в текстовых файлах на рабочих столах, т.к. запомнить их нереально
Я так от своих репозиториев в гитхабе храню ключ))) Извините, я не способен запомнить 40 случайных букв (а по хорошему надо еще и на каждый репо свой). Они почему-то запретили комитить по паролю учетки в гитхабе, только по ключуquwy
28.05.2022 03:25А меня, как пользователя, бесят эти звездочки
Некоторые гении безопасности маскируют даже поля ввода одноразовых ключей двух-факторной авторизации. Вот где маразм.
gwer
27.05.2022 11:19+1Так же можно упомянуть про двойное хеширование и метод цепочек - внутрянку знать не обязательно, просто знать, что методы есть.
А какая связь между формой аутентификации и методами разрешения коллизий в хэш-таблицах? При сохранении пароля нужно произвести брутфорс и рядом с хэшом в связный список положить все пароли, которые под этот хэш попадают?
makar_crypt
27.05.2022 11:21+4Что вы привязались к этому шифрования )))
Где вопросы про web3 ? авторизацию кошельков без логинов паролей? , где мультисиг кошельки? где входы по Ferra, G,Y,F и прочим? Как должна выгладить структура\архитектура при той же web3 авторизации?
Статья как будто человека помешенного на велосипедном шифровании
VertiBird
27.05.2022 12:24+1Вообще статья крутая, но раздел по Rate limiter это что-то... "тема сабжа", "аффектать", вай сач мач?
olku
27.05.2022 12:27+4К какому уровню квалификации относится вопрос "давайте сначала обсудим модель угроз"?
tbp2k5
27.05.2022 12:31+5Остановился на «Правильнее делать используя метод POST. Ничего вам не мешает сделать это любым другим методом»:
GETом слать нельзя! — без вариантов и шаканий ножкой. Потом выгребаются все пароли из разных логов squid/nginx/apache и прочих…
int03e
27.05.2022 13:47+1Ну, технически ничего не мешает прикрепить body к GET запросу. Вроде как спецификация HTTP это не запрещает :)
Rsa97
27.05.2022 13:58+2Спецификация не запрещает, но семантика такого запроса не определена и он может быть отвергнут сервером [и/или прокси].
httpwg.org/specs/rfc7231.html#GET
tbp2k5
27.05.2022 14:06Проще процитировать RFC7231 section 4.3.1:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Я не вижу как стандартными средствами HTML/JavaScript «прикрепить body к GET запросу» но допустим он существует: вы притулили клиенту Аплет/ActiveX или еще через какую экзотику (свой клиент/аппликация) — в любом случае это колхоз как на клиентской так и на серверной стороне — ради чего?int03e
28.05.2022 12:44+1Конечно, так делать не стоит. Я просто вспомнил такой забавный факт, что, теоретически, такое возможно.
quwy
28.05.2022 03:33+1GET-запрос просто не должен изменять состояние сервера (кроме теневых изменений, типа записи в журналы). А авторизация пользователя -- это изменение.
Была уже тут статья про особо офигевший браузер от не менее офигевшего поискового гиганта, который сливал абсолютно все посещенные URL-ы. А потом их сервер еще и шарился по этим URL-ам как у себя дома, активируя таким образом весьма чувствительные экшены, повешенные на GET-запросы.
Bronx
28.05.2022 03:43Даже если ни прокси ни сервер не отвергнут такой запрос, не факт, что GET вообще до сервера дойдёт, ибо кэширование.
BugM
28.05.2022 04:03+1У всех нормальных апишек в ответе стоит no-cache. Иначе можно очень интересные результаты внезапно получать.
Кеши лучше на стороне аппликейшен серверов делать. Ответить из памяти или из соседнего Редиса не стоит ничего. Работает надежно и предсказуемо.
Bronx
29.05.2022 07:02У меня был опыт, когда мой небольшой тестовый сайт посадили за прокси, настроенный админом так, что ему было пофиг на все эти no-cache, так что я бы не особо надеялся.
BugM
29.05.2022 13:49Выглядит как проблема настройки прокси сервера.
Если это админ из вашей конторы, то на него заводится тикет с максимальным приоритетом и быстро эскалируется до вашего и его руководства если он оперативно не чинит.
Если это где-то в интернете, то пользователю сообщается о неверных настройках его сети и забывается навсегда.
Бывает всякое. Да почти что угодно бывает. Надо со своей стороны сделать хорошо, и дальше только проверять что по пути никто не сломал.
zloun
28.05.2022 12:11По моему браузер отбрасывает тело запроса, если его тип GET и уже на сервер этот запрос приходит без него. А вот через какой-нибудь postman можно отправить GET запрос с body.
Neusser
27.05.2022 12:52+1Что делать в случае коллизий паролей при хэшировании?
Ну так и что делать? В "ответе" ответ не содержится, только рассуждения о том, что такое маловероятно.
Rsa97
27.05.2022 12:56+2Полагаю, ничего не делать. Идентификация пользователя идёт по логину, пароль служит только для аутентификации и работает в сочетании с логином.
aigoncharov
27.05.2022 15:10+1Более того, я не очень представляю как можно проверить, есть ли коллизия с кем-то ещё в БД. Да и зачем?
Nbx
27.05.2022 17:50Для инженера, наверное самое важный пункт будет «посмотреть на текущий стандарт». Зачем придумывать своё, если уже за вас кто-то всё придумал и продумал. Например стандарты реализации систем безопасности от NIST.
Если ваш сервис будет работать с государственными заказчиками, то это будет не просто рекомендация, а требование.
Потом следует уточнить для кого мы делаем эту систему и какие последствия от утери доступа. Это должно быть главным в дизайне системы.
Ну а если чисто для интервью, то можно наверное включить ещё несколько вопросов.
— Имеет ли смысл блокировать аккаунт при нескольких неудачных попытках?
Сущесвует атака, которая подобным образом не даёт настоящему владельцу аккаунта зайти и использовать сервис. Иногда это может быть не менее вредно чем утеря аккаунта.
— Сложность пароля
Существуют огромные базы сломанных, реально существующих паролей и есть системы требующие чтобы вводимый пароль был не в этой базе. Правила сложности пароля гораздо менее надёжны, чем простая проверка по подобной базе.
— Передача по https
Во многих компаниях на компьютеры пользователей ставят доверенный корневой сертификат и это позволяет с лёгкостью реализовать MitM, так что иногда можно и дополнительное шифрование реализовать и не надеятся только на https. Такое дополнительное security-through-obscurity, ленивых это отсечёт.
Кстати можно ещё спросить что это такое «security through obscurity».
— Описать протокол востанавления утерянного пароля
Все ухищрения с 2FA и сложностями паролей ничего не значат если можно сделать восстановление пароля и фактора без кросс проверки, просто доступом к емайлу или смс.
— Социальная инженерия и следование организационным протоколам
Например иметь возможность админу менять пользовательский пароль, открывает массу интересных опций.Nigrimmist Автор
27.05.2022 20:18> Существуют огромные базы сломанных, реально существующих паролей
Интересно, такое API кто-то предоставляет сейчас на рынке?
Да, про соц инженерию и восстановление - хорошие поинты. Кроссчек - вы имеете ввиду, что сначала должен прислаться емейл со ссылкой на изменение пароля?
Nbx
27.05.2022 20:44+2Интересно, такое API кто-то предоставляет сейчас на рынке?
Наверное, точно есть UI для проверок, но более менее нагруженый вариант там скорее всего не пройдёт.
Сделайте своё — может выстрелит, будет копеечка падать.Кроссчек — вы имеете ввиду, что сначала должен прислаться емейл со ссылкой на изменение пароля?
Что для восстановления 2FA по емайл/смс слать ссылку на востановление, а по ссылке просить пароль перед восстановлением.
Для восстановления пароля по емайл/смс слать ссылку на востановление, а по ссылке просить 2FA перед восстановлением.
Видел системы которые полагались только на надёжность почты.
Можно ещё security questions в процесс включить, но тут уж совсем плохо с точки зрения безопасности. Где то читал про исследование что по открытым источникам можно достаточно легко вычислить ответы на подобные вопросы.
Конечно как уже говорилось, что защита должна быть адекватна угрозе. Для простых приложений где нету денег и только публичные (или некритичные) данные, конечно смысла городить огород нету.
izirayd
27.05.2022 20:38Ничего нового в статье нет, ожидал увидеть целый блок посвящённый защите от ботов и авторега. Что если кто-то напишет систему авторега и сделает 10тыс. аккаунтов? Как защититься? А если сделает 100к аккаунтов? Есть целые решения для обхода десятка видов капч, получить сотни тысяч ip`шников для проксей не проблема.
Nbx
27.05.2022 20:47получить сотни тысяч ip`шников для проксей не проблема.
С точки зрения IPv4 более менее понятно как это решать, а интересно как решаются проблемы для IPv6? Там же реально непаханное поле, если у вас сервис выставлен через IPv6, это может быть слабым местом.
un1t
27.05.2022 21:20+1Токены для защиты от CSRF больше не нужены, у cookie есть атрибут SameSite, он решает эту проблему.
Nbx
27.05.2022 21:38+1Мне кажется что CSRF токены (как и cookie с атрибутом SameSite) с _точки зрения формы аутентификации_ проблем не решают.
Если вы смогли обмануть пользователя и заставить его ввести имя и пароль (и 2FA код если он есть) на своём сайте (а он думает что аутентифицируется на другом сайте), то все проблемы уже случились и поздно пить боржоми.
CSRF это в основном про то чтобы сделать защиту от действий когда пользователь уже аутентифицирован на атакуемом сайте.Nigrimmist Автор
27.05.2022 23:59Да, пожалуй соглашусь. Вектор атаки до авторизации не очень ясен в рамках csrf, кроме описанной вами. Подумалось - а интересная идея "подставить" пользователя, опубликовав что-то запрещенное с его айпишника. Но это если креды знаешь, конечно.
Nigrimmist Автор
27.05.2022 23:56Резонно, принято. Правда в старых браузерах оно не работает, но сколько их там осталось... Добавлю в статью, спасибо.
metj
27.05.2022 23:18В вопросы сеньору/сеньору+ можно добавить про способы аутентификации без передачи по сети пароля плейнтекстом (PAKE/SRP). Весьма интересная тема.
Nbx
27.05.2022 23:35Если обсуждается вопрос с точки зрения веб формы, то тут при присутствии MitM, PAKE/SRP проблему не особенно решит.
MitM сможет модифицировать получаемую страницу, внедрив туда простой код который повесит на нажатие кнопок и легко перехватит пароль на другом уровне. А без MitM плейнтекст не сильно навредит, все и так по https гоняют траффик.
Для api/мобильных приложений это уже не сделать и тут PAKE/SRP конечно позволит избежать перехвата.
nehrung
27.05.2022 23:32Я не особо копенгаген в данной тематике, но тем не менее заметил, что тема входа пользователя в систему — частая рутинная процедура — рассмотрена автором достаточно подробно. А вот более редкую, практически одноразовую для конкретного пользователя процедуру — регистрацию — автор не затронул совсем. А лично меня она интересует больше, поскольку всё больше сервисов при регистрации требуют с меня ввода личных данных, чего мне категорически хотелось бы избежать.
Вот конкретные вопросы. В дуровском Телеграме накоплена огромная база пользовательских номеров телефонов, полученных при регистрациях. Каждый такой номер, будучи аналогом удостоверения личности, позволяет узнать об этой личности всё. Я понимаю, что сам Дуров — приличный человек (это постулат), но нет гарантии, что в его команде не угнездился тот, кого в статье и комментариях называют «плохим человеком», и он имеет доступ к этой базе.
1. Значит ли это, что процедура регистрации в Телеграме с точки зрения гарантий анонимности и приватности построена неправильно?
2. Возможно ли сделать её правильно? Тут, конечно, надо сначала формализовать, а как правильно-то? Но я знаю ответ: вот в видеомессенджере Tox меня зарегистрировали без всяких телефонов, т.е. такая процедура возможна. И это при том, что даже старый добрый Скайп по прошествии лет начал время от времени закидывать мне удочку — может, сообщите нам свой номер телефона? Ах, не хотите? Ну ладно…
3. Если регистрация в Телеграме скомпрометирована, то почему миллиардам его пользователей это пофик?
4. Как с этим засильем бороться с пользовательской стороны? Не регистрироваться там, где просят номер тлф? Но ведь просто посмеются, невзирая даже на объяснения типа «у меня нет мобилы!» (кстати, вполне релевантный ответ).Nbx
27.05.2022 23:59Значит ли это, что процедура регистрации в Телеграме с точки зрения гарантий анонимности и приватности построена неправильно?
На сколько я понимаю это требование удобства и функциональности, т.е. привязка по номеру телефона даёт преимущество с точки удобства пользования по сравнению со стандартной моделью имя пользователя/пароль.Если регистрация в Телеграме скомпрометирована, то почему миллиардам его пользователей это пофик?
Она не скомпрометирована, а соответствует тем требованиям которые к ней были предоставлены.Как с этим засильем бороться с пользовательской стороны? Не регистрироваться там, где просят номер тлф?
Виртуальный номер телефона. Есть масса сервисов где можно получить номер телефона, даже бесплатно (или за очень небольшие деньги) и в почти что любой стране. В конце концов просто купив левые симки, если так это парит.
Недавно была статья как заметать следы по максимуму. Это довольно муторно и дорого и что самое важное очень ненадёжно. Небольшой провал и всю вашу историю размотают без проблем, легко соотнесут виртуалов и реальных людей.
Надо заморачиваться только там где это реально необходимо и сработает в основном против небольших коммерческих структур либо на очень коротких промежутках времени.
В остально простые правила цифровой гигиены будут достаточны и принять как объективную реальность что всё что может утечь в конце концов утекёт и скорее всего уже утекло.
Nigrimmist Автор
28.05.2022 00:21Ну скажем так - параноики Телеграмом не пользуются :) Как и смартфонами, как и .... ах да, где та грань-то? :) Конечно же те, кто не хочет вводить свой телефон (и я их понимаю) - приобретают просто левые симки. Но суть такова, что если вас захотят отследить - вас отследят. Рано или поздно. Вопрос лишь в том, насколько оппоненту это нужно, тут и идёт игра "перетяни канат". Мне кажется, анонимность в наше время это просто миф. Можно обойти 99.9% кейсов по деанонимизации, но оставшийся процент, который входит в "эдж кейз" всё равно вас "убьёт", просто шанс этого очень мал. Т.к. стойкость анонимизации в самом слабом звене, а этих звеньев прилично - помнить обо всех нормальному человеку просто нереально. Только, если от этого зависит ваша жизнь и вы точно знаете, что если дадите осечку - вашей жизни будет угрожать опасность в том или ином виде. Так что тут вопрос меры анонимизации.
Вспоминаю отчёт агента в расследование ФБР о поимке владельца SilkRoad и на чём он "провалился" - хочется просто улыбнуться.
omlin
28.05.2022 00:10+1Вопросник очень неполный, там на самом деле гораздо больше нюансов. Например, только по теме mfa можно говорить, наверное, час: как защищаться от leak-ов БД mfa-токенов, как оптимизировать mfa чтобы не надо было посылать платную смс каждый раз, вопросы accessibility, как защищаться от социальной инженерии, что делать если пользователь потерял свой mfa и recovery codes тоже, может ли смс считаться безопасным методом mfa и т д. и т.п. Очень обширная тема.
Но главное не это: по моему опыту, знание аутентификации плохо коррелирует с определением джун/мид/сениор. Я раньше тоже задавал кучу вопросов по безопасности на каждом собеседовании (поскольку сам очень много знаю по теме, приходилось например участвовать в защите крупных систем от ботнет-атак в качестве техлида), но быстро понял, что это плохо работает. И в последнее время сомневаюсь, что это подходит даже как "один из вопросов".
Я вполне могу представить классного сениора, который с этой темой не работал совсем, и как следствие, он её будет знать на уровне джуна. И наоборот, джун, который был в команде которая делала аутентификацию, и он будет знать все эти вещи на хорошем уровне.
Системы аутентификации и авторизации часто либо используются готовые, либо в серьезных конторах типа юникорнов и фаанг - пишутся отдельной командой. Условно у вас есть 50 команд в продукте, и только у одной из них есть серьёзный опыт работы с аутентификацией. Все остальные знают тему шапочно - но это не означает, что они плохие программисты.
Готовые системы тоже не стоит недооценивать, особенно от фаанг. Они сделаны очень хорошо и продуманы до мелочей. Лучше использовать их, чем написать велосипед и завтра получить очередной leak персональных данных людей, которые вам доверились. Плюс, как вы правильно заметили в статье, всегда есть вариант с oidc/saml.
Резюмируя, я бы не стал спрашивать эти вопросы на собеседовании кроме следующих случаев:
когда нанимаете в команду аутентификации
когда нанимаете архитектора по безопасности
когда кандидат заявляет, что знает эту тему хорошо, тогда стоит проверить, насколько хорошо :)
Nigrimmist Автор
28.05.2022 00:31Да, тут на каждый пункт по статье можно, да и самих пунктов еще накидать, но уж на сколько хватило знаний и времени :) В целом, со всем согласен что написали.
XenRE
28.05.2022 01:07Что по соли — она может быть одна для всех пользователей
Фигня какая-то, и это сеньор левел? Соль нужна для того, чтобы одинаковые пароли давали разные хеши и нужно было брутить каждый хеш персонально, а не всю базу разом. Если соль одинаковая для всех юзеров — она бесполезна.Nigrimmist Автор
28.05.2022 12:32Сеньор должен отличать виды солений и перчений, к этому и вопрос был. Такая соль не бесполезна - она а) уменьшает шанс брутфорса и б) убирает возможность использование радужных таблиц
Rampages
28.05.2022 01:16Порой думая о безопасности забывают о том что у пользователя может быть несколько логинов или учетных записей и вспомнить с какой учетки заходил сложно, порой думаешь по-любому логинился через Google, тыкаешь "зайти через Google" и сайт создают тебе еще одну учетку с тем же самым email'ом... Некоторые сайты принудительно тебя пытаются залогинить через номер телефона и других вариантов нет, а если вдруг ты не угадал номер телефона, они создают учетную запись с новым номером телефона, хотя ты хотел войти в старую и поменять в ней номер телефона.
Безопасность это хорошо, но пожалуйста не забывайте о пользователях, которые ошибаются при вводе и о пользователях, которым необходимо вспомнить не только пароль, но и логин.
Также очень раздражают все эти в духе Apple и Microsoft 3 личных вопроса для определения личности ("город в котором познакомились ваши родители", "имя первого питомца" и так далее), неужели они так надежны?
Еще заметил, что некоторые делают супер короткие сессии, чтобы вот прям отвлекся на 10 минут, а теперь заново логинься, допускаю, что есть системы, которым это необходимо, но порой можно встретить там где это толком и не нужно.
Также некоторые не продумывают способы восстановления пароля, в случае если в базе есть 2 пользователя с одинаковым email и номеров телефона :) либо исключайте возможность создания таких записей, либо что-то придумайте (тот же Microsoft Live однажды не давал мне восстановить пароль, точнее он пытался поменять пароль на другом аккаунте, так как у меня 2 аккаунта с одинаковой почтой было )
Riot Games например сама поменяла логины пользователям и не дает менять их на другие, теперь у меня очень сложный логин, а если зайти в Desktop приложение, то в мобильном приходится заново входить, короче стремный ход с их стороны. Приходится каждый раз искать старое письмо о смене логина и копипастить его.
Amazon уже давно не может мне отправить 2FA на мобильный, связано это с событиями в феврале или нет не понятно, хотел зайти поменять номер на турецкий, но не могу зайти так как не приходят ни звонки ни sms на мегафон, ни в Турции, ни в России, а ведь этот аккаунт у меня и к AWS привязан...
Кстати к вопросу о релокации и смене номеров телефонов и проблемам с получением SMS в других странах, мне кажется возможность настроить 2FA через почту или хотя бы через OTP/TOTP (Google Authenticator или Twilio Authy или любое другое приложение).
Еще кстати был прикол с AirBnB, при попытке зарегистрироваться со своим номером телефона внезапно выяснилось, что ранее уже у них был аккаунт с этим номером телефона, обращение в поддержку не помогло и номер телефона из чужой записи не удалили и создать учетную запись с моим номером телефона мне не дали :)
Схожая ситуация была у друга в Badoo, он смог зайти со своим номером телефона, но стал видеть переписку другого человека, при этом насколько я понял со слов друга, другой человек пользовался приложением и вел активную переписку :) То ли второй человек сменил номер телефона, но в приложении забыл поменять и продолжает пользоваться аккаунтом со старым номером, то ли еще какие-то проблемы.
Nigrimmist Автор
28.05.2022 12:24Да, идеальный аппы - в идеальных мирах, а по факту - грабли на граблях. Но в целом это реальна картина, что тут поделать Пока нет стандартизации и каждый пилит свой велосипед - будут пользователи колоться как ежи и есть этот кактус, ибо лучшего варианта на горизонте не видно.
kubk
28.05.2022 10:28+1Безусловно, запрос должен посылаться с CSRF токеном
Тут хорошо бы уточнить какой запрос. CSRF происходит когда браузер автоматически добавляет токен пользователя к запросу с помощью Cookie. В популярной ныне модели JWT браузер не добавляет токен автоматически в заголовки запроса (это делает приложение), поэтому защита от CSRF тут не нужна. JWT хранится в localStorage, информация в localStorage изолирована между доменами.
Nigrimmist Автор
28.05.2022 12:20Добавил в статью пометочку про JWT, но если так подумать - JWT и есть в том числе и CSRF токен, поэтому да, проблема решается сама собой. ????
andreishe
28.05.2022 11:25Что такое двухфакторная авторизация (2fa)
Сначала рассказываем про авторизацию и аутентификацию, потом пишем это. Ай-ай-ай.
DrinkFromTheCup
Вы знаете, я сначала на полном серьёзе хотел матерно вознегодовать на то, что даже схожих ситуаций случаться не должно никогда. Но потом вспомнил, как Facebook мне как-то выстрелил в лицо уведомлением "Вы ввели старый пароль! Он больше не подходит!" - и задумался...
Нужна ли - это же немного на другом уровне решаться должно, ни?
nronnie
Один заказчик как-то просил сделать на форме входа autocomplete логина (не тот, который на клиенте в браузере, а прямо из БД). Предложили ему бонусом сделать дополнительно такой же autocomplete пароля.
trawl
И как? Согласился?
abutorin
А в чем вопрос? Ну хранит лицекнига у себя хеши паролей который вы в ней устанавливали. Если соль для каждого пользователя своя, то никаких проблем нет.
DrinkFromTheCup
Поздравляю, Вы не middle. Ежели по статье судить.
Вопрос, как обычно, в "священной корове сесюрности" по имени Брутфорс.
Просто так взять и брякнуть потенциальному взломщику "да, этот чел когда-то использовал такой пароль", чтобы потенциальный взломщик пошёл примерять эту пару логин+пароль на другие сервисы, - это очень, очень, очень плохая практика.
Djeux
Очевидно что это вопрос баланса UX и безопасности. В котором мордокнига склонилась больше к UX.
По аналогии, это тоже самое что принудительно всех заставить настраивать 2FA, но при этом лишая себя львиной доли клиентов кто вообще не в курсе что это, и зачем им этот геморой.
DrinkFromTheCup
Очевидно, что это вопрос здравого смысла.
Помогать взломщику - плохо.
Говорить воткрытую взломщику, что он на верном пути, - ещё хуже.
К сожалению, Google (вроде бы уже), GitHub (не сразу, но к повальной 2FA там явно придут очень скоро), Yahoo (скоро) и прочие примазавшиеся к очередной хайповой теме - не в курсе этого : ( ( (
Djeux
Вопрос того, могут ли они себе это позволить. Условный гугл на данном этапе вполне, т.к. стал уже слишком крупным.
Гитхаб в каком-то смысле тоже, т.к. является практически незаменимым ресурсом в ИТ, плюс аудитория более подкована в вопросах безопасности.
Мордокнига, учитывая что и так буксует по части роста аудитории и финансов, такую вольность себе позволить не может.
Сам работал в конторе где уровень образования и подкованности аудитории оставлял желать лучшего, и вопросы которые могут повлиять на онбординг новых клиентов взвешивались очень сильно. И это при том что сфера деятельности была криптовалюты, где вопросы безопасности не на последнем месте.
Ionenice
Сообщение про старый пароль появляется при задании нового, разве нет? Если у «взломщика» есть доступ к созданию нового пароля, то уже как-то не важно. А использовать данные о старом пароле на других сервисах, после получения прямого доступа к одному из это звучит как что-то с вероятностью около нуля
DrinkFromTheCup
Вы упускаете из вида факт, что рано или поздно даже самому упёртому поборнику сесюрности надоест под каждый сайт делать новые пароли по схеме
Куда уж тут простым смертным. Простой смертный пользователь не хочет мудохаться с KeePass и тридцатидвухзначными паролями из символов пяти разных алфавитов.
Но поборник сесюрности, и правда, задумается о 2FA и неубиваемом устройстве для использования с 2FA, когда надоест эта возня.
А простой смертный будет фигачить везде один и тот же пароль. Да попроще. Просто потому, что он может.
По объективным причинам сколь либо крупной сверки баз паролей между достаточно крупными сервисами мы не дождёмся, а значит моя теория останется только теорией.
Но это не повод пренебрегать таким шансом сделать жизнь пользователя лучше, особенно если это укрепляет ситуацию с безопасностью в целом (и слегка упрощает разработку).
Ionenice
Но если плохой человек получил доступ к странице задания нового пароля какого-то смертного, то он уже знает дефолтный пароль этого смертного, и сообщение о старом, тут ещё ключевое слово «старом», пароле вряд-ли будет хоть как-то полезно ему.
Ну и простой смертный может не вписывать свой дефолтный пароль при создании аккаунтов, а просто использовать предложение браузера/телефона о новом сгенерированном пароле, это ведь ещё проще, чем записывать свой пароль?)
DrinkFromTheCup
См. "священная корова сесюрности №2" под названием Использование Учётки В Интернет-Кафе.
Serg10
Многие пользователи меняют пароль с qwerty на qwerty1, потом qwerty2 итд. Так что, зная первый, сами понимаете
Format-X22
Участвовал я когда-то в одной криптокомпании где при регистрации тебе чуть-чуть денег сыпали, для того чтобы ты мог в системе работать. Совсем копейку, но хакеры и до неё были жадные и засылали левых регистраций. Потом была поставлена защита с подтверждением по смс, но хакеры видимо обиделись и начали выжигать смски просто тысячами долларов, ведь каждая стоила денег. В итоге там поставили правило что чтобы зарегистрироваться - уже ты должен был отправить смс на специальный номер и только тогда то тебя и пускало. И потом как раз пришёл я и был в шоке - на столько сомнительно выглядящих регистраций я ещё не встречал.
abutorin
Ну тоесть вам не нравится уведомление именно что он "старый". Т.е. если заменить фразу на "Вы ввели недопустимый пароль" все будет ОК? Разрешать пользователю вводить старый пароль сомнительное удовольствие, тогда от смены пароля нет никакой пользы.
DrinkFromTheCup
Десять шагов вперёд, девять шагов назад.
В ситуации из вопроса из статьи пользователь пытается зарегистрироваться, что, помимо прочего, почему-то может стриггерить сверку его пароля с уже хранящимися в БД другими паролями.
При этом, мы ЕЩЁ НЕ ЗНАЕМ, доверенный это настоящий пользователь или нет.
Вопроса, кому и зачем взбрело проводить сверку, пока не касаемся. Мало ли. Тут уже попахивает YOBA-архитектурой - но это совсем out of scope нашей дискуссии.
Главное, что попытка регистрации - это по определению "хрен с горы", которому доверять нельзя. Совсем нельзя.
Мне не нравится, что на идущую с фронта операцию от неизвестного постороннего пользователя может вернуться привязанный к
конкретному пользователюконкретным данным в БД респонс.Такого. Не. Должно. Случаться. Никогда. Совсем.
Это почти равносильно выдаче возможности сдампить себе НЕЗАШИФРОВАННЫЙ список
паролейсверяемых данных из этой БД первому встречному.Я, чёрт побери, аналист-недоучка, которого как вышвырнули с баркаса за сомнительную профпригодность, так и не затащили обратно на борт. И то я понимаю как исходную абсурдность этой ситуации из вопроса из статьи, так и потенциальный вред от YOLO-подхода к её непосредственной реализации.
Да и для уже зарегистрированного пользователя сверка нового пароля со старым_и - это настолько неадекватно...
abutorin
В любом вопросе всегда важно соблюсти баланс "параноя" vs "удоство". Есть ситуации когда разрешать устанавливать какой-то пароль еще раз недопустима ,например база паролей утекла и нужно принудительно заставить пользователя его сменить.
DrinkFromTheCup
Мгм. А потом очередной сервис, основанный крупной компанией с вроде бы неплохими специалистами, начинает фигурировать в ломающих новостях.
Приведу ещё одну цитатку с купюрами из одного вполне приличного произведения. Рекомендую при случае приложиться к первоисточнику и подумоть. Предупреждаю, это очень времяёмко.
abutorin
Некоторые "никогда" делают другие "никогда" не актуальными. Например правило "никогда не использовать одинаковые пароли в разных сервисах" сводят на нет описанный изначально вами вектор атаки.
DrinkFromTheCup
Скажите, Вам действительно настолько сложно вынуть голову из коробки и попробовать представить, например, вариант, когда проверка на совпадение всё равно происходит, но целиком на бэкенде, а на фронт только отдаётся дженерик респонс (можно продолжать / нельзя продолжать)? Естественно, превращаемый на фронте в максимально обтекаемый и при этом информативный текст (с содержанием, которое по хорошему надо подбирать под конкретные потенциально способные случиться ситуации).
Или проще упереться рогом и таки оставить потенциальное слабое место в безопасности хранимых данных?
"Никогда", делающие другие "никогда" не актуальными - это отличный демагогический приём, которым можно оправдать всё, что угодно, были бы желание и гибкость позвоночника.
А уж уверенность, что гнуться должен пользователь под код, а не код под пользователя, ммммммммм... classic...
abutorin
Помнится когда-то, в одной стране, тоже требовали соблюдения своих "никогда" и сожгли за их нарушение Джордано Бруно на костре.
Все правила пишутся для конкретных условий. Эти конкретные условия могут быть известны только автору (к сожалению и авторы не всегда их понимают).
DrinkFromTheCup
Экскурсы в прошлое набили оскомину ещё в прошлом.
Попробуйте лучше экскурс в будущее. Хотя бы не будете выглядеть, как томный юноша, открывший таки учебник по Истории.
Источник цитаты тот же.
Говорю же, чудесное чтиво. Вам бы понравилось.
DrinkFromTheCup
Кстати, почему-то за минувшие пару суток мне насовали плохо прикрытых обвинений в чём попало, иногда даже обоснованных, - но никто не заметил, что я предлагаю НЕ сверять воткрытую с записями в БД емэйл ТОЖЕ!
Что выглядит, между прочим, куда более грубой ошибкой, заклевать за которую меня проще (но почему-то не ищут люди лёгких путей).
Ведь такая реализация может вызвать интересные сложности с попыткой донести до регистрирующегося пользователя мысль, что учётка в системе у него уже есть (читай: емэйл занят).
Но это нормально! И в обход такой проблемы построить форму логина очень даже можно!
Кое-где я даже уже видел, как эту проблему решали весьма элегантным и самоочевидным способом (заодно сэкономив на интерфейсе капелюху и убрав один из источников "заусенцев" в "воронке").
Увы, для того, чтобы допустить возможность построения регистрации/логина с учётом этого нюанса, нужно не просто вынуть голову из коробки. Нужно слегка изойти из себя.
Может, поэтому господа комменторезы как-то интуитивно сторонятся этой моей "ошибки". Слишком больно при отрыве от стереотипов будет.
Bronx
Чтобы поменять пароль, нужно залогиниться со старым. В таком случае слово «потенциальный» тут лишнее — аккаунт уже взломан.
DrinkFromTheCup
См. "священная корова сесюрности №2" под названием Использование Учётки В Интернет-Кафе.
Bronx
Слишком расплывчатый ответ. Опишите атаку.
DrinkFromTheCup
И proof of concept. И ТЗ на устранение. И неограниченную лицензию на использование. Да. И полцарства впридачу. B vfibyre to`/ Cfvb pyftnt? rfre./
Эта работа (если делать её по-настоящему) стоит денег.
И довольно неплохих, в зависимости от объекта атаки.
Bronx
Вы написали «см.», что означает «смотри». Куда смотреть, если вы ничего не написали, кроме некоей коровы, непонятно кем посчитанной? Ссылку хотя бы дайте, раз лень писать.
DrinkFromTheCup
Вы тогда не меня теребите - как видите, объясняю я очень плохо.
Вы просто гаркните куда-нибудь в пространство фразочку типа
Пояснятели сами прибегут, и всё объяснят, и кармой одарят... может быть...
(уж поверьте - прибегут. И одарят. Мне уже где-то на -7 одарили. Зато пояснили всё...)
BugM
Мы в 2022 году вроде как. Ставим вечную авторизационную куку, а пароль браузер сам запомнит.
Задание под звездочкой реализовать функцию "инвалидировать все другие сессии"
Bronx
Вроде мне каждое из ваших слов понятно, но что конкретно вы хотели ими сказать — непонятно, смысл ускользает. Слишком тонко и витиевато для моего усталого мозга.
vesper-bot
Интернет-кафе используют прокси-сервер с MitM, по факту пре-скомпрометированное соединение, так как MitM собирает все логи, включая POST, и плевать хотел на HTTPS. Атаки как таковой нет, считается, что использовать логин-пароль в интернет-кафе равно его компрометации.
BugM
Вы это сейчас серьезно? Любой современный браузер или мобильник будет орать и откажется показывать вам странички при попытке сделать такое.
Bronx
Я понимаю опасность компроментации существующего пароля. Я не понимаю, каким образом ответ «ваш пароль уже использовался» в форме смены пароля делает хуже, чем уже есть.
Megakazbek
А кто вам разрешит перебрать столько паролей, чтобы брутфорс через форму логина был хоть сколько-нибудь осмысленным занятием?
DrinkFromTheCup
Была бы точка входа. А как её заабьюзить - как-нибудь придумают.
Я не профессиональный сесюрщик, не могу сказать сходу, что тут можно придумать помимо долбежа ботнетом и поиска не прикрытых рекапчей/ЦДНом/чортом лысым APIобразных точек входа, пригодных для произведения брутфорса.
Я просто против идиотизма в производстве.
Megakazbek
Но если вы пойдёте другим путём, то и предупреждения о старом пароле тоже не получите.
DrinkFromTheCup
А нужно ли предупреждение именно о старом пароле?
Нам важно проинформировать пользователя о том, что пароль должен быть другим. В конце концов, если заявить клиенту прямо, что "это уже было", - он действительно просто поменяет циферку в конце пароля. И получится фигня, как в комментарии @ALogachev чуть ниже.
Каким именно другим должен быть пароль - нужно напомнить обо всех нюансах оптом.
И нам с нашей стороны не надо маяться дурью, отправляя уникальный респонс на каждый тип фэйла.
И пользователю не надо раз за разом материться, переделывая пароль под новые всплывшие нюансы.
Если нюансов оказалось слишком много либо среди них таки затесалась дичь вида "не должен совпадать с последними десятью паролями даже частично" (и такое видал...) - заказчику фичи нужно... хмммм... как бы это поделикатнее сказать, к психоаналитику наведаться, что ли. Потому, что за такими методами сублимации, от которых страдают абсолютно непричастные люди, причём массово, обычно стоит какая-то очень тяжёлая травма, которую не повредило бы наконец проработать и перестать усложнять всем (включая собственно заказчика фичи) жизнь.
ALogachev
Помню, в филиале серьезного немецкого ритейлера в политиках надо было менять пароль каждый месяц и он не должен был повторяться в течении года… в результате у 99% работников пароль был «мой пароль»+«номер месяца»…
Nigrimmist Автор
Не раз на личном опыте видел что именно так и работает. Только не номер месяца, а кол-во последних символов просто увеличивалось на +1. Т.е. с "123" на "1233" и так далее :)
loltrol
Если бы меня спросили, как сделать форму логина, я бы ответил: "Какая форма логина?! Только биометрический токен с анализом ДНК и психической активности, что бы случайно не пропустить принужденную аутентификацию третьими лицами".
А без сарказма, аудитория сервиса определяет, что и как показывать. Если моей маме сказать "ваш новый пароль недопустим" без точной причины, она просто отложит facebook на N недель, пока я не приеду в гости и не напишу ей на бумажке новый пароль. А умножить эти N недель на огромное количество таких пользователей, мы получим миллиарды пропущенных кликов на рекламу и потерю прибыли.
Поздравляю, вы технический специалист, а не миллиардер-владелец facebook. И с точки зрения безопасности вы можете быть 100% правым, но прибыль владельца и ЗП junior/middle/senior формошлепщика, который в этом бизнесе работает, зачастую зависит от красоты и удобства в значительно большей мере чем от секьюрности и других маловажных технических факторов.
Nigrimmist Автор
Абсолютно согласен, довольно тонкие материи. Но ФБ себе такое позволить может (хоть я и осуждаю). Скажу больше - даже когда пишут причину, там иногда такой листинг требований, что проще не регистрироваться вовсе. А потом почему-то клиенты не идут, рынок маленький - нужно больше вкинуть в маркетинг. Радует, что всё же это больше исключения среди хороших сервисов, чем правило.
DrinkFromTheCup
Вы знаете, мне совершенно лень переписывать заново этот комментарий. Оставлю ссылку и подкреплю ещё свежим рассуждением и парой кросс-ссылок.
Вообще-то, если реальное обсуждение реальной задачи на функционал дошло до такой степени разброда, - то я в первую очередь баран. Потому, что всё на самом деле уже должно быть решено и вопрос ТОЛЬКО в реализации.
Уууууууу, секъюрность теперь маловажный фактор... Я понимаю, что штраф за утечку личных данных не Вам платить. Но это не повод подталкивать тех, кому ВОЗМОЖНО придётся платить этот штраф, к такому опасному поведению.
Формошлёпайте наздоровье. Отлично. Кто-то же должен покупать подписку на Тильду. Но я бы предпочёл, чтобы серьёзных проектов Вы не касались.
У трезвых людей зарплата непосредственно создающих продукт персон зависит не от перечисленных Вами факторов.
Браво. Вы убедили меня в том, чего я и так придерживался.
Я бы так не смог.
Vamp
Эта "очень плохая" практика зафиксирована в международном стандарте PCI DSS:
DrinkFromTheCup
В этом?
Вы понимаете, что попытаться натянуть стандарт для платилок на форму авторизации/регистрации - это... наивно?
Anrikigai
При входе во вспомогательные аккаунты после смены пароля вполне можно забыться. И, когда Google пишет "вы поменяли пароль 2 месяца назад", это отрезвляет и помогает не вводить повторно тот же самый пароль (вдруг ошибся при вводе), а ввести "новый".
DrinkFromTheCup
О. Ещё лучше. Не только брякнуть "да, когда-то эта пара логин+пароль была валидной", но и указать, когда именно перестала быть валидной.
Чесслово, я не могу сказать, что хуже, - принудительный 2FA вместо паролей или Ваш вариант.
Anrikigai
Смотря кому лучше. Всегда есть конфликт интересов. Как минимум, безопасность vs удобство.
Для важного аккаунта у меня 2FA включен. Для временного (дурацкие регистрации и прочее) 2FA абсолютно не нужен. А вот подсказка очень кстати.
Я, конечно, понимаю вектор атаки:
злоумышленник подбирал пароль к мое гугловой учетке
узнал, что какое-то время назад был такой пароль (тут, конечно, большой вопрос, что много паролей он не проверит, и подсказка мне как раз нужна, чтобы самому не заблокироваться)
пошел с этим паролем на другие ресурсы
Теоретически можно нафантазировать, что условно брутфорс на гуггле, авито и прочем можно поделить на кусочки, чтобы проверять только часть паролей. Только вот ежели на сайте нет локаута после нескольких попыток, не вижу большой разницы, проверять ли 2 миллиона паролей или только 1. А если локауты есть, вероятность с трех попыток подобрать брутфорсом "пароль, действоваший пару месяцев назад и который прекрасно подойдет к другому ресурсу сейчас" крайне мала.
100% безпасности не бывает. А пытаться из трех девяток сделать 5 девяток на не сильно критичном ресурсе типа форума/соцсети (мы же не о банке с MFA говорим) путем усложнения жизни обычному пользователю, тем более "ради его безопасности на других ресурсах" - мне это кажется не сильно целесообразным.
Хотя, разумеется, тоже можно возразить: "Вот Гугл помог подобрать пароль к Хабру, от вашего имени запостили экстремистский материал..."
DrinkFromTheCup
Я там где-то в соседней ветке комментариев мягко намекнул на ботнеты.
Наличие локаута на неудачное количество попыток ничего не меняет потому, что даже у Флагманов Индустрии оно написано в лучшем случае ногами. Без оглядки даже на решаемый этим функционалом круг задач.
У тех же параноиков из Battlestate Games реализована какая-то чеканутая система инкрементальной продолжительности локаута чуть ли не с первой же неудачной попытки.
От которой страдает, в общем-то, только конечный пользователь, который с трёх неудачных попыток может улететь в отмокание чуть ли не на сутки (за два года так и не понял, от чего это зависит).
Потому, что ботнету наплевать, куда долбить из-под какого TOR'а. Ботнету неведома усталость.
И ихней антибрутфорс системе, в общем-то, тоже наплевать, что в учётку кто-то ломится. Показать на фронте беззубое "ой, подождите полчасика" - это всё, на что хватило у них здравого смысла.
И техподдержке, я так понял, наплевать - я фидбэк ещё в 2019 году, что ли, отгружал на эту тему. Адекватного ответа не дождался.
А конечному пользователю не наплевать на то, что какой-то невменяемый скрипт упёрся рогом. Потому, что уплочено RUB4999 - и было бы неплохо, чтобы уплоченное начало приносить какой-то фан. А не лишние трудности от какого-то сесюрщика, не удовлетворённого в неустановленной сфере.
BugM
Точно?
Готовы показать или хотя бы описать работающую систему перебора значимого (>миллиона) числа паролей к гугл или хотя бы яндекс аккаунту за разумное время?
DrinkFromTheCup
Окей, окей, вы с @Bronx меня уговорили. Я проиграл этот раунд турнира по лени. Я не поленился загуглить. Потому, что, alas, писать даже концепт на ТАКОЕ я бесплатно НЕ собираюсь.
Но для прикидки порядка мощности потенциальной атаки И структуры начать, я думаю, можно с https://habr.com/ru/company/yandex/blog/577026/ .
DDoS - это, конечно, не брутфорс, и в зависимости от того, как именно будет обходиться и/или вводиться в заблуждение антибрутфорс система (и будет ли - если подойти к делу творчески, можно кое-где срезать пару углов), пересчёт потенциальной мощности (DDoS) в реально возможную (собственно брутфорс) можно делать ооооочень по-разному.
Я, пожалуй, возьму итоговую цифру с того же потолка, что и Вы, даже не отвлекаясь на поправку на использование словарей и всего такого.
Я считаю, что ботнет из статьи УЖЕ способен выудить значимое (>миллион) число паролей (sci!) за разумное время (скажем, месяц) с наиминимальнейшими правками кода.
А интересующие Вас детали архитектуры, полагаю, Вы можете получить из освещающих тот инцидент более детальных более профессиональных статей, а не из моей писанины.
Видите, и этот раунд турнира по лени я тоже проиграл.
BugM
Задудосить в теории можно всех и всё. Исключение разве что тир1 провайдеры. Тут деньги решают. Мозги могут только количество денег при неизменном железе менять.
Брутфорс паролей у "Флагманов Индустрии" это совсем другое дело. Если они не 100% прикрыты от брутфорса это детская ошибка их разработчиков систем авторизации и их безопасников одновременно. Я в такие ошибки таких людей уже много лет как не верю.