Логин и пароль: что это, как создать и где лучше хранить

Немного воды или, что же автор хотел всем этим сказать?

В преамбуле к статье я писал, что занимаюсь дурью проектирую протокол беспарольной аутентификации в Web, который бы сильно облегчил всем нам (конечным пользователям сайтов) жизнь, избавляя от парольного ада. И эта статья написана, чтобы  «раскрывать причины технических решений, закладываемых в новый протокол». Так вот, касаемо схемы авторизации, я делаю ставку на SRP.

На самом деле протоколов авторизации гораздо больше, чем было описано выше. Но SRP – это, на мой взгляд, самая крутая схема, созданная профильным специалистом, выпускником Стэндфордского университета (Thomas Wu), и проверенная его коллегами и другими специалистами по безопасности.

Возникает закономерный вопрос? Если эта схема такая крутая и древняя, почему она не получила до сих пор широкого распространения.

Я думаю, что этот протокол просто опередил свое время. Тогда аутентификацию предполагалось выполнять на клиенте в браузере. А javascript находился в зачаточном состоянии и мог, в лучшем случае вывести алертом «hello word». А нужна была арифметика на больших числах. Сейчас уже есть, но время упущено.

И самое главное, веб сообщество до сих пор не осознало, что процесс аутентификации необходимо выносить за рамки прямого взаимодействия сервер–браузер (равно как и аутентификацию в иных системах). В самом деле, ведь никто в здравом уме не хотел бы реализовывать вручную TLS  (на javascipt/PHP/JAVA)?

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

А кстати, почему это srp вдруг крут?

Чтобы понять это, необходимо вначале глужбе его изучить. Сравнить с другими методами и протоколами.

Злоумышленник не сможет сделать ничего, даже если взломал сервер и активно контролирует канал. Это очень круто.

Хешируем

Ну хорошо. Попробуем усилить элементарную схему. Первое, что приходит на ум: будем передавать не пароль P, а его хэш H. И сервер будет хранить не исходный пароль, а его хеш. Теперь исходный пароль пользователей не сможет узнать ни MitM, ни взломщик БД.

Для надежности, возьмём в качестве хеширующей функции SHA2 или SHA3. 256-битов на текущий момент вполне достаточно. Но если хотите – обе функции поддерживают режим 512 бит. Хотя признаться, такое количество бит потребует сделать в БД поле размером в 64 байта!

Хорошо. Вот только злоумышленнику MitM не нужно уже знать пароль – ему достаточно узнать его хэш. Мало того, если пользователь использует такой же пароль на другом сайте, и тот сайт использует подобную “защиту”, то MitM и там может “поживиться” (ему уже не обязательно взламывать канал, достаточно зайти “легально”).

Солим

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

Scrypt’им

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

Производительность компьютеров растет. И хотя закон Мура давно как не действует (по слухам, с 2006 года), и рост уже не экспоненциальный, на “плато” мы ещё не вышли. То что ранее считалось невозможным, теперь доступно многим. Например, аренда на время вычислительных кластеров с фантастической мощностью.

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

Как? В начале по таблице известных паролей: синтетических qwerty, популярных 123 и когда-то угнанных реальных. Затем, путём тупого перебора символов из заданного алфавита. Алгоритм концептуально прост: берем пароль-кандидат, вычисляем hash( password, salt ), сравниваем результат. Соль учетной записи известна, ибо хранится рядом с хешем пароля.

На нашу беду, процесс перебора хорошо параллелится. А значит, в теории рост производительности не ограничен (правда только в теории; практика – вещь куда более суровая).

Этой проблемой озадачились уже достаточно давно. И в результате усилий криптографов, на свет появилась такая функция как scrypt.

Функция scrypt делает почти тоже самое, что и хэш-функция (на самом деле использует в качестве базы SHA2-256), но создана таким образом, чтобы усложнить атаку перебором при помощи ПЛИС: FPGA, ASIC и подобных. Она заставляет использовать в алгоритме много циклов и ветвлений (чего суперскаллярные процессоры крайне не любят), к тому же, требует слишком много памяти на одно ядро.

