Пароли, хранилище и другие важные решения, касающиеся обеспечения безопасности

У Алисы есть несколько различных аккаунтов для работы, дома и хобби. Боб находится в такой же ситуации: у него буквально сотни паролей, используемых на работе и в личной жизни. Чтобы запомнить все свои пароли, Алиса использует менеджер паролей, в то время как Боб просто использует одну и ту же пару паролей (что специалисты по безопасности называют «повторным использованием паролей»).

СОВЕТ. Этот раздел содержит требования, которые подходят не всем проектам, но могут быть более полезны в качестве стандарта для вашего IТ-отдела в целом, например использование менеджера паролей. Делайте то, что имеет смысл для вашей организации.

Менеджер паролей – это программное обеспечение, которое надежно хранит пароли пользователей и помогает им создавать уникальные, длинные и сложные комбинации. Люди используют менеджеры паролей, чтобы не запоминать несколько паролей – им нужен лишь один для входа в менеджер (а также пароли, которые нельзя хранить там, например пароль от телефона или компьютера). Менеджер паролей обеспечивает создание случайных (не предсказуемых с точки зрения компьютера или человека) и уникальных (не используемых повторно, как в случае Боба) паролей.

Большинство менеджеров паролей имеют плагины для браузеров, позволяющих аутентифицироваться на посещаемом сайте простым нажатием кнопки. Менеджер сам скопирует имя пользователя и пароль в браузер, что помогает избежать ошибок при вводе. Качественные менеджеры паролей также сообщают, если в нескольких местах используется один и тот же пароль, имя пользователя и пароль стали частью взломанных данных, был выбран плохой пароль (возможность придумывать свои собственные пароли при использовании менеджера остается), а также если сайт предлагает функцию MFA (многофакторной аутентификации).

Ко всему прочему, в менеджерах паролей обычно есть защищенная область для заметок (в которой можно сохранить номер социального страхования, информацию о кредитной карте и т. д.). Я советую всем заядлым пользователям компьютеров применять менеджеры паролей не только для обеспечения дополнительной безопасности, но и для экономии времени, затрачиваемого на поиск или сброс забытых паролей. Также стоит отметить, что менеджеры паролей предназначены для пользования людьми, а не компьютерами.

При утечке данных на каком-нибудь сайте, когда имена пользователей и пароли (то есть «учетные данные») попадают в интернет или в руки злоумышленников, пользователь теряет лишь ту учетную запись, которая использовалась на взломанном сайте, что является одним из преимуществ менеджеров паролей и повсеместного применения уникальных паролей. Довольно часто украденные учетные данные используются в атаке методом подстановки учетных данных (англ. credential stuffing attack): злоумышленник использует их как часть автоматизированной атаки на один или несколько других сайтов, чтобы увидеть, какие из них были использованы повторно, что позволяет ему получить доступ к аккаунтам на других сайтах. Некоторые взломщики доходят до того, что пишут сценарии «корректировки» паролей, например изменяя «Пароль1» на «Пароль2», «Пароль3» и так далее, и тем самым пробуют вариации украденных паролей. Такая атака называется атакой методом подстановки учетных данных с использованием радужных таблиц (англ. rainbow credential stuffing attack).

Если на сайте, которым пользовались и Алиса, и Боб, произойдет утечка данных, то, Алисе нужно будет сбросить только один пароль и беспокоиться только об одном аккаунте, поскольку она везде использует уникальные пароли. У Боба же возникнет много работы и забот! Также Алиса и Боб могут защититься от этого типа атаки с помощью включения MFA для каждой учетной записи, представляющей для них ценность (банковские счета, рабочие аккаунты, электронная почта, учетные записи, к которым привязаны кредитные карты, аккаунты очень личного характера, электронные медкарты и т. д.).

Менеджер паролей + повсеместное использование уникальных паролей + MFA = глубокая защита личной информации

По работе разработчикам и техническим специалистам необходимо использовать огромное количество паролей, следовательно, у них всегда должен быть доступ к менеджерам паролей.

Тайники похожи на менеджеры паролей, только они предназначены для использования компьютерными системами, а не людьми. Тайник – это программное хранилище, которое шифрует секреты, а затем позволяет приложению получить к ним программный доступ (через код приложения или процесс формирования CI/CD-конвейера). В нем можно хранить сертификаты, учетные данные (имя пользователя и пароль), строки подключения, хеши и все, что считается «секретом», используемым приложением.

