Безопасность веб-приложений. Исчерпывающий гид для начинающих разработчиков

Public Key Pinning Extension for HTTP (HPKP)

Привязка открытого ключа (англ. Public Key Pinning) – это система, созданная для защиты от поддельных сертификатов. Ее идея заключалась в том, что доверять определенному URL-адресу или сайту можно было только при наличии сертификата от одного или двух центров сертификации. Сначала она реализовывалась с помощью статических привязок (встроенных в браузер непосредственно и вручную, в частности в Chrome и Firefox). Со временем владельцы других сайтов тоже захотели «привязать» сертификаты, в результате чего появились динамические привязки. Сертификат привязывался на определенный период времени (обычно на год) к определенному криптографическому идентификатору (ключам). Потеря ключей при этом означала потерю контроля над сайтом на срок до года, поскольку без них он не работал. URL сайта по сути оказывался «замурованным» (непригодным для использования), и в результате эта функция безопасности наносила катастрофический ущерб бизнесу. Такая ситуация называется «самоубийством с помощью HPKP».

Хотя использование данного заголовка безопасности потенциально дает большие преимущества, высокие риски делают его нежелательным средством защиты. Он применяется в тех случаях, когда требуется чрезвычайно высокий уровень безопасности и когда с ним работает команда, очень хорошо разбирающаяся в этой теме и готовая принять бизнес-риски.

ВНИМАНИЕ. Заголовок безопасности Public Key Pinning Extension for HTTP (HPKP) считается устаревшим и более не поддерживается.

Обеспечение безопасности файлов cookies

Протокол HTTP никогда не был предназначен для обработки пользовательских сессий (то есть отслеживания входов в систему или наличия товаров в корзине. Отслеживание того, как пользователь переходит с одной страницы на другую внутри сайта, называется «состоянием»). Cookie используются для передачи информации о сессии пользователя от браузера к веб-серверу и могут быть сохранены для усиления персонализации (например, сохранения языковых предпочтений) в будущем. Многие сайты используют cookie для хранения информации в целях осуществления маркетинговых действий и отслеживания поведения пользователей, а также для продажи информации другим компаниям. Мы не будем рассматривать этические аспекты конфиденциальности данных, хранящихся в cookie.

Для обеспечения безопасности данных в файлах cookie необходимо применить нижеизложенные параметры.

Обратите внимание, что иногда разработчики решают использовать вместо cookie локальное хранилище. Для его защиты применяются совершенно иные меры безопасности, и в данном разделе они рассматриваться не будут. Кроме того, передача сессии должна происходить не в постоянном, а только в сессионном файле cookie и никогда не храниться в локальном хранилище. Всегда используйте сессионные файлы cookie.

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

Флаг Secure

Флаг Secure гарантирует, что файл cookie будет отправлен только по зашифрованным (HTTPS) каналам. Если злоумышленник попытается перевести сессию на HTTP, веб-приложение откажется отправлять cookie. Данная настройка должна быть включена на постоянной основе:

Set-Cookie: Secure; (плюс все остальные настройки)

Флаг HTTPOnly

Так как данный флаг не имеет ничего общего с принудительным незашифрованным соединением (HTTP), его название вносит путаницу среди программистов. Когда он установлен, то это значит, что к файлу cookie нельзя получить доступ через JavaScript. Его можно изменить только на стороне сервера. Причина использования этого параметра заключается в защите от XSS-атак, которые пытаются получить доступ к значениям в файле cookie. Необходимо всегда устанавливать данный флаг во всех cookie в качестве еще одного уровня защиты от XSS-атак, угрожающих конфиденциальности данных:

Set-Cookie: HttpOnly; (плюс все остальные настройки)

Для постоянных cookies