https://www.youtube.com/watch?v=7P66-lolLBQ

Поэтому, вместо стандартной хеширующей функции, мы будем использовать scrypt. WebCryptApi пока её не поддерживает, но для javascript-разработчиков есть уже реализованные библиотеки. В остальном схема взаимодействия пока остается прежней. И вроде бы, надежной.

Но защитит ли она от пассивного MitM? Нет. Ибо мы всё ещё посылаем на сервер всегда один и тот же хеш. А значит, перехватив передачу итогового хеша на сервер, злоумышленник может в последствии легально его использовать для входа под чужой учеткой.

Добавляем challenge

Ну хорошо. Давайте усложним жизнь и для MitM. Попытаемся добиться того, чтобы хеш от пароля на сервер передавался всегда разным. Как? А давайте «посолим» уже сам хэш! Тот самый, что нам дает функция scrypt( password, salt ). Для этого сервер сгенерирует и пошлет клиенту случайную последовательность байт (длина которой равна длине блока хеширующей функции), которую мы (по традиции) назовем challenge. Теперь схема взаимодействия клиента и сервера такова:

Обоюдный challenge

Казалось бы где тут подвох? Да почти нигде. Вот только, что если наш злоумышленник MitM вклинится в момент аутентификации и поменяет challenge от сервера на более простой (например – все нулевые биты, или вообще пустой)? Зачем? А чтобы попытаться облегчить себе задачу обратного восстановления H из Hs.

Защититься от такой потенциальной атаки можно, если клиент будет генерировать свой challenge и использовать его для хеширования пароля. Теперь на шаге 2, клиент вычисляет Hs = hash(H,server-challenge,client-challenge) и отправляет Hs вместе со своей версией challenge.

Финальный штрих

Некоторые, возможно, уже заметили, что даже такая усложненная схема авторизации не защищает нас от взломщика БД. Последний может использовать компрометированные хеши пользователей и соли для легального входа от имени пользователей. Можно ли как-то от этого защититься?

Можно. И даже более того. Фактически мы можем сделать так, что угон аутентификационных данных пользователей будет бессмысленным. Компрометация этих сведений не принесет взломщику ничего (ну правда, он может «поживиться» куда более ценными сведениями; например данными сохраненных кредитных карт и cvc-кодами для них; но мы ведь защищаем процессы авторизации, а не проектируем PCI DSS).

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

КРАЙНЕ ВАЖНОЕ ЗАМЕЧАНИЕ: если вдруг кому-то покажется интересной какая-то из двух рассмотренных далее схем, ни в коем случае не спешите внедрять. Внимательно изучите сравнительную таблицу недостатков и уязвимостей. Опять же, не забывайте про опасность использования «учебных» криптопротоколов. Я предупредил.

А Схема защиты на симметричных ключах

Пусть H – это тот самый хеш клиента, по которому сервер его аутентифицирует. H хранится на сервере. H может быть потенциально стать доступным взломщику БД.

Пусть клиент имеет некий ключ K, которым он зашифровывает свой исходный аутентификационный хеш H: V = EK(H), где E – функция шифрования на ключе K. Итоговый шифр V вместе с H сервер хранит в своей БД. Если алгоритм шифра выбран надежный, то из пары (V, H) восстановить исходный ключ почти невозможно.

Теперь в процессе аутентификации нам остается передать защищенным образом пару (H, V) серверу. Тот сверит H, расшифрует V и убедится, что мы действительно знаем ключ К, а не украли H при взломе БД. 

Это был концепт. Теперь конкретика. 

Определим функцию hmac как функцию HMAC-SHA2-256. Salt и challenge должны быть равны длине блока хеширующей функции. В нашем случае – 256 бит. Определим функцию E – как функцию шифрования, а функцию D – как функцию расшифровывания на базе симметричного шифра AES-256.  Наконец, определим функцию scrypt, как функцию, возвращающую 256-битный хеш от пароля и его соли.