Сервисными учетными записями называются аккаунты, используемые компьютерами, а не людьми. С их помощью происходит идентификация компьютерных систем в сети. Если разрабатываемому приложению требуется доступ к базе данных, разработчику следует создать сервисную учетную запись, а не использовать личную. Этому есть много причин, самая очевидная из которых заключается в необходимости, чтобы все программное обеспечение могло продолжить работу даже после ухода его разработчика. Другими причинами выступают мониторинг (если каждое приложение имеет собственную учетную запись, команда мониторинга может видеть, что делают приложения, а не разработчик), расследование инцидентов (необходимо, чтобы были видны действия всех членов команды, иначе возникнет представление, как будто все ошибки принадлежат разработчику, так как везде было использовано его имя пользователя), соблюдение принципа наименьших привилегий (учетная запись разработчика, скорее всего, имеет множество разрешений повсюду, и если кто-то получит доступ к его аккаунту, то получит доступ ко всем приложениям) и т. д. Необходимо обеспечить постоянное соблюдение принципа наименьших привилегий при создании и включении учетных записей служб.

СОВЕТ. Срок действия паролей от сервисных учетных записей никогда не должен истекать, если только не произошло (предполагаемого) взлома. Пароли также должны быть чрезвычайно сложными и как можно более длинными. Сервисные учетные записи никогда не должны иметь права (привилегии) на вход на рабочие станции или доступ к любым другим ресурсам, кроме тех, для которых они изначально были созданы.

А как насчет паролей пользователей приложения? Где их следует хранить? Они должны храниться в базе данных (или другом централизованном месте управления, например у поставщика удостоверений), в засоленном и хешированном формате. Если вы помните, хешированием называется односторонний криптографический процесс, который нельзя отменить. Засаливание – это добавление уникальной длинной строки к значению перед хешированием с целью увеличения энтропии и усложнения для потенциального злоумышленника взлома или угадывания пароля. Когда пользователь аутентифицируется в приложении и вводит необходимые значения, запускается функция хеширования и соления, а затем результат сравнивается с тем, что хранится в базе данных. Таким образом, украденные имена пользователей и пароли бесполезны для злоумышленника, поскольку если бы он ввел в приложение хешированное и засоленное значение, то оно бы изменилось и в результате уже не совпадало бы со значением в базе данных.

ПРИМЕЧАНИЕ. Под взломом здесь подразумевается использование автоматизированного инструмента для угадывания пароля с помощью списка слов до тех пор, пока пароль не будет определен. Данный процесс также называется «методом грубой силы» или «полным перебором» (англ. brute force) и является автоматизированным угадыванием чего-то с целью получения доступа.

Соль должна состоять как минимум из 28 символов (но желательно намного длиннее), создаваться безопасным генератором случайных чисел и быть уникальной для каждого пользователя приложения. Следует хранить отдельное значение соли для каждого пользователя в базе данных вместе с хешированным значением «соль + пароль». Надо отметить, что соль не является секретом, в отличие от перца (о котором мы расскажем чуть позже).

Более новыми методами обеспечения того, чтобы пароли было чрезвычайно трудно взломать, являются «рабочий фактор» и «перец».

Рабочий фактор означает повторение алгоритма хеширования X раз, где X – это количество итераций. Значение рабочего фактора должно быть равно 2 или более (в зависимости от изменений в оборудовании в нашей отрасли, уровня чувствительности данных и учетных записей или чего-либо еще в изменяющемся характере угроз, которым подвергается приложение).

«Засыпка перцем», или по-криптографически «перец», имеет общие черты с солью: его тоже нужно добавлять к паролю до хеширования и создавать с помощью безопасного генератора случайных чисел. Однако, в отличие от соли, перец является секретом и не может храниться в базе данных, следовательно, его размещают в тайнике. Он должен быть довольно длинным: состоять как минимум из 32 символов (но желательно из 128). Ко всему прочему, перец уникален для каждого приложения, но одинаков для всех его пользователей.

Можно как солить, так и перчить свои пароли. Однако, как правило, для большинства систем требуется только соль. Решите этот вопрос со своей службой безопасности.

СОВЕТ. В идеале управление пользователями системы может осуществляться в рамках управления идентификационными записями. Таким образом можно переложить эту сложную работу по обеспечению безопасности на систему, созданную специально для таких целей.

