Comments 211
Нужно ли при неудачной попытке регистрации писать, что такой пароль уже существует в системе?
Вы знаете, я сначала на полном серьёзе хотел матерно вознегодовать на то, что даже схожих ситуаций случаться не должно никогда. Но потом вспомнил, как Facebook мне как-то выстрелил в лицо уведомлением "Вы ввели старый пароль! Он больше не подходит!" - и задумался...
Что такое двухфакторная авторизация (2fa) и нужна ли?
Нужна ли - это же немного на другом уровне решаться должно, ни?
Один заказчик как-то просил сделать на форме входа autocomplete логина (не тот, который на клиенте в браузере, а прямо из БД). Предложили ему бонусом сделать дополнительно такой же autocomplete пароля.
"Вы ввели старый пароль! Он больше не подходит!" - и задумался...
А в чем вопрос? Ну хранит лицекнига у себя хеши паролей который вы в ней устанавливали. Если соль для каждого пользователя своя, то никаких проблем нет.
Поздравляю, Вы не middle. Ежели по статье судить.
Вопрос, как обычно, в "священной корове сесюрности" по имени Брутфорс.
Просто так взять и брякнуть потенциальному взломщику "да, этот чел когда-то использовал такой пароль", чтобы потенциальный взломщик пошёл примерять эту пару логин+пароль на другие сервисы, - это очень, очень, очень плохая практика.
Очевидно что это вопрос баланса UX и безопасности. В котором мордокнига склонилась больше к UX.
По аналогии, это тоже самое что принудительно всех заставить настраивать 2FA, но при этом лишая себя львиной доли клиентов кто вообще не в курсе что это, и зачем им этот геморой.
Очевидно, что это вопрос здравого смысла.
Помогать взломщику - плохо.
Говорить воткрытую взломщику, что он на верном пути, - ещё хуже.
По аналогии, это тоже самое что принудительно всех заставить настраивать 2FA, но при этом лишая себя львиной доли клиентов кто вообще не в курсе что это, и зачем им этот геморой.
К сожалению, Google (вроде бы уже), GitHub (не сразу, но к повальной 2FA там явно придут очень скоро), Yahoo (скоро) и прочие примазавшиеся к очередной хайповой теме - не в курсе этого : ( ( (
Вопрос того, могут ли они себе это позволить. Условный гугл на данном этапе вполне, т.к. стал уже слишком крупным.
Гитхаб в каком-то смысле тоже, т.к. является практически незаменимым ресурсом в ИТ, плюс аудитория более подкована в вопросах безопасности.
Мордокнига, учитывая что и так буксует по части роста аудитории и финансов, такую вольность себе позволить не может.
Сам работал в конторе где уровень образования и подкованности аудитории оставлял желать лучшего, и вопросы которые могут повлиять на онбординг новых клиентов взвешивались очень сильно. И это при том что сфера деятельности была криптовалюты, где вопросы безопасности не на последнем месте.
Сообщение про старый пароль появляется при задании нового, разве нет? Если у «взломщика» есть доступ к созданию нового пароля, то уже как-то не важно. А использовать данные о старом пароле на других сервисах, после получения прямого доступа к одному из это звучит как что-то с вероятностью около нуля
А использовать данные о старом пароле на других сервисах, после получения прямого доступа к одному из это звучит как что-то с вероятностью около нуля
Вы упускаете из вида факт, что рано или поздно даже самому упёртому поборнику сесюрности надоест под каждый сайт делать новые пароли по схеме
Куда уж тут простым смертным. Простой смертный пользователь не хочет мудохаться с KeePass и тридцатидвухзначными паролями из символов пяти разных алфавитов.
Но поборник сесюрности, и правда, задумается о 2FA и неубиваемом устройстве для использования с 2FA, когда надоест эта возня.
А простой смертный будет фигачить везде один и тот же пароль. Да попроще. Просто потому, что он может.
По объективным причинам сколь либо крупной сверки баз паролей между достаточно крупными сервисами мы не дождёмся, а значит моя теория останется только теорией.
Но это не повод пренебрегать таким шансом сделать жизнь пользователя лучше, особенно если это укрепляет ситуацию с безопасностью в целом (и слегка упрощает разработку).
Но если плохой человек получил доступ к странице задания нового пароля какого-то смертного, то он уже знает дефолтный пароль этого смертного, и сообщение о старом, тут ещё ключевое слово «старом», пароле вряд-ли будет хоть как-то полезно ему.
Ну и простой смертный может не вписывать свой дефолтный пароль при создании аккаунтов, а просто использовать предложение браузера/телефона о новом сгенерированном пароле, это ведь ещё проще, чем записывать свой пароль?)
Но если плохой человек получил доступ к странице задания нового пароля какого-то смертного, то он уже знает дефолтный пароль этого смертного
См. "священная корова сесюрности №2" под названием Использование Учётки В Интернет-Кафе.
Многие пользователи меняют пароль с qwerty на qwerty1, потом qwerty2 итд. Так что, зная первый, сами понимаете
Участвовал я когда-то в одной криптокомпании где при регистрации тебе чуть-чуть денег сыпали, для того чтобы ты мог в системе работать. Совсем копейку, но хакеры и до неё были жадные и засылали левых регистраций. Потом была поставлена защита с подтверждением по смс, но хакеры видимо обиделись и начали выжигать смски просто тысячами долларов, ведь каждая стоила денег. В итоге там поставили правило что чтобы зарегистрироваться - уже ты должен был отправить смс на специальный номер и только тогда то тебя и пускало. И потом как раз пришёл я и был в шоке - на столько сомнительно выглядящих регистраций я ещё не встречал.
Ну тоесть вам не нравится уведомление именно что он "старый". Т.е. если заменить фразу на "Вы ввели недопустимый пароль" все будет ОК? Разрешать пользователю вводить старый пароль сомнительное удовольствие, тогда от смены пароля нет никакой пользы.
Десять шагов вперёд, девять шагов назад.
В ситуации из вопроса из статьи пользователь пытается зарегистрироваться, что, помимо прочего, почему-то может стриггерить сверку его пароля с уже хранящимися в БД другими паролями.
При этом, мы ЕЩЁ НЕ ЗНАЕМ, доверенный это настоящий пользователь или нет.
Вопроса, кому и зачем взбрело проводить сверку, пока не касаемся. Мало ли. Тут уже попахивает YOBA-архитектурой - но это совсем out of scope нашей дискуссии.
Главное, что попытка регистрации - это по определению "хрен с горы", которому доверять нельзя. Совсем нельзя.
Мне не нравится, что на идущую с фронта операцию от неизвестного постороннего пользователя может вернуться привязанный к конкретному пользователю конкретным данным в БД респонс.
Такого. Не. Должно. Случаться. Никогда. Совсем.
Это почти равносильно выдаче возможности сдампить себе НЕЗАШИФРОВАННЫЙ список паролей сверяемых данных из этой БД первому встречному.
Я, чёрт побери, аналист-недоучка, которого как вышвырнули с баркаса за сомнительную профпригодность, так и не затащили обратно на борт. И то я понимаю как исходную абсурдность этой ситуации из вопроса из статьи, так и потенциальный вред от YOLO-подхода к её непосредственной реализации.
Да и для уже зарегистрированного пользователя сверка нового пароля со старым_и - это настолько неадекватно...
В любом вопросе всегда важно соблюсти баланс "параноя" vs "удоство". Есть ситуации когда разрешать устанавливать какой-то пароль еще раз недопустима ,например база паролей утекла и нужно принудительно заставить пользователя его сменить.
В любом вопросе всегда важно соблюсти баланс "параноя" vs "удоство".
Мгм. А потом очередной сервис, основанный крупной компанией с вроде бы неплохими специалистами, начинает фигурировать в ломающих новостях.
Приведу ещё одну цитатку с купюрами из одного вполне приличного произведения. Рекомендую при случае приложиться к первоисточнику и подумоть. Предупреждаю, это очень времяёмко.
— Запомни. Есть вещи, которые делать НЕЛЬЗЯ. Вообще никогда. ... Никогда. Нипочему.
Некоторые "никогда" делают другие "никогда" не актуальными. Например правило "никогда не использовать одинаковые пароли в разных сервисах" сводят на нет описанный изначально вами вектор атаки.
Скажите, Вам действительно настолько сложно вынуть голову из коробки и попробовать представить, например, вариант, когда проверка на совпадение всё равно происходит, но целиком на бэкенде, а на фронт только отдаётся дженерик респонс (можно продолжать / нельзя продолжать)? Естественно, превращаемый на фронте в максимально обтекаемый и при этом информативный текст (с содержанием, которое по хорошему надо подбирать под конкретные потенциально способные случиться ситуации).
Или проще упереться рогом и таки оставить потенциальное слабое место в безопасности хранимых данных?
"Никогда", делающие другие "никогда" не актуальными - это отличный демагогический приём, которым можно оправдать всё, что угодно, были бы желание и гибкость позвоночника.
А уж уверенность, что гнуться должен пользователь под код, а не код под пользователя, ммммммммм... classic...
это отличный демагогический приём, которым можно оправдать всё, что угодно, были бы желание и гибкость позвоночника.
Помнится когда-то, в одной стране, тоже требовали соблюдения своих "никогда" и сожгли за их нарушение Джордано Бруно на костре.
Все правила пишутся для конкретных условий. Эти конкретные условия могут быть известны только автору (к сожалению и авторы не всегда их понимают).
Экскурсы в прошлое набили оскомину ещё в прошлом.
Попробуйте лучше экскурс в будущее. Хотя бы не будете выглядеть, как томный юноша, открывший таки учебник по Истории.
Источник цитаты тот же.
Тонкостей там много. Я для себя запомнил главное: чтобы перевести обычное высказывание про историю на язык всепобеждающего учения, нужно выучиться двум вещам. Первое: к любому голословному утверждению нужно добавлять слово "объективно". А если нужно как-то состыковать между собой два утверждения, которые друг с другом не вяжутся, одно не вытекает из другого и вообще — то надо закрывать дырку словом "диалектически". Если из какого-то А согласно ТИП следует Б, но есть парочка примеров, когда вместо этого получалось никакое не Б, а хрен знает что, то надо писать "в данном случае из А следует Б в форме хрен знает чего". И если ещё что-нибудь добавить про историческую роль и законы развития, не забывая также про деятельный гуманизм — то всё будет отлично.
Говорю же, чудесное чтиво. Вам бы понравилось.
Кстати, почему-то за минувшие пару суток мне насовали плохо прикрытых обвинений в чём попало, иногда даже обоснованных, - но никто не заметил, что я предлагаю НЕ сверять воткрытую с записями в БД емэйл ТОЖЕ!
Что выглядит, между прочим, куда более грубой ошибкой, заклевать за которую меня проще (но почему-то не ищут люди лёгких путей).
Ведь такая реализация может вызвать интересные сложности с попыткой донести до регистрирующегося пользователя мысль, что учётка в системе у него уже есть (читай: емэйл занят).
Но это нормально! И в обход такой проблемы построить форму логина очень даже можно!
Кое-где я даже уже видел, как эту проблему решали весьма элегантным и самоочевидным способом (заодно сэкономив на интерфейсе капелюху и убрав один из источников "заусенцев" в "воронке").
Увы, для того, чтобы допустить возможность построения регистрации/логина с учётом этого нюанса, нужно не просто вынуть голову из коробки. Нужно слегка изойти из себя.
Может, поэтому господа комменторезы как-то интуитивно сторонятся этой моей "ошибки". Слишком больно при отрыве от стереотипов будет.
Просто так взять и брякнуть потенциальному взломщику
Чтобы поменять пароль, нужно залогиниться со старым. В таком случае слово «потенциальный» тут лишнее — аккаунт уже взломан.
См. "священная корова сесюрности №2" под названием Использование Учётки В Интернет-Кафе.
И proof of concept. И ТЗ на устранение. И неограниченную лицензию на использование. Да. И полцарства впридачу. B vfibyre to`/ Cfvb pyftnt? rfre./
Эта работа (если делать её по-настоящему) стоит денег.
И довольно неплохих, в зависимости от объекта атаки.
Вы тогда не меня теребите - как видите, объясняю я очень плохо.
Вы просто гаркните куда-нибудь в пространство фразочку типа
Чекбокс "Сохранить пароль" надо держать в форме логина по умолчанию включенным ради удобства пользователя!
Пояснятели сами прибегут, и всё объяснят, и кармой одарят... может быть...
(уж поверьте - прибегут. И одарят. Мне уже где-то на -7 одарили. Зато пояснили всё...)
Мы в 2022 году вроде как. Ставим вечную авторизационную куку, а пароль браузер сам запомнит.
Задание под звездочкой реализовать функцию "инвалидировать все другие сессии"
Интернет-кафе используют прокси-сервер с MitM, по факту пре-скомпрометированное соединение, так как MitM собирает все логи, включая POST, и плевать хотел на HTTPS. Атаки как таковой нет, считается, что использовать логин-пароль в интернет-кафе равно его компрометации.
Вы это сейчас серьезно? Любой современный браузер или мобильник будет орать и откажется показывать вам странички при попытке сделать такое.
В интернет кафе железо и софт контролируется владельцем этого самого кафе. Поэтому сертификат этого прокси добавлен в доверенные установленных в кафе браузеров. Никаких вопросов не будет. Вот если выходить в интернет со своего мобильника, то да, заорёт.
А кто вам разрешит перебрать столько паролей, чтобы брутфорс через форму логина был хоть сколько-нибудь осмысленным занятием?
Была бы точка входа. А как её заабьюзить - как-нибудь придумают.
Я не профессиональный сесюрщик, не могу сказать сходу, что тут можно придумать помимо долбежа ботнетом и поиска не прикрытых рекапчей/ЦДНом/чортом лысым APIобразных точек входа, пригодных для произведения брутфорса.
Я просто против идиотизма в производстве.
Но если вы пойдёте другим путём, то и предупреждения о старом пароле тоже не получите.
А нужно ли предупреждение именно о старом пароле?
Нам важно проинформировать пользователя о том, что пароль должен быть другим. В конце концов, если заявить клиенту прямо, что "это уже было", - он действительно просто поменяет циферку в конце пароля. И получится фигня, как в комментарии @ALogachev чуть ниже.
Каким именно другим должен быть пароль - нужно напомнить обо всех нюансах оптом.
И нам с нашей стороны не надо маяться дурью, отправляя уникальный респонс на каждый тип фэйла.
И пользователю не надо раз за разом материться, переделывая пароль под новые всплывшие нюансы.
Если нюансов оказалось слишком много либо среди них таки затесалась дичь вида "не должен совпадать с последними десятью паролями даже частично" (и такое видал...) - заказчику фичи нужно... хмммм... как бы это поделикатнее сказать, к психоаналитику наведаться, что ли. Потому, что за такими методами сублимации, от которых страдают абсолютно непричастные люди, причём массово, обычно стоит какая-то очень тяжёлая травма, которую не повредило бы наконец проработать и перестать усложнять всем (включая собственно заказчика фичи) жизнь.
Если бы меня спросили, как сделать форму логина, я бы ответил: "Какая форма логина?! Только биометрический токен с анализом ДНК и психической активности, что бы случайно не пропустить принужденную аутентификацию третьими лицами".
А без сарказма, аудитория сервиса определяет, что и как показывать. Если моей маме сказать "ваш новый пароль недопустим" без точной причины, она просто отложит facebook на N недель, пока я не приеду в гости и не напишу ей на бумажке новый пароль. А умножить эти N недель на огромное количество таких пользователей, мы получим миллиарды пропущенных кликов на рекламу и потерю прибыли.
Поздравляю, вы технический специалист, а не миллиардер-владелец facebook. И с точки зрения безопасности вы можете быть 100% правым, но прибыль владельца и ЗП junior/middle/senior формошлепщика, который в этом бизнесе работает, зачастую зависит от красоты и удобства в значительно большей мере чем от секьюрности и других маловажных технических факторов.
Абсолютно согласен, довольно тонкие материи. Но ФБ себе такое позволить может (хоть я и осуждаю). Скажу больше - даже когда пишут причину, там иногда такой листинг требований, что проще не регистрироваться вовсе. А потом почему-то клиенты не идут, рынок маленький - нужно больше вкинуть в маркетинг. Радует, что всё же это больше исключения среди хороших сервисов, чем правило.
Вы знаете, мне совершенно лень переписывать заново этот комментарий. Оставлю ссылку и подкреплю ещё свежим рассуждением и парой кросс-ссылок.
Поздравляю, вы технический специалист, а не миллиардер-владелец facebook.
Вообще-то, если реальное обсуждение реальной задачи на функционал дошло до такой степени разброда, - то я в первую очередь баран. Потому, что всё на самом деле уже должно быть решено и вопрос ТОЛЬКО в реализации.
чем от секьюрности и других маловажных технических факторов.
Уууууууу, секъюрность теперь маловажный фактор... Я понимаю, что штраф за утечку личных данных не Вам платить. Но это не повод подталкивать тех, кому ВОЗМОЖНО придётся платить этот штраф, к такому опасному поведению.
ЗП junior/middle/senior формошлепщика, который в этом бизнесе работает, зачастую зависит от красоты и удобства в значительно большей мере
Формошлёпайте наздоровье. Отлично. Кто-то же должен покупать подписку на Тильду. Но я бы предпочёл, чтобы серьёзных проектов Вы не касались.
У трезвых людей зарплата непосредственно создающих продукт персон зависит не от перечисленных Вами факторов.
Если моей маме сказать "ваш новый пароль недопустим" без точной причины, она просто отложит facebook на N недель, пока я не приеду в гости и не напишу ей на бумажке новый пароль. А умножить эти N недель на огромное количество таких пользователей, мы получим миллиарды пропущенных кликов на рекламу и потерю прибыли.
Браво. Вы убедили меня в том, чего я и так придерживался.
Я бы так не смог.
Эта "очень плохая" практика зафиксирована в международном стандарте PCI DSS:
8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
В этом?
Вы понимаете, что попытаться натянуть стандарт для платилок на форму авторизации/регистрации - это... наивно?
"Вы ввели старый пароль! Он больше не подходит!"
При входе во вспомогательные аккаунты после смены пароля вполне можно забыться. И, когда Google пишет "вы поменяли пароль 2 месяца назад", это отрезвляет и помогает не вводить повторно тот же самый пароль (вдруг ошибся при вводе), а ввести "новый".
О. Ещё лучше. Не только брякнуть "да, когда-то эта пара логин+пароль была валидной", но и указать, когда именно перестала быть валидной.
Чесслово, я не могу сказать, что хуже, - принудительный 2FA вместо паролей или Ваш вариант.
Смотря кому лучше. Всегда есть конфликт интересов. Как минимум, безопасность vs удобство.
Для важного аккаунта у меня 2FA включен. Для временного (дурацкие регистрации и прочее) 2FA абсолютно не нужен. А вот подсказка очень кстати.
Я, конечно, понимаю вектор атаки:
злоумышленник подбирал пароль к мое гугловой учетке
узнал, что какое-то время назад был такой пароль (тут, конечно, большой вопрос, что много паролей он не проверит, и подсказка мне как раз нужна, чтобы самому не заблокироваться)
пошел с этим паролем на другие ресурсы
Теоретически можно нафантазировать, что условно брутфорс на гуггле, авито и прочем можно поделить на кусочки, чтобы проверять только часть паролей. Только вот ежели на сайте нет локаута после нескольких попыток, не вижу большой разницы, проверять ли 2 миллиона паролей или только 1. А если локауты есть, вероятность с трех попыток подобрать брутфорсом "пароль, действоваший пару месяцев назад и который прекрасно подойдет к другому ресурсу сейчас" крайне мала.
100% безпасности не бывает. А пытаться из трех девяток сделать 5 девяток на не сильно критичном ресурсе типа форума/соцсети (мы же не о банке с MFA говорим) путем усложнения жизни обычному пользователю, тем более "ради его безопасности на других ресурсах" - мне это кажется не сильно целесообразным.
Хотя, разумеется, тоже можно возразить: "Вот Гугл помог подобрать пароль к Хабру, от вашего имени запостили экстремистский материал..."
Я там где-то в соседней ветке комментариев мягко намекнул на ботнеты.
Наличие локаута на неудачное количество попыток ничего не меняет потому, что даже у Флагманов Индустрии оно написано в лучшем случае ногами. Без оглядки даже на решаемый этим функционалом круг задач.
У тех же параноиков из Battlestate Games реализована какая-то чеканутая система инкрементальной продолжительности локаута чуть ли не с первой же неудачной попытки.
От которой страдает, в общем-то, только конечный пользователь, который с трёх неудачных попыток может улететь в отмокание чуть ли не на сутки (за два года так и не понял, от чего это зависит).
Потому, что ботнету наплевать, куда долбить из-под какого TOR'а. Ботнету неведома усталость.
И ихней антибрутфорс системе, в общем-то, тоже наплевать, что в учётку кто-то ломится. Показать на фронте беззубое "ой, подождите полчасика" - это всё, на что хватило у них здравого смысла.
И техподдержке, я так понял, наплевать - я фидбэк ещё в 2019 году, что ли, отгружал на эту тему. Адекватного ответа не дождался.
А конечному пользователю не наплевать на то, что какой-то невменяемый скрипт упёрся рогом. Потому, что уплочено RUB4999 - и было бы неплохо, чтобы уплоченное начало приносить какой-то фан. А не лишние трудности от какого-то сесюрщика, не удовлетворённого в неустановленной сфере.
Я там где-то в соседней ветке комментариев мягко намекнул на ботнеты.Наличие локаута на неудачное количество попыток ничего не меняет потому, что даже у Флагманов Индустрии оно написано в лучшем случае ногами. Без оглядки даже на решаемый этим функционалом круг задач.
Точно?
Готовы показать или хотя бы описать работающую систему перебора значимого (>миллиона) числа паролей к гугл или хотя бы яндекс аккаунту за разумное время?
Окей, окей, вы с @Bronx меня уговорили. Я проиграл этот раунд турнира по лени. Я не поленился загуглить. Потому, что, alas, писать даже концепт на ТАКОЕ я бесплатно НЕ собираюсь.
Но для прикидки порядка мощности потенциальной атаки И структуры начать, я думаю, можно с https://habr.com/ru/company/yandex/blog/577026/ .
DDoS - это, конечно, не брутфорс, и в зависимости от того, как именно будет обходиться и/или вводиться в заблуждение антибрутфорс система (и будет ли - если подойти к делу творчески, можно кое-где срезать пару углов), пересчёт потенциальной мощности (DDoS) в реально возможную (собственно брутфорс) можно делать ооооочень по-разному.
Я, пожалуй, возьму итоговую цифру с того же потолка, что и Вы, даже не отвлекаясь на поправку на использование словарей и всего такого.
Я считаю, что ботнет из статьи УЖЕ способен выудить значимое (>миллион) число паролей (sci!) за разумное время (скажем, месяц) с наиминимальнейшими правками кода.
А интересующие Вас детали архитектуры, полагаю, Вы можете получить из освещающих тот инцидент более детальных более профессиональных статей, а не из моей писанины.
Видите, и этот раунд турнира по лени я тоже проиграл.
Задудосить в теории можно всех и всё. Исключение разве что тир1 провайдеры. Тут деньги решают. Мозги могут только количество денег при неизменном железе менять.
Брутфорс паролей у "Флагманов Индустрии" это совсем другое дело. Если они не 100% прикрыты от брутфорса это детская ошибка их разработчиков систем авторизации и их безопасников одновременно. Я в такие ошибки таких людей уже много лет как не верю.
Я вижу смысл делать так какое-то время после смены пароля (в зависимости от частоты использования сервиса, от пары дней до пары недель). Если злоумышленнику каким-то образом удалось сменить пароль, то пользователь моет потыкаться в ошибку, восстановить через почту и продолжить пользоваться сервисом, так и не поняв что произошло.
А если пользователю показать "2 часа назад ты сменил пароль", то это раскроет факт взлома учетки.
Но то, что время показа сообщения должно быть ограничено - соглашусь, но быть, на мой взгляд, такое имеет право (хотя есть вариант сделать это на энную неудачную попытку входа, хотя и это кажется не секьюрной идеей).
"Вы не можете зарегистрироваться с таким паролем, так как он уже используется пользователем Вася")))
Хорошо, если мидл назовёт парочку, допустим md5 или sha-1/sha-256. Вопрос чем они плохи — уже скорее сеньорский левел, обсудим это ниже.
Как по мне, если в 2022 году кто-то скажет что нужно для хеширования использовать md5, то это уровень стажера, даже не джуна.
Мой пароль в MD5: 0b538919bf6b514958c100fc8ad1ef87
Если что-то получится - можете прямо с моего аккаунта отписать его тут в чистом виде, чтобы убедить в небезопасности :)
Сложная длинная соль усиливает слабые пароли.
Это плохая идея хранить еще в конфиге или в переменных окружения. Усложняет жизнь разработчику но не повышает безопасность. Если хакер имеет доступ к базе то по умолчанию нужно считать что у него есть доступ к всему содержимому сервера. ПОэтому соль должна быть уникальна для каждой записи и хранится рядом с паролем. Так вы максимально сусложниет жизнь подборщику паролей и максимально неусложните жизнь разработчику
по умолчанию следует считать что он получил доступ к всему серверу. так проше строить защиту и сложнее запутатся в условиях взлома. Иначе вы можете придти к выводу что раз у взломзика нет доступа к коду то можно придумать свой алгоритм хэширования и шифрования .
по умолчанию следует считать что он получил доступ к всему серверу
По-умолчанию нужно считать соотношение «цена/бенефиты» для разных видов защит от разных видов атак, а не идеализированный сценарий. Иначе вы можете придти к выводу, что раз идеальной защиты нет, значит нужно исходить из максимы «что попало в интернет известно всему миру», и посему защищать данные вообще бессмысленно и затратно, потому что беспечные юзеры сами всё сливают, а завтра наступят квантовые компьютеры, которые расшифруют всё.
Иначе вы можете придти к выводу что раз у взломзика нет доступа к коду то можно придумать свой алгоритм хэширования и шифрования .
Код, как и БД, может храниться в куче мест, где к нему имеет доступ (или могут случайно ошибочно получить доступ) большее количество людей. Т.е. периметр атаки (или ошибочной публикации) для кода и БД гораздо больше, чем для ключей к серверу, которые хранятся только у админа. И отследить источник утечки гораздо труднее.
Сценарий «базы утекли» без доступа к серверу (через дырку в авторизации web API или внутренней сети, через слишком широкие запросы в web API, через внутренний слив бэкапов и проч) случается чаще, чем сценарий «хакер получил доступ к переменным окружения веб сервера». Если простая мера в виде разделения соли на две части, хранимой в разных местах, позволяет кардинально уменьшить периметр атаки, то этим нужно пользоваться, потому что выгоды выше затрат.
Сценарий «базы утекли» без доступа к серверу (через дырку в авторизации web API или внутренней сети, через слишком широкие запросы в web API, через внутренний слив бэкапов и проч) случается чаще, чем сценарий «хакер получил доступ к переменным окружения веб сервера». Если простая мера в виде разделения соли на две части, хранимой в разных местах, позволяет кардинально уменьшить периметр атаки, то этим нужно пользоваться, потому что выгоды выше затрат.
Подпишусь. Дешево, просто и может помочь.
Если чуть дороже: Сервис работающий с паролями должен жить отдельно вообще от всего. С совсем минимальными со всех сторон правами доступа к проду, любым системам виртуализации и железу на котором он крутится. И конечно же логи аудита вообще любого чиха на проде. Которые кто-то смотрит регулярно. Доступ к настройке, хранению и тому подобному логов аудита и проду работающему с паролями должен быть у не пересекающихся групп людей. Отдельная стойка запирающаяся на отдельный ключ с отдельным журналом кто его брал тоже хорошо сюда вписывается.
Если еще дороже: Добавляем HSM модуль. На котором и лежат ключи для расшифровки строк в БД. Тогда даже при утечке всего, но без долговременного доступа злоумышленника к проду, все украденное превращается в мусор.
PS: Чувствую что не возьмут нас по этому собеседованию. Мы о каких-то непонятных вещах говорить начнем, вместо нужного рассказа: используйте https и не храните пароли плейнтектом.
Напомню, ветка то началась со спора что и MD5 норм если соль и перец подкинуть.
Оставь надежду всяк сюда входящий.
Делаем все возможное чтобы злоумышленник не получил доступ к чему-либо и делаем все возможное чтобы минимизировать последствия если доступ он все таки получил.
Напомню, ветка то началась со спора что и MD5 норм если соль и перец подкинуть.
За MD5 я ничего не писал — только про то, что к соли можно добавить перца, ради «defense in depth». В общем, с вами я не спорил, просто воткнул 2 копейки :)
p.s. Если так рассуждать, можно тогда вообще сразу уж считать что хакер не получит доступ ни к чему, тогда не то что md5 становится подходящим решением, а хранение в открытом виде.
Вот совсем не одно и тоже всё же доступ к базе и к конфигам где-то в енвах, если там разные способы доступа и пароли к сервисам конечно.
Объясните пожалуйста смысл такой операции? Чтобы защититься от радужных таблиц достаточно соли, чтобы защититься от брутфорса пары "интересных" пользователей — если пароль достаточно сложный то кажется не так-то просто это сделать даже имея всю соль на руках.
В случае же аутентификации по md5 можно не брутить пароль, а найти коллизию, т.е. другой пароль, дающий тот же хеш и с ним войти. В этом проблема использования md5, а не в возможности реверса. Хотя радужных таблиц для популярных паролей под него достаточно.
sha-256 часто используют не обрабатывая коллизии никак. Вот вы UUID когда генерируете часто рассчитываете на них? А sha256 куда реже их имеет.
уже изобрели хеш-функции, не подверженные коллизиям?
такое возможно только для длины хэша не менее длины защищаемого текста
В качестве проверки концепта можно просто написать сюда плейнтекст коллизии. Этого будет достаточно чтобы разгромить коммент выше про то что мд5 хорош.
Под этот хэш подходит слишком много паролей, чтобы перебирать их все на хабре.
Минимум с миддла должны первыми звучать другие важные вопросы:
Для какой программно системы эта форма и какие требования этой системы к процедуре аутентификации?
Если корпоративной, то требуется ли специальная форма аутентификации: смарт-карты, ПАК с УКЭП и прочие подобные радости.
Не банковская ли это система ДБО? Если да, то требуется ли ввод дополнительных полей, указывающих на организацию аутентифицируемого? Поясню - в некоторых ДБО при одном подписанте в разных ЮЛ это должен быть один аккаунт, а в некоторых - разные.
И много подобных вопросов применительно к корпсистемам.
Хотя, с текущим низким порогом входа в ИТ это уровень архитектора, наверное :)
По соли ещё: при конкатенации пароля и соли, вначале должен идти пароль, а потом соль. Иначе, в зависимости от длины блока хэша, длины соли и длины пароля, комбинация "соль + пароль" может не влезть в блок хэш-функции, и конец пароля обрежется. А если "пароль + соль", то обрежется соль.
Причина совершенно другая. Если соль идёт вначале и известна нарушителю, то можно один раз посчитать промежуточное состояние хеш-функции и дальше брутфорсить от этого состояния. Если соль в конце, то придется каждый раз пересчитывать весь хеш целиком.
Никакие входные данные хеш-функциями не обрезаются.
Эту информацию давали в курсе криптографии, который я проходил, и она верна как минимум для некоторых реализаций.
https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length
С bcrypt пример не самый удачный, потому что он сам разделяет пароль и соль, но суть не меняется.
Про промежуточное состояние хэш-функции не знал, спасибо!
Пара замечаний:
"Асимметричный" - от какого слова образовано? (Подсказка: не от слова ass)
PBKDF2 - это не функция хеширования. Если какие-то данные пользователя нужно шифровать, используя пароль, следовало бы упомянуть об этом отдельно. Иначе мухи с котлетами.
OpenID/Oauth могут точно так же стать единой точкой отказа. Необходимо упомянуть о масштабировании провайдеров. Ну и вы опять же в тексте смешиваете в кучу аутентификацию с авторизацией.
"такой пароль уже существует в системе" смешно, конечно, но если аутентификация вынесена в отдельный сервис, не лишним будет использовать на этапе валидации (на сервере) базу часто используемых паролей для проверки. 2FA снижает риски, но, всё же, моё мнение, - как ещё приучить пользователей не быть безалаберными?
"шифрование не замена хэшированию и должно применяться только в крайних случаях для кейсов подобно обсуждаемому нами" так и не понял, что за кейс такой. Данные аутентификации нужны только для аутентификации, которая односторонняя, в чём необходимость хранить зашифрованными и возвращать их в плейне? Приведите пример.
И ещё дополнение по валидации. В дикой природе есть сервисы, которые ограничивают пароли по алфавиту и длине. Пример: личный кабинет Читай-Города. Писал им, что не стоит так делать, но воз и ныне там. Хотя нет, они вот-вот переведут аутентификацию на sms. Хрен редьки не слаще.
Про глупость такого ограничения тоже стоило бы упомянуть.
Зы Прекрасное объяснение на енотах о разнице между id/authen/author в блоге ЛК, например.
"шифрование не замена хэшированию и должно применяться только в крайних случаях для кейсов подобно обсуждаемому нами" так и не понял, что за кейс такой. Данные аутентификации нужны только для аутентификации, которая односторонняя, в чём необходимость хранить зашифрованными и возвращать их в плейне? Приведите пример.
На самом деле - любая ERP/CRM для провайдера. Самая большая беда в том, что бОльшая часть пользователей при смене ОС/роутера/etc первыми делом просит пароль... Менять их - выстрел в ногу тех.поддержке, т.к. очень быстро у юзера будет с десяток бумажек с паролем - и он всеравно не поймет какой из них нужен. И снова позвонит. А потом еще раз... "эс как доллар" - суровые реальности :-(
ПС: Очень многие такие системы хранят plain текстом пароли до сих пор. Так что хорошо бы их хотя бы шифровать. Но вот хешировать - не очень вариант
Всегда смотрел с недоумением на системы, присылающие по запросу текущий пароль (а их до сих пор немало, увы). Все (на мой взгляд) разумные системы при запросе генерируют новый пароль или токен на его смену и присылают забывчивому пользователю "по надёжному каналу" (обычно "надёжным каналом" считается почта или СМС, хотя тут возможны нюансы). И да, никто, кроме самого пользователя, не должен знать пароль от учётки. Ни при каких обстоятельствах. Максимум - можно делегировать необходимые полномочия.
1) упс. исправил
2) Правильно ли я понял, что отличие только в том, что в PBKDF2 является HMAC, который есть алгоритм, который вызывает хэш-функцию и в него уже "вшита" соль (пароль) + есть возможность указать кол-во итераций?
3) > OpenID/Oauth могут точно так же стать единой точкой отказа.
it depends, как и обычно. Много "если". Но сойтись тут можно в одном - вынесенная аутентификация снижает риск падения связанных сервисов в случае отказа первой.
4) Хороший поинт, согласен.
5) > Приведите пример
"напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица.". А еще "мы хотим собрать статистику по паролям и их сложности, но это будет когда накопим данных, а не в моменте". или "засетапайте эти же пароли в 3rd party системе, чтобы они были идентичны, ну вы поняли - и чтобы пользователь смог под капотом ходить в эту систему по кредам".
Всё это конечно про коня в вакууме, однако ...
> Прекрасное объяснение на енотах о разнице между id/authen/author в блоге ЛК, например
Статья огонь. Добавил в статью.
Спасибо за дополнения!
Правильно ли я понял, что отличие только в том, что в PBKDF2 является HMAC, который есть алгоритм, который вызывает хэш-функцию и в него уже "вшита" соль (пароль) + есть возможность указать кол-во итераций?
Криптографическая хеш-функция - это просто функция свёртки, обладающая необратимостью и стойкостью к коллизиям.
HMAC - механизм проверки аутентичности сообщений. Использует под капотом хеш-функцию.
PBKDF2 - механизм деривации ключа (который затем можно использовать как угодно, но вообще задумано использовать его для симметричного шифрования). Для деривации нужен секрет и еще какие-то данные (соль). Также использует хеш-функцию внутри (как частный случай псевдослучайной функции).
Понимаете, тут вопрос в применимости. Для аутентификации по паролю онлайн (в удалённой системе) необходимо и достаточно хранить необратимые и стойкие к коллизиям солёные хеши.
Никто не запрещает вам использовать scrypt, bcrypt, PBKDF2 вместо простой (относительно вышеупомянутых) необратимой функции свёртки. Но! Прошу обратить внимание:
Алгоритмы деривации вычислительно сложнее. Вы тратите ресурсы CPU сервера впустую, повышая риски DDOS (даже учитывая капчу и рейт-лимит).
Всё меняется при аутентификации оффлайн. Если у атакующего есть возможность осуществить атаку на секрет, имея хеш, а также время и ресурсы, то алгоритм деривации как никогда кстати - он подразумевает соль и количество итераций (в scrypt ещё и требования по RAM), которые усложняют словарную атаку и брутфорс, соответственно. Это актуально, например, при шифровании локальных хранилищ (атака evil maid). В этом месте закономерно возражение: но ведь всё равно приходится солить простые хеши в бд (а вдруг сольют). Моё мнение - требует отдельного исследования и сравнения скорость и вычислительная сложность алгоритмов деривации vs простой хеш+соль. Всё равно придётся искать компромиссы между нагрузкой на сервер (один из трёх китов ИБ - доступность) и рисками слива бд. Ну и ко всему прочему, последнее (риски), как всегда, нужно стараться нивелировать комплексным подходом (в безопасности без этого никуда).
Что же касается моего замечания за номером 2, прошу простить за буквоедство, вы назвали алгоритм деривации хеш-функцией, и меня что-то триггернуло. Попытался объяснить своё видение =)
Теперь что касается пункта №5. То, что вы и пользователь @affinity описываете, это всё такая системная дичь, которая совсем не решается техническими методами. Криптографией в том числе. Ну, немного сложности атакующему шифрование добавит, да. Если прям нужны пароли пользователей в плейне - ИМХО, нужно хранить их совсем в отдельном месте, с доступом на чтение только оффлайн и по отдельно разработанным протоколам.
Да, паззл складывается в голове. Спасибо за разъяснения!
Понимаете, тут вопрос в применимости. Для аутентификации по паролю онлайн (в удалённой системе) необходимо и достаточно хранить необратимые и стойкие к коллизиям солёные хеши.
Вы заблуждаетесь. Вектор атаки на секрет имея хеш, а так же время и ресурсы существует вне зависимости от того онлайн система, осуществляющая обработку данных, или офлайн. Соответственно использование вычислительноемких функций преобразования паролей имеет смысл в обоих случаях.
А вообще в первую очередь следует пользоваться общепринятыми рекомендациями, например OWASP Password Storage Cheat Sheet, вместо того чтобы выдумывать свои схемы.
Признаю, заблуждался. Вне зависимости от степени рисков в варианте с удалённым доступом, вектор атаки существует. И свои велосипеды, как это было до появления рекомендаций, теперь выдумывать ни к чему, и даже вредно.
Спасибо за ссылку на cheatsheet! Очень рад, что OWASP теперь всё так структурировали и даже предложили несколько вариантов. Всё равно несколько коробит терминология, но это уже мои проблемы, видимо, термин "алгоритм хеширования" надёжно закрепился сейчас за методами деривации ключа.
Пожалуй, мне надо перечитать современные рекомендации, и только потом вступать в подобные дискуссии.
напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица
Просто дайте саппорту саппортовский токен. Зачем ему знать пароли пользователей?
мы хотим собрать статистику по паролям и их сложности, но это будет когда накопим данных, а не в моменте
Слишком какой-то вакуумный конь. Статистику эту можно собирать при логине, когда пароль всё ещё виден. Но хранить из-за этого пароли в обратимой форме ― идея так себе.
засетапайте эти же пароли в 3rd party системе, чтобы они были идентичны, ну вы поняли - и чтобы пользователь смог под капотом ходить в эту систему по кредам
Так в смысле, сами же в статье рассказываете про OpenID и всякое такое. На крайний случай люди LDAP используют для таких 3rd party систем.
"напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица."
"Вы реально доверяете своим саппортам, набраным из трехкопеечных студентов по объявлению, пользовательские пароли? Тех самых пользователей, половина которых для вас и своего онлайн-банка один пароль использует?" Ну серьёзно, если заказчик такого хочет - от него лучше убежать побыстрее и подальше. На следующей неделе он предложит закладки в парке раскладывать.
Я бы ответил, что нужно взять готовое решение типа Keycloak, Ory, Avanpost, ... Но сначала посмотреть какая система уже используется у заказчика. Если никакая, то аналитик должен определить верхнеуровневые требования (например, нужна ли в принципе на этом конкретном сайте двухфакторная аутентификация), сделать обзор по существующим в мире системам идентификации и аутентификации пользователей, оценить их на соответствие требованиям, затем написать детальные постановки (например, с требованиями к правилам валидации вводимых данных). Затем можно начинать писать код. И конечно же после всего этого я был бы послан и с позором провалил собеседование, потому что от меня ожидали рассказ про необходимость хэширования паролей, и в итоге в опроснике было поставлено ноль галочек напротив правильных ответов.
Хорошая ли идея вынести аутентификацию на openid?
Безусловно да
Если на аутентификацию будет один из векторов атаки - это не затронет остальные компоненты системы.
Вспоминается история с Трампом и соцсетью Parler. Американские леваки отключили хостинг для микросервиса авторизации соцсети. В результате можно было зайти под любым логином без авторизации, что они и сделали.
Нужно ли скрывать вводимый пароль на странице?По факту часто должна быть возможность посмотреть введённые данные, т.к. сложные пароли большинство не запоминает а где-нибудь хранит и при копировании могут добавляться например пробелы.
Асимметричное шифрование пароля в БД? Что вы под этим подразумеваете?
А почему нет. пароли шифруются по открытому ключу, хранятся в базе, а закрытый для расшифровки можно вообще забыть. Получаем хорошее стойкое хеширование.
Оригинальный подход. В любом случае, некорректно подобное называть асимметричным шифрованием.
1) можно "забыть забыть"
2) а зачем использовать асимметричное шифрование, там где можно использовать хеширование?
Да, валидный комментарий. Я скорее имел в виду, что если затрагивается симметричное, то и про ассиметричное можно/могут спросить. Но да, к паролям в бд это имеет примерно никакое отношение.
При нессиметричном шифровании реверснуть не получится, даже если открытый пароль прямо в коде.
Ассиметричные ключи не панацея, если не уметь их готовить.
Шифрование может потребоваться для авторизации в "сторонних" ресурсах. В случае, если там на вход подать можно только сам пароль, а не хэш.
Простите, но кто и как должен обеспечивать синхронизацию логинов+паролей на сторонних сервисах? Если они действительно независимые, то смена пароля "там" сразу сломает авторизацию, а если они связанные, то что мешает использовать единый алгоритм аутентификации на разных подсистемах?
Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - это логин (а лучше хэш логина). Пароль - нельзя. Было уже множество громких ининцидентов
Примеры взломов можно глянуть тут и тут
Почитайте по второй ссылке внимательнее. Вопросы безопасности информационных систем это проблема уровня организации. Аудит и логирование: кто, когда и что делал в вашей системе - одно из требований регуляторов. Все это в том или ином виде отражено в стандарте (ISO/IEC 27001 - Information security management systems - вообще полезное чтиво). Т.е. независимо от того, джуниор вы или синьер, если к вам приходят с такого рода вопросами, а не детальной спецификацией (с какой целью, в каких случаях, куда, что и в каком виде должно логироваться), то можете сразу надевать парик и делать себе большой красный нос, чтобы адекватно смотреться в компании этих клоунов. ;)
Я бы позволил пользователю иметь пароль любой сложности, если это не какой-то супер критичный сервис, типа банковского приложения.
О, а я оказывается Senior веб-разработки :) Хотя я в жизни ни одной странички не написал :)
Нужна ли валидация на сложность пароля или можно позволять пользователю иметь пароль любой сложности?
Если это личный сервис - нет, максимум - уведомление пользователю, что он использует слабый пароль. А на самом деле, политика паролей должна быть прописана в ТЗ или в требованиях службы безопасности, разработчик это решать не должен. ИМХО.
То же касается и логирования.
Половина пунктов в статье из суровой реальности, когда заказчик хочет, стадия бизнес-анализ пропускается, а разработчик по сути человек-оркестр. Проходил такой этап, знакомая история. Но... Если все-таки речь идет о найме именно разработчика, специалиста в своей области, то вопрос я бы перефразировал: "Вас попросили принять участие в бизнес-анализе, создании ТЗ на разработку и спецификации формы аутентификации для сферического сайта в вакууме. Что по вашему мнение следует уточнить, учесть и какие предложения по реализации технической части у вас имеются?"
Эквивалент 128 битного симметричного ключа равен 2048 ассимметричного.
С какого перепугу? Я ещё понимаю, если разговор о конкретных алгоритмах, т.е. 2048bit RSA и 128bit ECDSA/Ed25519, и то вопрос открытый, почему это перебирать 2048 или на сколько там сократили атаку на RSA математики бит (сколько помню, и близко не до 128) легче, чем 128?
Безусловно, запрос должен посылаться с CSRF токеном. Это гарантирует отправку формы тем же клиентом, что её и отобразил.
Не гарантирует
>>Нужно ли скрывать вводимый пароль на странице?
А меня, как пользователя, бесят эти звездочки. (и дурацкая кнопка показа, которая тут же скрывает, когда пытаешься исправить или добавить символы)
>>эти пароли в текстовых файлах на рабочих столах, т.к. запомнить их нереально
Я так от своих репозиториев в гитхабе храню ключ))) Извините, я не способен запомнить 40 случайных букв (а по хорошему надо еще и на каждый репо свой). Они почему-то запретили комитить по паролю учетки в гитхабе, только по ключу
Так же можно упомянуть про двойное хеширование и метод цепочек - внутрянку знать не обязательно, просто знать, что методы есть.
А какая связь между формой аутентификации и методами разрешения коллизий в хэш-таблицах? При сохранении пароля нужно произвести брутфорс и рядом с хэшом в связный список положить все пароли, которые под этот хэш попадают?
Что вы привязались к этому шифрования )))
Где вопросы про web3 ? авторизацию кошельков без логинов паролей? , где мультисиг кошельки? где входы по Ferra, G,Y,F и прочим? Как должна выгладить структура\архитектура при той же web3 авторизации?
Статья как будто человека помешенного на велосипедном шифровании
Вообще статья крутая, но раздел по Rate limiter это что-то... "тема сабжа", "аффектать", вай сач мач?
К какому уровню квалификации относится вопрос "давайте сначала обсудим модель угроз"?
GETом слать нельзя! — без вариантов и шаканий ножкой. Потом выгребаются все пароли из разных логов squid/nginx/apache и прочих…
httpwg.org/specs/rfc7231.html#GET
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 или еще через какую экзотику (свой клиент/аппликация) — в любом случае это колхоз как на клиентской так и на серверной стороне — ради чего?
У всех нормальных апишек в ответе стоит no-cache. Иначе можно очень интересные результаты внезапно получать.
Кеши лучше на стороне аппликейшен серверов делать. Ответить из памяти или из соседнего Редиса не стоит ничего. Работает надежно и предсказуемо.
Выглядит как проблема настройки прокси сервера.
Если это админ из вашей конторы, то на него заводится тикет с максимальным приоритетом и быстро эскалируется до вашего и его руководства если он оперативно не чинит.
Если это где-то в интернете, то пользователю сообщается о неверных настройках его сети и забывается навсегда.
Бывает всякое. Да почти что угодно бывает. Надо со своей стороны сделать хорошо, и дальше только проверять что по пути никто не сломал.
По моему браузер отбрасывает тело запроса, если его тип GET и уже на сервер этот запрос приходит без него. А вот через какой-нибудь postman можно отправить GET запрос с body.
Что делать в случае коллизий паролей при хэшировании?
Ну так и что делать? В "ответе" ответ не содержится, только рассуждения о том, что такое маловероятно.
Все еще не понимаю, почему везде и всюду не внедряют SRP-6, которая решает множество упомянутых проблем. И в подобных статьях это упускается.
Потому что она сложная, требующая правильной имплементации и на самом деле решает проблему аутентификации И сервера, И клиента? Иными словами просто предназначена для другой модели угроз?
Если использовать готовые библиотеки (а они есть) то не сложнее. Да, нужно два запроса, а не один, но зато не надо пароли солить и шифровать. Я уже плохо помню, лет пять назад сделали на проекте и забыли.
Да, аутентифицировать сервер обычно не нужно, https защищает, если не терминируется где-то в прокси. Но разве это чему-нибудь помешает? Лучше меньше угроз, чем больше.
Ничего нового в статье нет, ожидал увидеть целый блок посвящённый защите от ботов и авторега. Что если кто-то напишет систему авторега и сделает 10тыс. аккаунтов? Как защититься? А если сделает 100к аккаунтов? Есть целые решения для обхода десятка видов капч, получить сотни тысяч ip`шников для проксей не проблема.
Токены для защиты от CSRF больше не нужены, у cookie есть атрибут SameSite, он решает эту проблему.
В вопросы сеньору/сеньору+ можно добавить про способы аутентификации без передачи по сети пароля плейнтекстом (PAKE/SRP). Весьма интересная тема.
Вот конкретные вопросы. В дуровском Телеграме накоплена огромная база пользовательских номеров телефонов, полученных при регистрациях. Каждый такой номер, будучи аналогом удостоверения личности, позволяет узнать об этой личности всё. Я понимаю, что сам Дуров — приличный человек (это постулат), но нет гарантии, что в его команде не угнездился тот, кого в статье и комментариях называют «плохим человеком», и он имеет доступ к этой базе.
1. Значит ли это, что процедура регистрации в Телеграме с точки зрения гарантий анонимности и приватности построена неправильно?
2. Возможно ли сделать её правильно? Тут, конечно, надо сначала формализовать, а как правильно-то? Но я знаю ответ: вот в видеомессенджере Tox меня зарегистрировали без всяких телефонов, т.е. такая процедура возможна. И это при том, что даже старый добрый Скайп по прошествии лет начал время от времени закидывать мне удочку — может, сообщите нам свой номер телефона? Ах, не хотите? Ну ладно…
3. Если регистрация в Телеграме скомпрометирована, то почему миллиардам его пользователей это пофик?
4. Как с этим засильем бороться с пользовательской стороны? Не регистрироваться там, где просят номер тлф? Но ведь просто посмеются, невзирая даже на объяснения типа «у меня нет мобилы!» (кстати, вполне релевантный ответ).
Ну скажем так - параноики Телеграмом не пользуются :) Как и смартфонами, как и .... ах да, где та грань-то? :) Конечно же те, кто не хочет вводить свой телефон (и я их понимаю) - приобретают просто левые симки. Но суть такова, что если вас захотят отследить - вас отследят. Рано или поздно. Вопрос лишь в том, насколько оппоненту это нужно, тут и идёт игра "перетяни канат". Мне кажется, анонимность в наше время это просто миф. Можно обойти 99.9% кейсов по деанонимизации, но оставшийся процент, который входит в "эдж кейз" всё равно вас "убьёт", просто шанс этого очень мал. Т.к. стойкость анонимизации в самом слабом звене, а этих звеньев прилично - помнить обо всех нормальному человеку просто нереально. Только, если от этого зависит ваша жизнь и вы точно знаете, что если дадите осечку - вашей жизни будет угрожать опасность в том или ином виде. Так что тут вопрос меры анонимизации.
Вспоминаю отчёт агента в расследование ФБР о поимке владельца SilkRoad и на чём он "провалился" - хочется просто улыбнуться.
Вопросник очень неполный, там на самом деле гораздо больше нюансов. Например, только по теме mfa можно говорить, наверное, час: как защищаться от leak-ов БД mfa-токенов, как оптимизировать mfa чтобы не надо было посылать платную смс каждый раз, вопросы accessibility, как защищаться от социальной инженерии, что делать если пользователь потерял свой mfa и recovery codes тоже, может ли смс считаться безопасным методом mfa и т д. и т.п. Очень обширная тема.
Но главное не это: по моему опыту, знание аутентификации плохо коррелирует с определением джун/мид/сениор. Я раньше тоже задавал кучу вопросов по безопасности на каждом собеседовании (поскольку сам очень много знаю по теме, приходилось например участвовать в защите крупных систем от ботнет-атак в качестве техлида), но быстро понял, что это плохо работает. И в последнее время сомневаюсь, что это подходит даже как "один из вопросов".
Я вполне могу представить классного сениора, который с этой темой не работал совсем, и как следствие, он её будет знать на уровне джуна. И наоборот, джун, который был в команде которая делала аутентификацию, и он будет знать все эти вещи на хорошем уровне.
Системы аутентификации и авторизации часто либо используются готовые, либо в серьезных конторах типа юникорнов и фаанг - пишутся отдельной командой. Условно у вас есть 50 команд в продукте, и только у одной из них есть серьёзный опыт работы с аутентификацией. Все остальные знают тему шапочно - но это не означает, что они плохие программисты.
Готовые системы тоже не стоит недооценивать, особенно от фаанг. Они сделаны очень хорошо и продуманы до мелочей. Лучше использовать их, чем написать велосипед и завтра получить очередной leak персональных данных людей, которые вам доверились. Плюс, как вы правильно заметили в статье, всегда есть вариант с oidc/saml.
Резюмируя, я бы не стал спрашивать эти вопросы на собеседовании кроме следующих случаев:
когда нанимаете в команду аутентификации
когда нанимаете архитектора по безопасности
когда кандидат заявляет, что знает эту тему хорошо, тогда стоит проверить, насколько хорошо :)
Что по соли — она может быть одна для всех пользователей
Фигня какая-то, и это сеньор левел? Соль нужна для того, чтобы одинаковые пароли давали разные хеши и нужно было брутить каждый хеш персонально, а не всю базу разом. Если соль одинаковая для всех юзеров — она бесполезна.
Порой думая о безопасности забывают о том что у пользователя может быть несколько логинов или учетных записей и вспомнить с какой учетки заходил сложно, порой думаешь по-любому логинился через 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, он смог зайти со своим номером телефона, но стал видеть переписку другого человека, при этом насколько я понял со слов друга, другой человек пользовался приложением и вел активную переписку :) То ли второй человек сменил номер телефона, но в приложении забыл поменять и продолжает пользоваться аккаунтом со старым номером, то ли еще какие-то проблемы.
Безусловно, запрос должен посылаться с CSRF токеном
Тут хорошо бы уточнить какой запрос. CSRF происходит когда браузер автоматически добавляет токен пользователя к запросу с помощью Cookie. В популярной ныне модели JWT браузер не добавляет токен автоматически в заголовки запроса (это делает приложение), поэтому защита от CSRF тут не нужна. JWT хранится в localStorage, информация в localStorage изолирована между доменами.
Что такое двухфакторная авторизация (2fa)
Сначала рассказываем про авторизацию и аутентификацию, потом пишем это. Ай-ай-ай.
Пароли должны быть зашифрованы стойким алгоритмом по ключу
На фронте? Вы уже провалили собеседование у меня :)
Я бы добавил еще вопрос о том, как можно еще обезопасить форму от перебора. И как вариант - capcha при нескольких неправильных попытках входа. Также можно следить за количеством неудачных попыток (или количеством попыток входа в секунду или за промежуток времени) и вводить какое-то временное ограничение на вход, например "следующую попытку входа можно осуществить через 5 минут"
Не знаю где как, но в РНР даже джуна, если он заикнется про md5, сразу гонят взашей.
Вообще, планка в статье очень сильно занижена. Это где такие сеньоры? JS, Питон? По-хорошему, нормальный сеньор посмотрит на такие вопросы, покрутит пальцем у виска, и пойдет туда, где ему будут задавать вопросы про архитектуру, а не про то, надо ли солить пароль для хэша.
При этом мидл тоже облажался, упомянув SHA-256. Причем облажался дважды — упомянув его рядом с PBKDF2 и bcrypt. То есть понимание того, чем принципиально отличаются эти алгоритмы, и, как следствие — ключевой проблемы хеширования паролей у автора отсутствует.
Так же важно добавлять соль после пароля, а не до. Причиной этому является одно из свойств хэширования — поточное преобразование. В случае, если соль добавлется перед паролем — злоумышленник скорее всего сможет найти соль, учесть её и вычислять уже хэши без учёта этой самой соли.
Это вообще чушь какая-то. Откуда это в статью притащили? Рекомендации журнала "Ксакеп"?
Не знаю где как, но в РНР даже джуна, если он заикнется про md5, сразу гонят взашей
А вам не кажется, что тут не от языка и технологии зависит, а от собеседующего? Или думаете, что в PHP это почему-то более типовая проблема, чем где-либо еще?
а не про то, надо ли солить пароль для хэша.
Вопрос про "надо ли солить" в разделе для Junior, не очень понятно почему у вас это вопрос уровня Senior
При этом мидл тоже облажался, упомянув SHA-256.
Чем облажался? Такой алгоритм не существует?
Причем облажался дважды — упомянув его рядом с PBKDF2 и bcryptPBKDF2 и bcrypt.
Sha-256 упомянут с PBKDF2 и bcrypt не у Middle, а у Senior.
То есть понимание того, чем принципиально отличаются эти алгоритмы, и, как следствие — ключевой проблемы хеширования паролей у автора отсутствует.
Принято, подредактировал статью.
Это вообще чушь какая-то. Откуда это в статью притащили? Рекомендации журнала "Ксакеп"?
Прогуглите md5 length extension attack. Можно еще сюда посмотреть : https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks
При чем здесь собеседующий, если мы говорим об ответах, "хорошо, если мидл назовёт..."?
В РНР это считается не "хорошо", а "вон из профессии". И даже джуны знают, что МД5 для паролей — это табу, потому что за это их бьют по рукам и тыкают носом в специализированную функцию для хэширования паролей. Возможно, в РНР это более типовая проблема, поскольку регистрация пользователей в веб-приложениях есть всегда. И в процессе обучения в обязательном порядке придется столкнуться с хранением паролей.
Для меня вопрос "Как бы вы хранили пароль в базе? Хешированным? Солёным?" звучит как "Надо ли хэшировать и солить пароль?". Возможно, проблема в формулировке, но сейчас это выглядит именно так.
В статье обсуждаются не алгоритмы хэширования вообще, а алгоритмы хэширования паролей. Именно поэтому с SHA-256 и "облажался".
length extension attack является специфичной для MD5, а о применимости этого алгоритма для паролей мы уже говорили выше. Все нормальные алгоритмы к ней, разумеется, невосприимчивы. То есть эта рекомендация — типичный карго культ, из серии "Интернет битком набит шимпанзе"
Спасибо что подредактировали статью, теперь акценты расставлены правильно. Я бы только добавил, что про использование scrypt на практике я не слышал. Судя по всему, из-за того что он не слишком подходит для хэширования паролей. И добавил бы в статью Argon2i.
Но здесь возникает ещё один вопрос. Вот у вас в профиле написано сеньор. Я ни в коем случае не хочу обидеть, я хочу понять. В моём понимании, сеньор должен написать такую статью из головы, хотя бы основные моменты, логику. А не собирать с миру по нитке из интернета, внося потом значительные правки на основании комментариев. Я в последнее время вижу статьи, уровень которых не соответствует заявленному уровню в профиле. И у меня не складывается картинка, не получается рационализировать это.
И добавил бы в статью Argon2i
Принято, добавил. Спасибо
Я ни в коем случае не хочу обидеть, я хочу понять.
Вы же должны понимать, что всех на три категории не поделить (а если и поделить, то как, по мифическому проценту ... чего?). +у разных контор разные требования к тайтлам. Видите, у вас еще +1 понимание сеньора, т.е. кол-во "подтонов" стремится к бесконечности. Так что считаю этот вопрос странным :)
А не собирать с миру по нитке из интернета, внося потом значительные правки на основании комментариев
Все мы учимся. Ваш комментарий импрувнул мою сеньористость на 0.013% (я три часа высчитывал процент!).
И у меня не складывается картинка, не получается рационализировать это
Что ж, похоже и у вас есть векторы для роста :) Если напишете об этом статью - дайте пожалуйста знать, с удовольствием почитаю ваше исследование и выводы ;-)
Ого, сколько комментариев ;-)
Вообще, когда говорят про аутентификацию и авторизацию, я обычно всегда вспоминаю про AAA, еше с курсов по Cisco. Авторизация, Аутентификация, Аккаунтинг.
Как бы вы реализовали форму аутентификации на сайте? Вопрос для собеседования на Junior/Middle/Senior?