На стороне клиента производятся предварительные вычисления:

1. Защитим исходный пароль пользователя, вычислив .

2. Сформируем аутентификационный хеш .

3. Сформируем код подтверждения .

4. Сформируем шифр аутентификационного хеша .

При регистрации клиент посылает серверу пару (H, V) в открытом виде. Заметим, что сервер не знает ни исходный пароль пользователя, ни его первичный хеш Hp.

Алгоритм авторизации клиента теперь такой:

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

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

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем
Single Sign-On
(SSO), где одно приложение (
service provider
или
relying party
) делегирует функцию аутентификации пользователей другому приложению (
identity provider
или
authentication service
). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение
доверяет
функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.На общем уровне, весь процесс выглядит следующим образом:

1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
3. Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

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

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
2. Токен предназначается текущему SP-приложению (проверка поля audience).
3. Срок действия токена еще не истек (проверка поля expiration date).
4. Токен подлинный и не был изменен (проверка подписи).

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

Брутфорс

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

Взлом через sms

Для этой уловки преступник должен знать номер жертвы. При восстановлении аккаунта практически от любого сайта пользователю нужно ввести свой номер, но если это сделает мошенник, то он получит доступ к вашим данным. Как это происходит:

1. Недоброжелатель заходит на сайт и начинает процесс восстановления пароля, выбирая способ «получить код через SMS»;
2. В этот момент код приходит на телефон жертвы;
3. Следом приходит фальшивое сообщение якобы от этого сайта, но написано оно мошенником. Например, «на вашем аккаунте замечена подозрительная активность, перешлите сюда код, пришедший ранее»;
4. Если жертва пересылает код, то преступник без проблем не только получит доступ к аккаунту, но и может сменить пароль.

https://www.youtube.com/watch?v=JzX7tysUhH4

Наглядно этот способ мошенничества показан в следующем видео, где демонстрируется «угон» Google-аккаунта (видео на англ., но интуитивно все ясно):

Вирус троян

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

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

Вместо послесловия

Я рассказал вам немного о том, как защитить свои данные.

Надеюсь, информация была вам интересна и полезна. Если у вас остались вопросы – спрашивайте, буду объяснять.

Ну а на сегодня, пожалуй, все. Жду от вас лайков, комментариев и репостов. Увидимся, точнее спишемся.

Вход в профиль с помощью пароля

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

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

Без входа в собственный аккаунт большинство функций сайта будут просто невозможны.

Для регистрации на сайте необходимо придумать пароль

Прежде чем придумывать пароль, позволю себе немного юмора:

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

В этой статье выше уже приведены примеры таких паролей (не пользуйтесь ими, придумайте другие):

• ParoL9!
• Pogoda8)
• Zdorovo!7
• Telefon!56

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

Вывод

Главный пароль – это пароль от электронной почты.

Для регистрации на всех остальных сайтах требуются другие пароли.

Принцип простой: сколько сайтов – столько и паролей у пользователя, а e-mail адрес везде можно указывать один и тот же.

Если нужно много паролей, то неизбежно встает вопрос:

Другой пароль для регистрации в соцсети

Теперь допустим, что надо пройти регистрацию в социальной сети или, проще говоря, создать свою страничку в соцсети. При этом, как правило, надо опять же указать свой e-mail и какой-то пароль.

Запоминать, сохранять или записывать все пароли?

Итак, пароль к e-mail – это именно пароль ТОЛЬКО к почте.

Можно зарегистрироваться, например, на десяти сайтах и везде указать один и тот же e-mail. Но пароли при регистрации на каждом сайте нужно указывать новые, разные. Это нормально, главное, самому не запутаться.

Можно пароли сохранять в браузере, либо пользоваться менеджером паролей, либо записывать в записную книжку.

Сейчас уже выпускаются специальные блокноты для записи паролей, которые можно приобрести в канцтоварах, в книжных магазинах или в интернет-магазине:

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

Зачем создавать надежный пароль

1 Через интернет мошенники и хакеры могут завладеть вашими личными данными, например, паспортными, благодаря которым в дальнейшем могут оформить кредит или микрозайм.