ВНИМАНИЕ. В случае необходимости ротацию перца следует проводить осторожно, так как она может привести к сбросу всех паролей всех пользователей приложения. Это серьезный риск, который негативно отразится на ваших пользователях и клиентах. Если вы решите произвести ротацию перца, разработайте ее с учетом данного риска.

Пароли пользователей приложения должны быть длинными, но не обязательно сложными: хороший пароль имеет заглавные и строчные буквы, цифры и специальные символы, однако требования по количеству символов каждой категории раздражают пользователей. Достаточно будет включить в требования «сложности» пароля наличие одного символа из каждой категории. Разрешите пользователям вводить пароли длиной до 64 символов (чем длиннее, тем лучше), а также поощряйте использование парольных фраз. Не нужно заставлять пользователей менять пароли через определенное время, если только не подозревается взлом. Чтобы убедиться, что новые пароли пользователей не были ранее взломаны, можно сравнить хеши sha1 в диапазоне с помощью сервисов вроде HaveIBeenPwned.

ВНИМАНИЕ. При проверке того, не был ли пароль взломан ранее, убедитесь, что анонимность пользователей защищена. Существует несколько моделей обеспечения анонимности, например k-анонимность. Подробную информацию можно найти на сайте haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange.

Никогда не стоит проверять правильность имени пользователя или пароля, когда предупреждаете пользователя о том, что он не смог войти в систему. Предоставление такой информации позволяет злоумышленникам собирать имена пользователей (проверяя, использует ли пользователь вашу систему).

СОВЕТ. Как метод проверки контрольные вопросы устарели, поскольку большинство пользователей выбирают те из них, ответы на которые находятся в открытом доступе (например, в социальных сетях). По возможности откажитесь от их применения.

Функции забытого пароля проверяют личность пользователя перед отправкой ссылки на сброс пароля по электронной почте или SMS с использованием либо другой формы аутентификации, либо контрольного вопроса. При неудачной аутентификации ни в коем случае нельзя раскрывать, какая часть не прошла проверку. Также нельзя допускать, чтобы пользователь смог сбросить пароль непосредственно в системе. Сброс пароля всегда должен происходить посредством «внеполосной» формы связи (через электронную почту или SMS) в качестве второй формы аутентификации. Ссылка на сброс должна быть одноразовой, а ее действие – не превышать один час, если она не была использована. Каждый сброс пароля (или неуспешная попытка) должен быть зарегистрирован. Для его подтверждения на адрес или номер, привязанный к учетной записи, следует высылать электронное письмо или SMS. Если за последние 24 часа пользователь безуспешно пытался сбросить пароль 10 раз, нужно заблокировать его учетную запись на IP-адресе, с которого поступают запросы, при этом данная ситуация регистрируется и подается сигнал тревоги. Если IP-адрес пытается сбросить пароль для несуществующего аккаунта, следует обрабатывать его так, как будто такая учетная запись существует, чтобы предотвратить перечисление (сбор) настоящих имен пользователей злоумышленниками. На рис. 2.3 изображена блок-схема безопасной процедуры сброса забытого пароля.

Правила работы с паролями

• Хешируйте и солите все пароли пользователей. Соль должна состоять не менее чем из 28 символов.

• Все секреты приложения должны храниться в тайнике.

• Все учетные записи, используемые внутри приложения, должны быть сервисными (не личными аккаунтами людей). Они должны быть уникальными для каждого приложения и соответствовать концепции наименьших привилегий.

• Попросите всех сотрудников команды использовать менеджеры паролей, управляемые организацией, и установите политику, согласно которой нельзя повторно использовать пароли, включая вариации одного и того же пароля.

• Включите MFA для всех важных аккаунтов на работе и дома. При любой возможности используйте приложение аутентификации или само устройство, а не SMS в качестве второго фактора аутентификации.

• Не заставляйте менять пароли по расписанию – только если произошел взлом или наблюдается подозрительная активность.

• Всегда используйте современный алгоритм хеширования.

• При наличии сомнений касательно хранения паролей следуйте политике вашего правительства, а если таковой нет – политике паролей от NIST. Она была разработана группой экспертов и проверена на деле, поэтому в ней представлены самые лучшие рекомендации.

Рис. 2.3. Блок-схема сброса забытых паролей

СОВЕТ. Современные алгоритмы хеширования и дополнительные советы по хранению паролей можно найти на сайте cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.