При сборе конфиденциальных данных пользователя либо при управлении сессией файлы cookies не должны быть постоянными. Они должны самоуничтожаться в конце сессии, чтобы защитить данные. Файл cookie, который самоуничтожается в конце сессии, называется «сессионным cookie», в противном случае – «постоянным cookie» или «отслеживающим cookie». Решать, какой тип cookie вам подходит, необходимо с помощью команды по обеспечению конфиденциальности и бизнес-аналитиков.

Для постоянных файлов cookie можно с помощью атрибута expires установить дату окончания действия, а через параметр max-age – определить максимальный срок жизни cookie.

Окончание действия: 1 января 2021

Set-Cookie: Expires=Mon, 1st Jan 2021 00:00:00 GMT; (плюс все остальные настройки)

Максимальный срок жизни – 1 час

Set-Cookie: Max-Age=3600; (плюс все остальные настройки)

Domain

Чтобы к файлам cookies могли получить доступ сторонние домены, нужно указать их как доверенные домены с помощью атрибута domain, иначе браузеры будут считать, что cookies предназначены «только для хоста», то есть доступны только вашему домену, а попытки других доменов получить доступ будут блокироваться. Этот тип встроенной защиты считается «безопасным по умолчанию». Вот бы все настройки программного обеспечения работали таким образом!

Set-Cookie: Domain=app.NOTwehackpurple.com; (плюс все остальные настройки)

ВНИМАНИЕ. Если поддомен не задан (то есть вы указали NOTwehackpurple.com вместо app.NOTwehackpurple.com), каждое приложение и страница, размещенные в этом домене, смогут получить доступ к вашему файлу cookie.

Path

Фактически большинство URL-адресов в интернете представляют собой множество отдельных приложений, имеющих различные пути и поддомены. Для пользователя они выглядят как одна огромная веб-страница, но на самом деле это тысячи различных приложений. В такой ситуации лучше всего ограничить доступ к cookie только определенной областью местоположения приложения – его «путем». Ограничение области действия cookie осуществляется с помощью атрибута path:

Set-Cookie: path=/YourApplicationsPath; (плюс все остальные настройки)

Same-site

Атрибут same-site был создан компанией Google для борьбы с межсайтовой подделкой запроса (CSRF). CSRF, ласково называемый «си сёрф», представляет собой атаку на авторизованных на надежном сайте пользователей, при которой злоумышленник пытается совершить действия от имени пользователя без его согласия или ведома. Обычно атака происходит через фишинговое электронное письмо.

Представим, что Алиса собирается принять участие в телевизионном шоу, в котором будет рассказывать о своей компании. Чтобы выглядеть великолепно, она решила купить новый наряд через интернет. Алиса заходит на сайт любимого магазина одежды и, просматривая новинки, замечает, что ей пришло письмо. Оно фишинговое: в нем содержится ссылка на сайт, на котором она в данный момент авторизована, с закодированной инструкцией, позволяющей злоумышленнику купить какой-нибудь продукт и отправить его себе, а не Алисе. Если она нажмет на данную ссылку, а сайт не обеспечен надлежащей защитой, вся атака может произойти без ее участия и вовсе остаться незамеченной. При этом атака сработает только в том случае, если на момент ее совершения Алиса будет авторизована на сайте, указанном в фишинговом письме.

Данная ситуация может показаться надуманной, но вспомните, как вы работаете со своей учетной записью (аккаунтом). Всегда ли нажимаете кнопку «Выход»? Бывает ли такое, что сайт остается открытым в течение нескольких дней? Никто не совершенен, и наша работа – защищать пользователей наших сайтов, даже если они совершают такую ошибку, как нажатие на фишинговую ссылку.

Таким образом, атрибут cookie same-site обеспечивает соблюдение правила, согласно которому cookies могут поступать только с одного сайта. Cookies не могут передаваться между различными сайтами (то есть исходить не с вашего сайта). Возможны следующие варианты применения данного атрибута: None (файлы cookies могут исходить откуда угодно), Strict (только с собственного домена) и Lax (если нужно, чтобы cookies отправлялись при переходе по ссылке или с другой страницы, в них должна содержаться только нейтральная информация). Если ни одно из данных значений не установлено, то по умолчанию в современных браузерах используется lax:/, а в старых версиях – none.^[20]

