Начиналось все просто: у вас есть два набора символов (имя пользователя и пароль) и тот, кто знает оба, может войти в систему. Ничего сложного.
Однако и экосистемы, в которых они функционировали, тоже были простыми — скажем, система с разделением времени от МТИ, которая считается первой компьютерной системой, где применялись пароли.
Но такое положение дел сложилось в шестидесятые годы прошлого века, и с тех пор много воды утекло. Вплоть до последней пары десятилетий у нас было очень небольшое количество учетных записей с ограниченным числом связей, что делало спектр угроз достаточно узким. Навредить вам могли только те, кто находился в непосредственной близости — то есть люди, которые имели возможность напрямую, физически получить доступ в систему. Со временем к ним присоединились и удаленные пользователи, которые могли подключиться через телефон, и спектр угроз расширился. Что произошло после этого, вы и сами знаете: больше взаимосвязей, больше аккаунтов, больше злоумышленников и больше утечек данных, особенно в последние годы. Изначальная схема с простой сверкой символов уже не кажется такой уж блестящей идеей.
Пару месяцев назад я писал о многоразовом использовании паролей, вбросе регистрационных данных и о том, что в базу сервиса Have I been pwned был добавлен очередной миллиард записей. Дела обстоят так: миллиарды реквизитов доступа лежат и ждут, когда какой-нибудь злодей начнет использовать их для взлома любого сайта, какой ему понравится. Это ставит перед нами очень интересный вопрос: как защитить себя в таких обстоятельствах? В смысле, вы тут пытаетесь удержать на плаву онлайн-систему, а у какого-то типа со стороны есть рабочие данные от учетных записей некоторых пользователей — как ему запретишь войти в систему? Простым сопоставлением символов родом из шестидесятых тут уже не обойдешься.
Но эволюция аутентификации не сводится к бесконечному расширению баз для вброса регистрационных данных — процесс входа в систему изменился и во многих других отношениях. В некоторых случаях это привело к тому, что все перевернулось с ног на головы, и те истины о создании и управлении аккаунтами, которые когда-то считались прописными, теперь уже неактуальны. Тем не менее, мы можем видеть, как некоторые организации и сегодня применяют устаревшие схемы к современным угрозам. Данный пост ставит своей целью проанализировать это несоответствие и объяснить, как на самом деле нужно проектировать эту критически важную часть системы в наше время. Надеюсь, когда-нибудь он станет тем ресурсом, куда доброжелатели будут отправлять компании, которые говорят: «Мы делаем эту глупость ради безопасности».
Начну с отсылок к другим источникам, потому что в Сети за последнее время появилось много хороших материалов на эту тему, и я буду к ним обращаться. Хочу выложить все это сразу, чтобы прояснить один момент: большая часть рекомендаций, которые будут приводиться дальше, — это не просто мой личный взгляд на проблему, а прямое цитирование таких организаций, как Национальный институт стандартов и технологий (National Institute of Standards and Technologies, или NIST). На самом деле, их труд Digital Identity Guidelines, который вышел буквально в прошлом месяце, пожалуй, можно считать тем толчком, который побудил меня взяться за этот пост — столько там было всего интересного.
Национальный центр по кибербезопасности (National Cyber Security Centre) правительства Великобритании — еще один замечательный ресурс, данные которого я буду использовать. Они регулярно публикуют очень содержательные статьи на тему безопасности, и представляют один из редких примеров правительственного учреждения, которое действительно «соображает» в IT-сфере.
Также я буду обращаться к исследованию Microsoft's Password Guidance от команды Identity Protection. На первой его странице говорится, что Microsoft находится в «уникальном положении для понимания роли паролей в захвате аккаунтов», благодаря тому, что ежедневно переживает по 10 миллионов атак, так что опыта у этих ребят точно хватает! Это очень практичное руководство, составленное людьми, которые явно досконально продумали, как обезопасить свои онлайн-аккаунты.
Уверен, что есть и другие интересные материалы, и буду рад, если вы поделитесь своими находками в комментариях. Здесь я перечислил только несколько источников, дальше по тексту вы найдете отсылки и на многие другие. Ну, приступим!
Для начала посмотрим на процесс аутентификации с более философской точки зрения: пока вы не зашли в систему, у вас нет доступа ни к каким ее компонентам, потом вы заходите и получаете доступ ко всему, что прописано у вас в правах. Никакой серой зоны — либо так, либо эдак.
Одна из замечательных тенденций, которые мы наблюдаем в ИБ-секторе в последнее время — дифференциация уровней угрозы и доверия, то есть осознание того, что в каких-то сценариях, связанных с потенциальным риском (таких, как вход в систему), мы чувствуем больше доверия к пользователю, а в каких-то — меньше. Для примера: вместо того, чтобы разрешать определенное число попыток входа, скажем, пять (замечали, что число почему-то всегда нечетное?), а затем просто блокировать аккаунт, возможно, стоит добавить шаг с вводом капчи после трех. Таким образом, мы показываем, что уровень доверия к пользователю снизился и мы вынуждены принять дополнительные меры, чтобы удостовериться, что система не подвергается автоматизированной атаке. Для ботов это серьезное препятствие, а для пользователей — легкое неудобство, к тому же, при необходимости можно все-таки заблокировать аккаунт после еще нескольких неудачных попыток.
Продолжая мысль, стоит ли при давать пользователям доступ ко всем возможностям сразу при успешном входе? Допустим, они не с первого раза правильно ввели пароль и пришли с браузера, который раньше не использовали, и из другой страны — предоставлять ли им в таком случае неограниченный доступ ко всему? Или лучше ограничиться самыми базовыми функциями и потребовать доказательств, что указанный адрес действительно принадлежит пользователю, прежде чем дать ему возможность производить какие-то серьезные операции?
С помощью этих простых примеров я пытаюсь навести читателей на мысль, что можно действовать умнее, чем позволяют традиционные бинарные системы, до сих пор превалирующие в большинстве сервисов. Эта темы будет развиваться в тексте и дальше.
Теперь давайте углубимся в техническую составляющую и начнем с простого: то, что вы видите ниже — не лучшая политика для создания паролей.
Первое предложение во всплывающем окошке («Длина пароля должна составлять 8-10 символов») представляет, наверное, самый распространенный из ошибочных анти-паттернов по созданию паролей: маленькая заданная длина пароля. Это убивает менеджеры паролей (позже мы остановимся на них подробнее), это убивает пароли-фразы и, как следствие, это убивает юзабилити. Кстати о юзабилити: приведенный скриншот я взял из своей прошлогодней статьи о том, как мы допускаем ошибки в самых базовых вещах, и, помимо неэффективной политики Etihad (принятой, между прочим, «ради безопасности»), я описываю в нем случай, когда Paypal фактически перекрыл мне доступ к аккаунту благодаря политике подобного же рода.
Вдобавок к озвученным выше проблемам, низкий лимит по длине часто внушает людям подозрения, что хранение паролей плохо организовано. После криптографического хеширования все хранящиеся пароли имеют одинаковую фиксированную длину, поэтому подобные произвольные ограничения могут означать, что пароли хранятся в виде обычного текста и колонка вмещает только десять символов. Конечно, причина может быть и другой, но, сами понимаете, такие предположения небезосновательны.
Какое тогда ограничение по длине нужно ставить? «Никакого» — неправильный ответ, потому что за определенным рубежом у вас появятся уже другие проблемы. Например, если размер превысит четыре мегабайта, вы не уложитесь в размеры запроса по умолчанию в ASP.NET. Вот что говорит по этому поводу NIST:
Ни один нормальный человек, регистрируясь на сайте с ограничением по длине пароля в 64 символа, не скажет: «Что за лажа у них безопасностью, мне даже не дали сделать пароль длиннее 64 символов». Но на всякий случай можете задать ограничение в 100 символов. Или подхватить идею NIST, и установить максимум в 256 символов — какая разница, все равно после хеширования все выровняется.
NIST указывает на еще один важный, хотя не настолько лежащий на поверхности момент:
Это, на самом деле, самые базовые вещи: не задавайте маленькую длину и не урезайте конечные символы у предложенного пользователем пароля. На худой конец, компании, которые защищают правомерность такой практики, должны добавлять: «Мы знаем, что так нельзя, у нас проблемы с наследственностью, мы внесем это в список на срочную доработку».
Я хочу рассмотреть два аспекта использования специальных символов. Начну с этого:
Обычно некоторые символы в паролях использовать запрещается. Это правило вводится для защиты от возможных атак. Скажем, угловые скобки могут использоваться в XSS атаках, а апострофы — при внедрении SQL-кода. Но подобные аргументы показывают, что в профиле безопасности сайта есть серьезные недостатки. Во-первых, пароли ни в коем случае нельзя выводить на интерфейс из-за угрозы межсайтового скриптинга; во-вторых, пароли не должны отсылаться в базу данных без хеширования, после которого остаются только алфавитно-цифровые символы. Ну и конечно, даже если вы нарушаете эти правила, отображая пароли в интерфейсе и сохраняя их в базе данных в виде обычного текста, у вас остается кодировка при выводе и параметризация.
NIST выражается по этому поводу вполне однозначно — не делайте так:
Стоит особо отметить их оговорку насчет символов Юникода — были прецеденты, когда разработчики накладывали запрет на вполне приемлемые с точки зрения языка символы просто потому, что они якобы выходили за рамки «нормальных». С другой стороны, конечно, встречаются и пароли вроде такого:
Что ж, если кому-то так уж хочется поставить паролем первый куплет «Отпусти и забудь» из «Холодного сердца», записанный смайликами — пожалуйста!
О другом аспекте, которого я хотел коснуться, также упоминает NIST:
Погодите, как так?! То есть людям необязательно включать в пароль заглавные, строчные буквы, цифры и символы?! Это настолько противоречит общепринятому подходу, что приходится сесть и обдумать все логически, чтобы понять, что они правы. В качестве иллюстрации: недавно я писал о том, как оценка пароля системой как «хорошего» или «плохого» подталкивает людей к неверным решениям. Базовый посыл был такой: чисто математический подход не помогает нам придумывать хорошие пароли. Подобные требования допускают пароли типа «Пароль!» и отсекают пароли-фразы только потому, что они не содержат заглавных букв.
В документе, о котором я упоминал выше, Microsoft вторит рекомендации от NIST:
При наличии требований к сложности пароля ситуация обычно разворачивается так: люди сначала пробуют ввести что-то примитивное, а потом подправляют символы, пока не включат самый минимум обязательных составляющих. Microsoft раскрывает эту проблему так:
В итоге пароль все равно получится плохой, причем скорее всего пользователь его уже где-нибудь использовал и раньше. Все, чего можно добиться этими мерами, — потрепать пользователю нервы без какого-либо результата!
По моим личным наблюдениям, сейчас подсказки уже далеко не так популярны, как были когда-то. Эта идея брала начало в «слушайте, люди постоянно забывают пароли, давайте помогать им вспомнить!» и выливалась в то, что при создании аккаунта пользователь получал возможность ввести не только пароль, но и подсказку к нему. Проблема состоит в том, что эту подсказку будут показывать неавторизованным пользователям — ведь только на этом этапе она и нужна. Еще одна проблема состоит в том, что эта информация вводится самим пользователем и, соответственно, скорее всего будет ужас кромешный.
Компания Adobe хранила подсказки к паролям в своей базе данных, которая попала в открытый доступ в 2013 году. Чтобы продемонстрировать, насколько все плохо, я просмотрел эту базу и решил поделиться отдельными образчиками:
Все они хранились в виде обычного текста, так что можете себе представить, что произошло, когда система была взломана. Ясно, почему NIST считает, что это плохая идея:
Как я уже говорил, сейчас подсказки и так редко увидишь в онлайн-системах, но просто на случай, если вы о чем-то таком задумывались — не вздумайте!
Я давно уже твержу о том, какую ценность в себе несут менеджеры паролей — аж с начала 2011 года, когда написал в одной из статей, что единственный надежный пароль — это тот, который вы не знаете на память. Мысль проста и изложить ее можно буквально в нескольких пунктах:
Сейчас кто-то возразит, что использовать менеджер паролей — значит собирать все в одном месте, и будет прав: если кто-то проникнет в это место, у вас будут крупные неприятности. Но это очень редкое явление по сравнению со случаями взлома отдельных сервисов и последующей утечки данных учетных записей. Более того, как я недавно говорил, менеджерам паролей необязательно быть идеальными, достаточно, чтобы с ними было лучше, чем без них.
Но этот пост писался не как руководство для пользователей по созданию хороших паролей, он предназначен для тех, кто создает сервисы. Соответственно, как бы лично вы ни относились к менеджерам паролей, вот так поступать не стоит:
Добрый день! Мы не рекомендуем использовать менеджер паролей, ваш девайс могут взломать.
Такая близорукость встречается часто, я могу с ходу найти десяток подобных твитов. Они вообще не принимают во внимание те три пункта, которых я коснулся выше, и фактически говорят примерно следующее: «Эй, создавайте простые для запоминания пароли, они, конечно, будут слабыми и, скорее всего, вы будете их повторять из аккаунта в аккаунт, но так надо ради безопасности».
NCSC прямым текстом говорит об этой проблеме: в инфографике к руководству Password Guidance: Simplifying Your Approach у них есть такой фрагмент:
Создавайте для пользователей возможность безопасного хранения паролей
Иными словами, не ломайте менеджеры паролей и не делайте таких заявлений, как в приведенном твите. Но NCSC идет еще дальше и предлагает следующую рекомендацию, явно с расчетом на то, чтобы организации давали своим сотрудникам возможность создавать пароли и управлять ими, не рискуя безопасностью:
Задумайтесь о том, в какой обстановке работаете в данный момент. Есть ли какие-то критерии надежности паролей? Проводятся ли ежегодные тренинги или, может, на стенах висят плакаты, призывающие создавать уникальные, сложные пароли? Конечно, какой-то контроль и инструктаж, связанный с паролями, точно присутствует, но обеспечивают ли вам «санкционированный механизм», который помогал бы достичь поставленных целей? Скорее всего нет, и я говорю об этом с такой уверенностью потому, что часто задаю этот вопрос, когда провожу тренинги в различных организациях. Удивительно, как часто приходится видеть такую несостыковку.
С использованием менеджера паролей тесно связана возможность вставлять пароли в поле ввода. Существует множество менеджеров паролей, которые заполняют поля автоматически, но бывают и такие случаи, когда все равно приходится пользоваться вставкой или же сервис блокирует попытки ввести пароль не вручную (это легко проверить при помощи JavaScript). В результате получается следующее:
В 2014 году я писал об «эффекте кобры», который возникает, когда в поле пароля запрещена вставка. Я подробно объясняю значение этого термина в статье по ссылке, но если резюмировать вкратце: эффект кобры проявляется, когда попытка решить проблему ее только усугубляет. Когда на сайте блокируют возможность вставить пароль, чтобы обеспечить безопасность, это заставляет некоторых пользователей упрощать пароли, пока они не станут такими примитивными, что напечатать их не составит труда.
NCSC меня и здесь поддерживают:
Они даже ввели специальный термин для обозначения этого анти-паттерна — SPP (Stop Pasting Passwords, «Хватит вставлять пароли») и развенчивают популярные мифы о рисках, связанных со вставкой паролей. Они упоминают и мою статью, где говорилось об эффекте кобры — приятно получать такую протекцию от британского правительства!
NIST присоединяется к позиции NCSC, о чем свидетельствует их высказывание:
Так что даже не сомневайтесь: люди по обе стороны Атлантического океана единодушно поддерживают использование менеджеров паролей и выступают против активных действий по их блокировке.
На своей предыдущей работе в частной компании я придумал простой способ вычислить, сколько я уже использую свой текущий пароль: просто брал число, которое в нем содержалось и которое я увеличивал раз в квартал, когда компания требовала заменить пароль, и делил его на четыре. Таким образом я растянул один-единственный пароль почти на шесть лет, каждый раз меняя в нем не более пары символов. Если у вас на работе тоже заведено регулярно менять пароли, вы, вероятно, поступаете так же — ведь это легкий и естественный выход из положения, когда сталкиваешься с техническим требованием, которое доставляет неудобства.
Давайте разберем обоснование такого подхода: аргумент в пользу периодического обновления паролей состоит в том, что если пароль попадет в чужие руки, после вынужденной замены он станет неактуальным, а значит мошенники не смогут им воспользоваться. Проблема здесь в том, что в моем примере у хакеров было до трех месяцев времени, а в других случаях, возможно, и больше:
Если так подумать, хакеры обычно не выжидают сложа руки, они сразу принимаются за работу с аккаунтами, пытаясь извлечь из них выгоду. Команда Lifeboat не учла этого соображения в своих попытках загладить последствия прошлогодней утечки данных, и цепочка рассуждений получилась неверная:
Как упоминалось в приведенном выше твите, NCSC разделяет мнение, что на сегодняшний день вынужденная замена паролей — это анти-патерн в информационной безопасности. Вот что они говорят об этой практике в своем руководстве по управлению паролями:
Они выносят эту мысль и в инфографику:
Просите пользователей поменять пароль только в том случае, если появились признаки или подозрения, что старый пароль скомпрометирован.
Microsoft высказывается в том же духе:
Их слова, конечно не следует понимать как «не вынуждайте пользователей менять пароли, и больше от вас ничего не требуется». Это скорее указание на то, что необходим более широкий, более продвинутый подход к управлению паролями. Например, NCSC также дает и такие рекомендации:
И тут мы плавно переходим к следующему разделу.
Это важный аспект «продвинутого» подхода к процессу аутентификации и вполне возможно, что вы уже наблюдали его в действии. Недавно я зашел на свой аккаунт в Yammer cо своего нового Lenovo Yoga 910 — до того момента я не пользовался их сервисом на этой машине. Чуть позже мне пришло такое оповещение:
Позже я зашел на Dropbox через бразуер на той же машине и сразу же получил сообщение:
Разумеется, эти письма никак не помешали мне зайти в систему и, само собой, на моем месте мог бы быть злоумышленник, заполучивший реквизиты доступа жертвы. Но они немедленно оповестили меня о произошедшем, и это имеет огромную ценность — руководствуясь этой информацией, я мог бы при необходимости пойти и выгнать того, кто вторгся в мою учетную запись. Dropbox даже показал мне все девайсы, которые я авторизовал за последние пять лет, и предоставил возможность отменить авторизацию.
Возможность отслеживать таким образом поведение аккаунта очень полезна; например, можно посмотреть на каких девайсах в данный момент осуществлен вход на мой аккаунт в Facebook.
Как и в случае с Dropbox и Yammer, здесь также предлагается опция выйти из системы на любом девайсе из списка. А это значит, что законный владелец может хоть в какой-то степени вернуть себе контроль над аккаунтом в ситуации, когда кто-то получил к нему несанкционированный доступ. Многие из современных сервисов предлагают такую возможность; хороший пример тому — Github, который приводит еще более подробную информацию, включая IP адрес и конкретные события, значимые с точки зрения безопасности, например, запрос на двухфакторную идентификацию или создание открытого ключа.
Вот еще один возможный сценарий:
Хотелось бы, чтобы мне сообщали о попытках входа, когда пароль вводился верный, но двухфакторная идентификация не проходила. Это явно говорит о том, что пароль попал в чужие руки.
Это также представляется очень разумным, и когда задумываешься о различных сценариях, в которых стоило бы проявить инициативу и предупредить пользователя, начинаешь понимать, как много можно сделать с минимальными затратами труда.
Вернемся на минутку к вбросам регистрационных данных и всему с ними связанному. Если пароли где-то засветили, их следует считать «оскверненными» — в том смысле, что использовать их больше нельзя. Никогда. Теперь, когда они побывали в открытом доступе, огромное количество людей располагает информацией об этих реквизитах, что существенно повышает риски для тех, кто их использует. Только представьте: доступ к миллиарду пар e-mail адрес-пароль, взятых из утечек реальных данных, о которых я распространялся в посте о вбросах регистрационных данных:
NIST говорит об этой проблеме следующее:
Говоря простым языком: когда кто-нибудь создает аккаунт или меняет пароль, вы должны следить, чтобы этот пароль не входил в число тех, которые фигурировали в утечках данных. Неважно, что это, возможно, не тот же самый пользователь, который устанавливал пароль на взломанный аккаунт — одно то, что пароль оказался в публичном доступе, повышает вероятность его использования в хакерских атаках. В цитате также упоминается, что пароль не должен представлять собой слово в его словарной форме или «слово, порожденное контекстом». Описывая случай, когда база данных CloudPets оказалась в общем доступе, я обращал внимание читателей на то, что хеши-строки bcrypt крайне легко взломать при помощи небольшого словаря паролей, в число которых входят и такие слова как «cloudpets». Не давайте пользователям возможность ставить в качестве пароля название ресурса, на котором они регистрируются — а то ведь они именно так и поступят!
Есть много других тонкостей, которые я умышленно не стал включать в эту статью. Скажем, разнообразные механизмы многошаговой верификации, которые сейчас доступны, — о них, кстати, говорит и NIST в своей документации. Здесь я хотел сосредоточиться на самых базовых принципах, хотя, конечно, дополнительные слои защиты (например, приложение для аутентификации) значительно улучшают ситуацию с безопасностью — жаль, что ими почти никто не пользуется.
В январе прошлого года только 1% пользователей Dropbox использовали двухфакторную идентификацию (еще до утечки данных)
Еще один аспект, которого стоило бы коснуться — это возможность выявлять и отражать автоматизированные хакерские атаки. Задумайтесь: насколько ваша система подготовлена к тому, чтобы идентифицировать неожиданный наплыв попыток войти в систему как атаку, например, при вбросе регистрационных данных? Все выяснится, только когда пользователи начнут массово сообщать о взломе аккаунтов, или вы с самого начала будете в курсе? А если, предположим, вам удалось обнаружить атаку, сможете ли вы немедленно провести контрмеры, чтобы минимизировать риски? Например, как на Cloudpet, где можно проставить нужный уровень защиты?
Также я не разбирал подробно способы хранения паролей, решив уделить основное внимание тем составляющим политики аутентификации, которые можно увидеть невооруженным глазом. Чтобы не оставлять эту тему совсем не затронутой, предлагаю вам ознакомиться с Password Storage Cheat Sheet от OWASP и почерпнуть там все необходимые напутствия. Вдобавок советую внимательно прочитать статью о том, как Dropbox хранит ваши пароли — это очень интересный текст, где современный подход к хешированию сочетается с шифрованием.
Представленные проблемы не исчерпываются тем, что я здесь написал. Суть в том, что принципы, намеченные мной выше, должны в наши дни быть обязательным минимумом, но это не значит, что вы должны останавливаться на этом этапе.
Вот общая картина того, что признают все эти руководства от правительственных учреждений и IT-компаний: безопасность все чаще связывается с комбинацией элементов управления, которые в совокупности обеспечивают более надежную защиту. В этом посте вы найдете набор рекомендаций, которые, дополняя друг друга, помогают создать мощное решение. Соотвественно, отдельные рекомендации, такие как отказ от требований к сложности, могут на первый взгляд показаться странными, но когда вы вдумаетесь в то, как люди обычно действуют в реальности (просто выбирают плохие пароли с комбинацией из разных типов символов), и примете во внимание другие инструкции, например, совет блокировать ранее взломанные пароли, все начинает становиться на свои места.
И вот еще что: теоретически все эти руководства – вещь хорошая, однако реализовать их на практике может быть несколько сложнее. Я собираюсь развить эту тему в следующем посте, который выйдет на этой неделе. Там я собираюсь рассказать кое-что интересное и новое, что поможет владельцам сайтов обеспечить безопасность своим подписчикам. Я работал над ним в течение нескольких недель, потратил немало сил и собираюсь поделиться с вами результатом бесплатно, так что заглядывайте в ближайшее время на мой сайт. Также я намерен обновить этот пост, добавив ссылку на ресурс, как только выложу его в открытый доступ. Следите за обновлениями!
Однако и экосистемы, в которых они функционировали, тоже были простыми — скажем, система с разделением времени от МТИ, которая считается первой компьютерной системой, где применялись пароли.
Но такое положение дел сложилось в шестидесятые годы прошлого века, и с тех пор много воды утекло. Вплоть до последней пары десятилетий у нас было очень небольшое количество учетных записей с ограниченным числом связей, что делало спектр угроз достаточно узким. Навредить вам могли только те, кто находился в непосредственной близости — то есть люди, которые имели возможность напрямую, физически получить доступ в систему. Со временем к ним присоединились и удаленные пользователи, которые могли подключиться через телефон, и спектр угроз расширился. Что произошло после этого, вы и сами знаете: больше взаимосвязей, больше аккаунтов, больше злоумышленников и больше утечек данных, особенно в последние годы. Изначальная схема с простой сверкой символов уже не кажется такой уж блестящей идеей.
Пару месяцев назад я писал о многоразовом использовании паролей, вбросе регистрационных данных и о том, что в базу сервиса Have I been pwned был добавлен очередной миллиард записей. Дела обстоят так: миллиарды реквизитов доступа лежат и ждут, когда какой-нибудь злодей начнет использовать их для взлома любого сайта, какой ему понравится. Это ставит перед нами очень интересный вопрос: как защитить себя в таких обстоятельствах? В смысле, вы тут пытаетесь удержать на плаву онлайн-систему, а у какого-то типа со стороны есть рабочие данные от учетных записей некоторых пользователей — как ему запретишь войти в систему? Простым сопоставлением символов родом из шестидесятых тут уже не обойдешься.
Но эволюция аутентификации не сводится к бесконечному расширению баз для вброса регистрационных данных — процесс входа в систему изменился и во многих других отношениях. В некоторых случаях это привело к тому, что все перевернулось с ног на головы, и те истины о создании и управлении аккаунтами, которые когда-то считались прописными, теперь уже неактуальны. Тем не менее, мы можем видеть, как некоторые организации и сегодня применяют устаревшие схемы к современным угрозам. Данный пост ставит своей целью проанализировать это несоответствие и объяснить, как на самом деле нужно проектировать эту критически важную часть системы в наше время. Надеюсь, когда-нибудь он станет тем ресурсом, куда доброжелатели будут отправлять компании, которые говорят: «Мы делаем эту глупость ради безопасности».
Слушайте, что говорит правительство (и толковые IT-компании)
Начну с отсылок к другим источникам, потому что в Сети за последнее время появилось много хороших материалов на эту тему, и я буду к ним обращаться. Хочу выложить все это сразу, чтобы прояснить один момент: большая часть рекомендаций, которые будут приводиться дальше, — это не просто мой личный взгляд на проблему, а прямое цитирование таких организаций, как Национальный институт стандартов и технологий (National Institute of Standards and Technologies, или NIST). На самом деле, их труд Digital Identity Guidelines, который вышел буквально в прошлом месяце, пожалуй, можно считать тем толчком, который побудил меня взяться за этот пост — столько там было всего интересного.
Национальный центр по кибербезопасности (National Cyber Security Centre) правительства Великобритании — еще один замечательный ресурс, данные которого я буду использовать. Они регулярно публикуют очень содержательные статьи на тему безопасности, и представляют один из редких примеров правительственного учреждения, которое действительно «соображает» в IT-сфере.
Также я буду обращаться к исследованию Microsoft's Password Guidance от команды Identity Protection. На первой его странице говорится, что Microsoft находится в «уникальном положении для понимания роли паролей в захвате аккаунтов», благодаря тому, что ежедневно переживает по 10 миллионов атак, так что опыта у этих ребят точно хватает! Это очень практичное руководство, составленное людьми, которые явно досконально продумали, как обезопасить свои онлайн-аккаунты.
Уверен, что есть и другие интересные материалы, и буду рад, если вы поделитесь своими находками в комментариях. Здесь я перечислил только несколько источников, дальше по тексту вы найдете отсылки и на многие другие. Ну, приступим!
Процесс аутентификации не должен сводиться к переключению между двумя состояниями
Для начала посмотрим на процесс аутентификации с более философской точки зрения: пока вы не зашли в систему, у вас нет доступа ни к каким ее компонентам, потом вы заходите и получаете доступ ко всему, что прописано у вас в правах. Никакой серой зоны — либо так, либо эдак.
Одна из замечательных тенденций, которые мы наблюдаем в ИБ-секторе в последнее время — дифференциация уровней угрозы и доверия, то есть осознание того, что в каких-то сценариях, связанных с потенциальным риском (таких, как вход в систему), мы чувствуем больше доверия к пользователю, а в каких-то — меньше. Для примера: вместо того, чтобы разрешать определенное число попыток входа, скажем, пять (замечали, что число почему-то всегда нечетное?), а затем просто блокировать аккаунт, возможно, стоит добавить шаг с вводом капчи после трех. Таким образом, мы показываем, что уровень доверия к пользователю снизился и мы вынуждены принять дополнительные меры, чтобы удостовериться, что система не подвергается автоматизированной атаке. Для ботов это серьезное препятствие, а для пользователей — легкое неудобство, к тому же, при необходимости можно все-таки заблокировать аккаунт после еще нескольких неудачных попыток.
Продолжая мысль, стоит ли при давать пользователям доступ ко всем возможностям сразу при успешном входе? Допустим, они не с первого раза правильно ввели пароль и пришли с браузера, который раньше не использовали, и из другой страны — предоставлять ли им в таком случае неограниченный доступ ко всему? Или лучше ограничиться самыми базовыми функциями и потребовать доказательств, что указанный адрес действительно принадлежит пользователю, прежде чем дать ему возможность производить какие-то серьезные операции?
С помощью этих простых примеров я пытаюсь навести читателей на мысль, что можно действовать умнее, чем позволяют традиционные бинарные системы, до сих пор превалирующие в большинстве сервисов. Эта темы будет развиваться в тексте и дальше.
Чем длиннее, тем лучше (как правило)
Теперь давайте углубимся в техническую составляющую и начнем с простого: то, что вы видите ниже — не лучшая политика для создания паролей.
Первое предложение во всплывающем окошке («Длина пароля должна составлять 8-10 символов») представляет, наверное, самый распространенный из ошибочных анти-паттернов по созданию паролей: маленькая заданная длина пароля. Это убивает менеджеры паролей (позже мы остановимся на них подробнее), это убивает пароли-фразы и, как следствие, это убивает юзабилити. Кстати о юзабилити: приведенный скриншот я взял из своей прошлогодней статьи о том, как мы допускаем ошибки в самых базовых вещах, и, помимо неэффективной политики Etihad (принятой, между прочим, «ради безопасности»), я описываю в нем случай, когда Paypal фактически перекрыл мне доступ к аккаунту благодаря политике подобного же рода.
Вдобавок к озвученным выше проблемам, низкий лимит по длине часто внушает людям подозрения, что хранение паролей плохо организовано. После криптографического хеширования все хранящиеся пароли имеют одинаковую фиксированную длину, поэтому подобные произвольные ограничения могут означать, что пароли хранятся в виде обычного текста и колонка вмещает только десять символов. Конечно, причина может быть и другой, но, сами понимаете, такие предположения небезосновательны.
Какое тогда ограничение по длине нужно ставить? «Никакого» — неправильный ответ, потому что за определенным рубежом у вас появятся уже другие проблемы. Например, если размер превысит четыре мегабайта, вы не уложитесь в размеры запроса по умолчанию в ASP.NET. Вот что говорит по этому поводу NIST:
Верификаторы должны разрешать ввод любого секретного кода длиной до 64 символов на выбор подписчика.
Ни один нормальный человек, регистрируясь на сайте с ограничением по длине пароля в 64 символа, не скажет: «Что за лажа у них безопасностью, мне даже не дали сделать пароль длиннее 64 символов». Но на всякий случай можете задать ограничение в 100 символов. Или подхватить идею NIST, и установить максимум в 256 символов — какая разница, все равно после хеширования все выровняется.
NIST указывает на еще один важный, хотя не настолько лежащий на поверхности момент:
Усечение секретного кода не допускается.
Это, на самом деле, самые базовые вещи: не задавайте маленькую длину и не урезайте конечные символы у предложенного пользователем пароля. На худой конец, компании, которые защищают правомерность такой практики, должны добавлять: «Мы знаем, что так нельзя, у нас проблемы с наследственностью, мы внесем это в список на срочную доработку».
Все символы особенные (но включать их необязательно)
Я хочу рассмотреть два аспекта использования специальных символов. Начну с этого:
Обычно некоторые символы в паролях использовать запрещается. Это правило вводится для защиты от возможных атак. Скажем, угловые скобки могут использоваться в XSS атаках, а апострофы — при внедрении SQL-кода. Но подобные аргументы показывают, что в профиле безопасности сайта есть серьезные недостатки. Во-первых, пароли ни в коем случае нельзя выводить на интерфейс из-за угрозы межсайтового скриптинга; во-вторых, пароли не должны отсылаться в базу данных без хеширования, после которого остаются только алфавитно-цифровые символы. Ну и конечно, даже если вы нарушаете эти правила, отображая пароли в интерфейсе и сохраняя их в базе данных в виде обычного текста, у вас остается кодировка при выводе и параметризация.
NIST выражается по этому поводу вполне однозначно — не делайте так:
В секретных кодах должно допускаться использование любых печатных символов ASCII [RFC 20], включая пробел. Символы Юникода [ISO/ISC 10646] также должны приниматься.
Стоит особо отметить их оговорку насчет символов Юникода — были прецеденты, когда разработчики накладывали запрет на вполне приемлемые с точки зрения языка символы просто потому, что они якобы выходили за рамки «нормальных». С другой стороны, конечно, встречаются и пароли вроде такого:
Что ж, если кому-то так уж хочется поставить паролем первый куплет «Отпусти и забудь» из «Холодного сердца», записанный смайликами — пожалуйста!
О другом аспекте, которого я хотел коснуться, также упоминает NIST:
Верификаторы не должны вводить дополнительные правила составления секретного кода (например, требовать использования разных типов символов или запрещать вводить одинаковые символы подряд).
Погодите, как так?! То есть людям необязательно включать в пароль заглавные, строчные буквы, цифры и символы?! Это настолько противоречит общепринятому подходу, что приходится сесть и обдумать все логически, чтобы понять, что они правы. В качестве иллюстрации: недавно я писал о том, как оценка пароля системой как «хорошего» или «плохого» подталкивает людей к неверным решениям. Базовый посыл был такой: чисто математический подход не помогает нам придумывать хорошие пароли. Подобные требования допускают пароли типа «Пароль!» и отсекают пароли-фразы только потому, что они не содержат заглавных букв.
В документе, о котором я упоминал выше, Microsoft вторит рекомендации от NIST:
Откажитесь от требований к составу пароля.
При наличии требований к сложности пароля ситуация обычно разворачивается так: люди сначала пробуют ввести что-то примитивное, а потом подправляют символы, пока не включат самый минимум обязательных составляющих. Microsoft раскрывает эту проблему так:
По большей части люди прибегают к одним и тем же паттернам (первая буква — заглавная, специальный символ или две цифры в конце). Кибер-мошенникам это известно, поэтому, осуществляя перебор по словарю, они включают все замены, выполненные по стандартным схемам («$» вместо «s», «@» вместо «a», «1» вместо «l» и так далее).
В итоге пароль все равно получится плохой, причем скорее всего пользователь его уже где-нибудь использовал и раньше. Все, чего можно добиться этими мерами, — потрепать пользователю нервы без какого-либо результата!
Подсказки? Ни в коем случае!
По моим личным наблюдениям, сейчас подсказки уже далеко не так популярны, как были когда-то. Эта идея брала начало в «слушайте, люди постоянно забывают пароли, давайте помогать им вспомнить!» и выливалась в то, что при создании аккаунта пользователь получал возможность ввести не только пароль, но и подсказку к нему. Проблема состоит в том, что эту подсказку будут показывать неавторизованным пользователям — ведь только на этом этапе она и нужна. Еще одна проблема состоит в том, что эта информация вводится самим пользователем и, соответственно, скорее всего будет ужас кромешный.
Компания Adobe хранила подсказки к паролям в своей базе данных, которая попала в открытый доступ в 2013 году. Чтобы продемонстрировать, насколько все плохо, я просмотрел эту базу и решил поделиться отдельными образчиками:
- мое имя
- adobe
- как обычно
- пароль
Все они хранились в виде обычного текста, так что можете себе представить, что произошло, когда система была взломана. Ясно, почему NIST считает, что это плохая идея:
Верификаторы секретного кода не должны допускать, чтобы подписчики оставляли «подсказку», которая будет доступна неавторизованному лицу при попытке войти в систему.
Как я уже говорил, сейчас подсказки и так редко увидишь в онлайн-системах, но просто на случай, если вы о чем-то таком задумывались — не вздумайте!
Полюбите менеджеры паролей
Я давно уже твержу о том, какую ценность в себе несут менеджеры паролей — аж с начала 2011 года, когда написал в одной из статей, что единственный надежный пароль — это тот, который вы не знаете на память. Мысль проста и изложить ее можно буквально в нескольких пунктах:
- Мы знаем, что пароли должны быть «надежными», то есть их должно быть сложно угадать или вычислить методом полного перебора. Иными словами, чем больше символов и чем более случайным образом они подобраны, тем лучше.
- Мы знаем, что использовать один пароль несколько раз нельзя: если один сервис взломают, то аккаунты пользователя на других ресурсах окажутся под угрозой. Проблема с вбросами регистрационных данных, о которой я упоминал выше, заключается как раз в этом.
- Люди не могут придумывать и заучивать надежные, уникальные пароли для каждого сервиса, полагаясь только на свою память.
Сейчас кто-то возразит, что использовать менеджер паролей — значит собирать все в одном месте, и будет прав: если кто-то проникнет в это место, у вас будут крупные неприятности. Но это очень редкое явление по сравнению со случаями взлома отдельных сервисов и последующей утечки данных учетных записей. Более того, как я недавно говорил, менеджерам паролей необязательно быть идеальными, достаточно, чтобы с ними было лучше, чем без них.
Но этот пост писался не как руководство для пользователей по созданию хороших паролей, он предназначен для тех, кто создает сервисы. Соответственно, как бы лично вы ни относились к менеджерам паролей, вот так поступать не стоит:
Добрый день! Мы не рекомендуем использовать менеджер паролей, ваш девайс могут взломать.
Такая близорукость встречается часто, я могу с ходу найти десяток подобных твитов. Они вообще не принимают во внимание те три пункта, которых я коснулся выше, и фактически говорят примерно следующее: «Эй, создавайте простые для запоминания пароли, они, конечно, будут слабыми и, скорее всего, вы будете их повторять из аккаунта в аккаунт, но так надо ради безопасности».
NCSC прямым текстом говорит об этой проблеме: в инфографике к руководству Password Guidance: Simplifying Your Approach у них есть такой фрагмент:
Создавайте для пользователей возможность безопасного хранения паролей
Иными словами, не ломайте менеджеры паролей и не делайте таких заявлений, как в приведенном твите. Но NCSC идет еще дальше и предлагает следующую рекомендацию, явно с расчетом на то, чтобы организации давали своим сотрудникам возможность создавать пароли и управлять ими, не рискуя безопасностью:
Вы также должны обеспечивать соответствующее оборудование для хранения паролей с уровнем защиты, соответствующим конфиденциальности информации, которую вы стремитесь обезопасить. Эти хранилища могут быть как материальными (например, сейфы), так и техническими (например, особые программы для управления паролями) или сочетать в себе аспекты тех и других. Крайне важно, чтобы ваша организация предоставляла санкционированный механизм, который помогал бы пользователям осуществлять контроль над паролями: это избавит их от необходимости прибегать к ненадежным «скрытым» методам, чтобы справиться с обилием паролей.
Задумайтесь о том, в какой обстановке работаете в данный момент. Есть ли какие-то критерии надежности паролей? Проводятся ли ежегодные тренинги или, может, на стенах висят плакаты, призывающие создавать уникальные, сложные пароли? Конечно, какой-то контроль и инструктаж, связанный с паролями, точно присутствует, но обеспечивают ли вам «санкционированный механизм», который помогал бы достичь поставленных целей? Скорее всего нет, и я говорю об этом с такой уверенностью потому, что часто задаю этот вопрос, когда провожу тренинги в различных организациях. Удивительно, как часто приходится видеть такую несостыковку.
Пусть вставляют пароли
С использованием менеджера паролей тесно связана возможность вставлять пароли в поле ввода. Существует множество менеджеров паролей, которые заполняют поля автоматически, но бывают и такие случаи, когда все равно приходится пользоваться вставкой или же сервис блокирует попытки ввести пароль не вручную (это легко проверить при помощи JavaScript). В результате получается следующее:
В 2014 году я писал об «эффекте кобры», который возникает, когда в поле пароля запрещена вставка. Я подробно объясняю значение этого термина в статье по ссылке, но если резюмировать вкратце: эффект кобры проявляется, когда попытка решить проблему ее только усугубляет. Когда на сайте блокируют возможность вставить пароль, чтобы обеспечить безопасность, это заставляет некоторых пользователей упрощать пароли, пока они не станут такими примитивными, что напечатать их не составит труда.
NCSC меня и здесь поддерживают:
Они даже ввели специальный термин для обозначения этого анти-паттерна — SPP (Stop Pasting Passwords, «Хватит вставлять пароли») и развенчивают популярные мифы о рисках, связанных со вставкой паролей. Они упоминают и мою статью, где говорилось об эффекте кобры — приятно получать такую протекцию от британского правительства!
NIST присоединяется к позиции NCSC, о чем свидетельствует их высказывание:
Верификаторы должны позволять лицу, проходящему авторизацию, пользоваться функцией вставки при вводе секретного кода. Это облегчает использование менеджеров паролей, которые широко распространены и во многих случаях стимулируют пользователей создавать более сложные секретные коды.
Так что даже не сомневайтесь: люди по обе стороны Атлантического океана единодушно поддерживают использование менеджеров паролей и выступают против активных действий по их блокировке.
Не требуйте регулярно менять пароль
На своей предыдущей работе в частной компании я придумал простой способ вычислить, сколько я уже использую свой текущий пароль: просто брал число, которое в нем содержалось и которое я увеличивал раз в квартал, когда компания требовала заменить пароль, и делил его на четыре. Таким образом я растянул один-единственный пароль почти на шесть лет, каждый раз меняя в нем не более пары символов. Если у вас на работе тоже заведено регулярно менять пароли, вы, вероятно, поступаете так же — ведь это легкий и естественный выход из положения, когда сталкиваешься с техническим требованием, которое доставляет неудобства.
Давайте разберем обоснование такого подхода: аргумент в пользу периодического обновления паролей состоит в том, что если пароль попадет в чужие руки, после вынужденной замены он станет неактуальным, а значит мошенники не смогут им воспользоваться. Проблема здесь в том, что в моем примере у хакеров было до трех месяцев времени, а в других случаях, возможно, и больше:
Если так подумать, хакеры обычно не выжидают сложа руки, они сразу принимаются за работу с аккаунтами, пытаясь извлечь из них выгоду. Команда Lifeboat не учла этого соображения в своих попытках загладить последствия прошлогодней утечки данных, и цепочка рассуждений получилась неверная:
После того, что произошло в январе, мы решили, что лучший курс действий — по-тихому провести замену всех паролей, чтобы хакеры не знали, что у них остается мало времени на воплощение своих планов.
Как упоминалось в приведенном выше твите, NCSC разделяет мнение, что на сегодняшний день вынужденная замена паролей — это анти-патерн в информационной безопасности. Вот что они говорят об этой практике в своем руководстве по управлению паролями:
[она] не приносит никакой реальной пользы, так как взломанные пароли обычно используются сразу же.
Они выносят эту мысль и в инфографику:
Просите пользователей поменять пароль только в том случае, если появились признаки или подозрения, что старый пароль скомпрометирован.
Microsoft высказывается в том же духе:
Политика установления срока действия паролей приносит больше вреда, чем пользы, так как подталкивает пользователей к тому, чтобы создавать крайне предсказуемые пароли из последовательных чисел и слов, тесно связанных друг с другом (как следствие, каждый последующий пароль легко угадать, опираясь на предыдущий). Что касается снижения рисков, смена пароля и здесь не играет большой роли, так как кибер-мошенники в большинстве случаев используют реквизиты сразу же, как получают к ним доступ.
Их слова, конечно не следует понимать как «не вынуждайте пользователей менять пароли, и больше от вас ничего не требуется». Это скорее указание на то, что необходим более широкий, более продвинутый подход к управлению паролями. Например, NCSC также дает и такие рекомендации:
- Отслеживайте все случаи авторизации, чтобы выявлять необычное поведение.
- Сообщайте пользователям подробности о попытках входа, неважно удачными они были или неудачными. В свою очередь, пользователи должны оповещать вас, если какие-то из этих попыток исходили не от них.
И тут мы плавно переходим к следующему разделу.
Сообщайте пользователям о нетипичном поведении
Это важный аспект «продвинутого» подхода к процессу аутентификации и вполне возможно, что вы уже наблюдали его в действии. Недавно я зашел на свой аккаунт в Yammer cо своего нового Lenovo Yoga 910 — до того момента я не пользовался их сервисом на этой машине. Чуть позже мне пришло такое оповещение:
Позже я зашел на Dropbox через бразуер на той же машине и сразу же получил сообщение:
Разумеется, эти письма никак не помешали мне зайти в систему и, само собой, на моем месте мог бы быть злоумышленник, заполучивший реквизиты доступа жертвы. Но они немедленно оповестили меня о произошедшем, и это имеет огромную ценность — руководствуясь этой информацией, я мог бы при необходимости пойти и выгнать того, кто вторгся в мою учетную запись. Dropbox даже показал мне все девайсы, которые я авторизовал за последние пять лет, и предоставил возможность отменить авторизацию.
Возможность отслеживать таким образом поведение аккаунта очень полезна; например, можно посмотреть на каких девайсах в данный момент осуществлен вход на мой аккаунт в Facebook.
Как и в случае с Dropbox и Yammer, здесь также предлагается опция выйти из системы на любом девайсе из списка. А это значит, что законный владелец может хоть в какой-то степени вернуть себе контроль над аккаунтом в ситуации, когда кто-то получил к нему несанкционированный доступ. Многие из современных сервисов предлагают такую возможность; хороший пример тому — Github, который приводит еще более подробную информацию, включая IP адрес и конкретные события, значимые с точки зрения безопасности, например, запрос на двухфакторную идентификацию или создание открытого ключа.
Вот еще один возможный сценарий:
Хотелось бы, чтобы мне сообщали о попытках входа, когда пароль вводился верный, но двухфакторная идентификация не проходила. Это явно говорит о том, что пароль попал в чужие руки.
Это также представляется очень разумным, и когда задумываешься о различных сценариях, в которых стоило бы проявить инициативу и предупредить пользователя, начинаешь понимать, как много можно сделать с минимальными затратами труда.
Блокируйте скомпрометированные пароли
Вернемся на минутку к вбросам регистрационных данных и всему с ними связанному. Если пароли где-то засветили, их следует считать «оскверненными» — в том смысле, что использовать их больше нельзя. Никогда. Теперь, когда они побывали в открытом доступе, огромное количество людей располагает информацией об этих реквизитах, что существенно повышает риски для тех, кто их использует. Только представьте: доступ к миллиарду пар e-mail адрес-пароль, взятых из утечек реальных данных, о которых я распространялся в посте о вбросах регистрационных данных:
NIST говорит об этой проблеме следующее:
При обработке запросов на создание или изменение секретного кода верификаторы должны сверять предложенные коды со списком тех, которые считаются широко распространенными, предсказуемыми или скомпрометированными. Такой список может включать, среди прочего, пароли из корпусов, составленных на материале утечек баз данных.
Говоря простым языком: когда кто-нибудь создает аккаунт или меняет пароль, вы должны следить, чтобы этот пароль не входил в число тех, которые фигурировали в утечках данных. Неважно, что это, возможно, не тот же самый пользователь, который устанавливал пароль на взломанный аккаунт — одно то, что пароль оказался в публичном доступе, повышает вероятность его использования в хакерских атаках. В цитате также упоминается, что пароль не должен представлять собой слово в его словарной форме или «слово, порожденное контекстом». Описывая случай, когда база данных CloudPets оказалась в общем доступе, я обращал внимание читателей на то, что хеши-строки bcrypt крайне легко взломать при помощи небольшого словаря паролей, в число которых входят и такие слова как «cloudpets». Не давайте пользователям возможность ставить в качестве пароля название ресурса, на котором они регистрируются — а то ведь они именно так и поступят!
Следующий уровень
Есть много других тонкостей, которые я умышленно не стал включать в эту статью. Скажем, разнообразные механизмы многошаговой верификации, которые сейчас доступны, — о них, кстати, говорит и NIST в своей документации. Здесь я хотел сосредоточиться на самых базовых принципах, хотя, конечно, дополнительные слои защиты (например, приложение для аутентификации) значительно улучшают ситуацию с безопасностью — жаль, что ими почти никто не пользуется.
В январе прошлого года только 1% пользователей Dropbox использовали двухфакторную идентификацию (еще до утечки данных)
Еще один аспект, которого стоило бы коснуться — это возможность выявлять и отражать автоматизированные хакерские атаки. Задумайтесь: насколько ваша система подготовлена к тому, чтобы идентифицировать неожиданный наплыв попыток войти в систему как атаку, например, при вбросе регистрационных данных? Все выяснится, только когда пользователи начнут массово сообщать о взломе аккаунтов, или вы с самого начала будете в курсе? А если, предположим, вам удалось обнаружить атаку, сможете ли вы немедленно провести контрмеры, чтобы минимизировать риски? Например, как на Cloudpet, где можно проставить нужный уровень защиты?
Также я не разбирал подробно способы хранения паролей, решив уделить основное внимание тем составляющим политики аутентификации, которые можно увидеть невооруженным глазом. Чтобы не оставлять эту тему совсем не затронутой, предлагаю вам ознакомиться с Password Storage Cheat Sheet от OWASP и почерпнуть там все необходимые напутствия. Вдобавок советую внимательно прочитать статью о том, как Dropbox хранит ваши пароли — это очень интересный текст, где современный подход к хешированию сочетается с шифрованием.
Представленные проблемы не исчерпываются тем, что я здесь написал. Суть в том, что принципы, намеченные мной выше, должны в наши дни быть обязательным минимумом, но это не значит, что вы должны останавливаться на этом этапе.
Обобщая сказанное
Вот общая картина того, что признают все эти руководства от правительственных учреждений и IT-компаний: безопасность все чаще связывается с комбинацией элементов управления, которые в совокупности обеспечивают более надежную защиту. В этом посте вы найдете набор рекомендаций, которые, дополняя друг друга, помогают создать мощное решение. Соотвественно, отдельные рекомендации, такие как отказ от требований к сложности, могут на первый взгляд показаться странными, но когда вы вдумаетесь в то, как люди обычно действуют в реальности (просто выбирают плохие пароли с комбинацией из разных типов символов), и примете во внимание другие инструкции, например, совет блокировать ранее взломанные пароли, все начинает становиться на свои места.
И вот еще что: теоретически все эти руководства – вещь хорошая, однако реализовать их на практике может быть несколько сложнее. Я собираюсь развить эту тему в следующем посте, который выйдет на этой неделе. Там я собираюсь рассказать кое-что интересное и новое, что поможет владельцам сайтов обеспечить безопасность своим подписчикам. Я работал над ним в течение нескольких недель, потратил немало сил и собираюсь поделиться с вами результатом бесплатно, так что заглядывайте в ближайшее время на мой сайт. Также я намерен обновить этот пост, добавив ссылку на ресурс, как только выложу его в открытый доступ. Следите за обновлениями!