Такой случай недавно произошел с беременной москвичкой, которая узнала о том, что у нее есть просроченный займ от коллекторов. Но что там просроченный займ, по сравнению с потерянной жилплощадью? В середине 2022 года злоумышленники украли паспортные данные некого Романа, обманом оформили цифровую подпись и с ее помощью переоформили квартиру. Правительство борется с таким видом мошенничества, но лучший способ защиты — это перестраховаться лично.

2 Получив доступ к вашим соцсетям, мошенники могут развести ваших знакомых на деньги, сообщив им от вашего имени, будто у вас беда и срочно нужны деньги. Я сам стал жертвой такого случая. Однажды ко мне обратилась знакомая в VK, которая сообщила, что ее мама в больнице, денег на телефоне нет, чтобы позвонить и попросила 300 рублей.

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

3 Получив доступ к вашему компьютеру, мобильному телефону и хранящимся там фотографиям – мошенники могут начать шантажировать вас.

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

4 Получив доступ к личному кабинету Сбербанк Онлайн или другого, используемого вами банка, мошенники могут завладеть хранящимися там деньгами.

Причем, в основном преступники получают данные не одного человека, а целую базу данных. Такая неприятная ситуация случилась в конце 2022 — персональные данные клиентов (около 60 млн. кредитных карт) утекли на «черный рынок Интернета». Конечно, эта утечка произошла со стороны банка, но после таких новостей я бы лучше сменил пароль.

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

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

Как восстановить пароль через почту

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

Все остальные пароли он «вспоминает» так:

• Заходит на тот или иной сайт, где он когда-то регистрировался,
• вводит свой e-mail,
• жмет на кнопку «Забыли пароль?»,
• идет в свою почту, открывает там письмо, касающееся смены пароля,
• кликает по ссылке в этом письме для сброса пароля,
• вводит на сайте новый пароль,
• заходит на сайт,
• пароль для входа на сайт все равно забывает.

При следующем заходе на тот или иной сайт с регистрацией проделывает всю эту процедуру по новой.

Я таким способом не пользуюсь, но на вкус и цвет товарищей нет. При таком варианте пароли меняются и обновляются постоянно, в этом несомненная фишка этого подхода.

В качестве примера приведу сайт РЖД, к которому можно восстановить доступ именно через свою почту.

Как создать хороший пароль

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

Кража данных через wi-fi

Это достаточно простой способ кражи данных, основанный на желании людей сэкономить. Бесплатным wi-fi пользуются очень многие люди, и при этом они заходят в соц. сети, личную почту или работают с банковскими счетами.

Ложка дёгтя в бочке мёда.

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

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

Обнадёживает тут только то, что даже если эллиптическая кривая «подведёт», пароль пользователя всё ещё находится под надёжной защитой благодаря scrypt и hmac.

Один пароль для e-mail и всех остальных сайтов?

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

А далее мошенник, получивший доступ к такой конфиденциальной информации, может использовать все это богатство для рассылки спама, для доступа к денежным средствам, на личные странички в соцсетях и ко всему, что возможно. Ведь достаточно просто вводить везде один и тот же электронный адрес и одинаковый пароль – просто подарок даже для неопытного хакера…

Пароль в личном кабинете на сайте

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

• получать счета на свой e-mail,
• оплачивать их,
• использовать бонусы для бесплатных звонков,
• вызывать мастера для ремонта
• и т.д.

Но для доступа к этому нужно сначала пройти регистрацию на сайте, чтобы у Вас появился там личный кабинет. А для регистрации опять-таки понадобится e-mail и пароль. Можно ввести

Правильный пароль

А теперь о том, как грамотно составить пароль.

Надеюсь, никто из вас не использует комбинацию цифр 0123456789.

Почему? Правильно, такой аккаунт взломают в первые же дни его существования. И смысл создания секретности вообще потеряется.

Для своей идентификации ( а это и есть login и password) необходимо придумать такие данные, которые не так легко подобрать.