Lax означает, что пользователи могут оставаться в учетной записи и посещать другие сайты, а по возвращении на сайт файлы cookies будут продолжать работать. Lax обычно используется для навигации и других функций, выполняемых приложением до того, как пользователь войдет в систему. Он блокирует очевидные CSRF-атаки (POST-запросы). Lax нельзя назвать надежным решением, однако это хороший компромисс, если не получается использовать значение strict.

Set-Cookie: same-site=Strict; (плюс все остальные настройки)

Set-Cookie: same-site=Lax; // блокирует только POST-запросы, разрешает переход по ссылке

Cookie с префиксом

Префиксы для файлов cookies были введены относительно недавно и принимаются еще не всеми браузерами. Тем не менее они являются одним из средств «защиты в глубину» (дополнительным уровнем безопасности) для случаев ошибочной обработки файлов cookies. Например, если поддомен был взломан, а в настройках cookies Path указан весь домен, то взломанный домен может попытаться получить доступ к файлу cookie. Префиксы расположены в имени файла cookie, и поэтому сервер увидит его, несмотря на то, зашифрован он или нет. Обеспечить доступ к cookie только в пределах определенного поддомена можно с помощью префикса host. Более подробную информацию по этой теме можно найти на веб-сайтах Mozilla и Chrome.

Политика конфиденциальности

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

Классификация данных

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

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

Боб работает в федеральном правительстве, имеющем свою систему классификации данных (рис. 2.2). В его обязанности входит работа с данными, которые являются государственной тайной, секретной и совершенно секретной информацией. Существует строгая система идентификации типа этих файлов и данных, которой Боб всегда следует. «Государственная тайна», «Секретно» и «Совершенно секретно» в Канаде (где живет Боб) означает, что в случае раскрытия данных может быть нанесен ущерб целой стране, а не конкретному лицу. На предыдущей должности Боб работал с данными, которые были гораздо менее чувствительными и классифицировались как общедоступные (их мог видеть любой человек), под защитой уровня «A» (могли причинить вред или смутить человека), под защитой уровня «B» (причиняли вред человеку или группе людей) и под защитой уровня «C» (могли привести к смерти или иному непоправимому ущербу для одного или нескольких людей).

Рис. 2.2. Классификация, используемая Бобом при работе с данными

Классифицируя (определяя уровень чувствительности) и размечая собираемые данные, Боб помогает всем членам команды понять, как правильно обращаться с этими данными. Работая с неразмеченными данными, люди могут совершить ошибку, что может привести к непреднамеренной утечке информации или незащищенности очень ценных или конфиденциальных данных. Многие системы баз данных (например, Microsoft SQL Server) позволяют добавлять к полям данных или таблицам уровни классификации. Если используемая вами программа не предоставляет такой возможности, вы сами можете разметить данные путем добавления дополнительного поля в таблицу (или нескольких, если данные имеют разные уровни чувствительности). Даже «несекретным» или «общедоступным» данным следует присвоить соответствующую метку.

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

ПРИМЕЧАНИЕ. Хотя это не является обязательным требованием проекта, но должна существовать техническая документация, объясняющая, как работать со всеми уровнями конфиденциальных данных, а также готовый к использованию код или библиотеки для работы с данными. Лучше всего, если этот код или библиотека централизуют управление и обработку данных для получения одинаковых результатов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Засыпка перцем», или по-криптографически «перец»^[22], имеет общие черты с солью: его тоже нужно добавлять к паролю до хеширования и создавать с помощью безопасного генератора случайных чисел. Однако, в отличие от соли, перец является секретом и не может храниться в базе данных, следовательно, его размещают в тайнике. Он должен быть довольно длинным: состоять как минимум из 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.