Отмечу, что злоумышленники делают это не вручную, а с помощью хакерских программ. И занимает это минимум времени.

Таким образом, ваши данные могут попасть в руки к нечестным людям, и хорошо, если это будет просто форум, а не данные платежных систем.

Пароли принято делить на простые и сложные.

Простые – это сочетание цифр. Они должны идти в разнобой, но ни в коем случае не по порядку. И не повторятся.

Приведу варианты плохих паролей:

• 123456789;
• 987654321;
• 777777777;
• 010101010.

Не используйте в записях номера телефонов, даты рождения, особенно, если в вашем профиле эта информация является общедоступной.

Обратите внимание на длину секретного кода. Большее количество символов сложнее подобрать.

Стоит отметить, что некоторые системы (например, телефонные приложения) допускают короткие комбинации до 4 букв.

Но в большинстве случаев требуется вводить от восьми символов, и это не только цифры, но и буквы.

Так, как вы уже поняли, выглядит сложный пароль. Сочетание цифр и букв при составлении пароля с большей вероятностью обезопасит ваши данные от несанкционированного доступа.

Общепринято использовать латинский алфавит. Добавит надежности использование разного регистра символов (то есть применяем заглавные и обычные буквы).

Password, который вы будете писать при первичной регистрации вам еще понадобится, поэтому его следует запомнить.

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

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

Многие сайты оснащены функцией восстановления забытого пароля, но, скажу вам честно, обычно это 9, если не больше, кругов ада.

Конечно можно все записать на бумажный носитель. Но, на мой взгляд этот вариант также не очень правильный. Запискам тоже свойственно теряться.

Мой совет: выучить Password и login наизусть, вводить их как можно чаще не используя автоматических запоминаний, или включайте двухфакторную авторизацию, которая доступна уже на многих сервисах.

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

Не можете запомнить? Создайте единое хранилище для ваших паролей к примеру используя программу Keepass, где всегда их можно посмотреть и они будут надежно защищены от третьих лиц.

Ни под каким предлогом не передавайте данные для входа в аккаунты посторонним людям: ни друзьям, ни модераторам, ни рекламщикам. Этим вы обезопасите себя и свой профиль

Проверка надежности пароля

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

Регистрация на государственных сайтах

Это непростая история – пройти регистрацию на государственном сайте, ибо начинается  она с неподтвержденной  учетной записи, а далее потребуется подтвержденная.  Для примера возьмем сайт Госуслуг, подробно о регистрации на этом сайте ЗДЕСЬ. В этой статье речь только про маленькую важную часть при регистрации — про пароли.

Для регистрации на сайте Госуслуг вводим настоящие имя, фамилию, электронную почту (1, 2, 3 на рис. 2).

Далее нужно открыть электронную почту и там найти письмо, в котором надо будет кликнуть по ссылке, чтобы подтвердить, что Вы хозяин почты. После этого потребуется придумать пароль для сайта Госуслуг и желательно также, чтобы этот пароль отличался от пароля для вашей электронной почты.

Для примера вводим для регистрации на сайте Госуслуг

Как видите, пароль для сайта Госуслуг отличается от пароля для электронной почты. Вам предстоит придумать свой пароль, указанный выше пароль использовать нельзя, он известен всем, кто прочитает эту статью.

Социальная инженерия

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

Стандарт saml

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Стандарты oauth и openid connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2022 гг., а текущая версия 2.0 опубликована в 2022 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

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

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

1. Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
2. Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
3. Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Схема авторизации на ассиметричных ключах и эллиптических кривых

Пусть в процессе аутентификации клиент подпишет случайную строку message своим закрытым ключом e. А сервер проверит подпись клиента, зная его открытый ключ D. Но если клиент может таким образом доказать, что ключ D принадлежит ему, и только ему, то нам уже не нужно «заморачиваться» с хранением хэша от пароля!

Схема на базе протокола srp

SRP — протокол парольной аутентификации, устойчивый к прослушиванию и MITM-атаке и не требующий третьей доверенной стороны. Имеет свой RFC2945. Есть производные от него стандарты для протоколов Telnet, TLS. Единственный из представленных, который проводит окончательную взаимную авторизацию обеих сторон. Хорошо описан как в Википедии, так и на Хабре пользователем @datacompboy.

Тем не менее, для генерации секретного ключа x протокол использует устаревшие подходы: (уже  не криптостойкую) функцию SHA-1 и  простую схему хеширования: x = hash(salt | hash(login | ‘:’ | pass). В свете современных тенденций к взлому паролей брутфорсом офлайн на специализированных ПЛИС или арендованных кластерах, данный подход должен быть улучшен, использованием scrypt.

Для реализации схемы нам понадобятся: большое простое число N, генератор g мультипликативной группы Z*N и параметр k = hash(N, g). В качестве g и N стороны используют числа, определенные в RFC-5054. Так, например, g = 2, а «мультипликативная группа» – это просто степени двойки; точнее их остатки по модулю N.

Процесс регистрации пользователя в системе:

1. Клиент отправляет серверу свой login и свою 256-битную версию соли salt_C.

2. Сервер генерирует свою 256-битную версию соли salt_S для пользователя login.

3. Клиент формирует общую 256-битную соль: salt = salt_C ^ salt_S.

4. Клиент вычисляет секретный 256-битный ключ x = scrypt(password, salt) от своего пароля

5. Клиент вычисляет верификатор пароля V = g^x (mod N).

6. Клиент посылает на сервер пару (salt_C, V).

7. Сервер вычисляет общую соль salt аналогично клиенту в п. 3.

8. Сервер хранит учетные данные пользователя в форме: login, salt, V.

Процесс авторизации пользователя в системе:

1. Клиент формирует случайное 256-битное число a и вычисляет 2048-битное A = g^a (mod N).

2. Клиент делает запрос на сервер со своим login, и числом А.

3. Сервер формирует случайное 256-битное число b и вычисляет 2048-битное B = (kv g^b) (mod N).

4. Сервер посылает клиенту пару (salt, B).

5. Обе стороны вычисляют u = hash(A | B). В оригинальном RFC указано, что параметр u – 32-битное беззнаковое, получаемое от результата примененной хеш-функции hash(A | B).

6. Пользователь вычисляет свой ключ x на основе пароля и соли, аналогично пп. 4 процесса регистрации.

7. Пользователь вычисляет сессионный ключ K следующим образом: S = (B – kg^x)^{a ux} (mod N); K = hash(S).

8. Сервер вычисляет сессионный ключ K следующим образом: S = (Av^u)^b (mod N); K = hash(S).

9. Пользователь вычисляет M₁ = hash( hash(N) ^ hash(g) | hash(login) | salt | A | B | K ) и отправляет на сервер.

10. Сервер дождавшись от пользователя M₁, проверяет его, производя аналогичные п. 9 вычисления.

11. Сервер вычисляет M₂ = hash( A | M₁ | K ) и отправляет клиенту.

12. Клиент проверяет M₂ сервера. На этом этапе аутентификация считается завершенной.

В функции hash операция | означает конкатенацию аргументов. Если предполагается, что ключ K не будет использоваться в дальнейшем взаимодействии (например, для шифрования или аутентификации пакетов), то пп. 9-12 к исполнению обязательны. А если будет, то проверка излишняя, т.к. несогласованный ключ не позволит проводить корректное взаимодействие. Но я бы всё-таки оставил эти пункты обязательными.

Согласно спецификации, пользователь должен прервать аутентификацию, если получил B = 0 (mod N) или u = 0. (Полагаю, что B не должно быть также равно –kV, т.к. в этом случае клиент получит S = 0a ux (mod N) = 0).

https://www.youtube.com/watch?v=Y4k2Vt-mJNM

Сервер должен прервать аутентификацию, если получил A = 0 (mod N). Клиент должен первым доказать, что получил тот же ключ K. Если клиенту это не удалось, сервер должен прервать аутентификацию, без своего доказательства K.

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Подведём итоги