Аналоги Электронных Подписей
В современном мире очень важна безопасность в Интернете. Каждый день по разным каналам передаются «тонны» информации и думаю, каждый хотел бы обезопасить себя от злоумышленников. В рамках данной статьи зайдет речь о двух наиболее распространенных аналогах электронных подписей — токене доступа (авторизации) и аутентификационном коде.
Давайте представим повседневную ситуацию. Вы хотите кому-нибудь написать сообщение: родственникам, друзьям, преподавателю — не важно кому, главное — хотите. Есть 2 варианта, как это можно сделать:
Взять лист бумаги, написать на нем сообщение, купить конверт, запаковать письмо, отнести на почту;
Зайти в одну из социальных сетей, мессенджер или электронную почту и написать сообщение там.
Казалось бы, 2-й вариант очевиден, потому что не нужно совершать много действий и тратить много времени, по сравнению с 1-м вариантом, но зато 1-й вариант безопаснее, ведь конверт никто не сможет перехватить (кроме сотрудников таможни), а электронное сообщение может попасть в чужие руки намного проще.
Чтобы начать общение с кем-либо, сначала нужно зарегистрироваться или авторизоваться, если уже зарегистрирован, но никто никогда не задумывается, как происходит процесс называемый аутентификацией.
Регистрация - это процесс создания учетной записи.
Авторизация — это ускоренный процесс входа в веб-сервис, с помощью уже ранее созданной учетной записи.
Аутентификация - процедура проверки подлинности, например:
проверка подлинности пользователя путём сравнения введённого им пароля (для указанного логина с паролем), сохранённым в базе данных пользовательских логинов;
подтверждение подлинности электронного письма путём проверки цифровой подписи письма по открытому ключу отправителя;
проверка контрольнной суммы файла на соответствие сумме, заявленной автором этого файла.
Аутентификация всегда происходит перед регистрацией/авторизацией.
Аутентификация и последующая авторизация
Аутентификация может происходить всегда абсолютно по-разному: в зависимости от того, насколько хорошо позаботился разработчик веб-сервиса о безопасности его пользователей (клиентов).
Давайте рассмотрим процесс аутентификации более подробно.
I. Блок пользовательских данных
Мы должны суметь как-то идентифицировать себя перед тем, как начнем общение. Для этого во всех современных сервисах, которые не являются одностраничными сайтами предусмотрена регистрация или авторизация.
Обычно пользователь, обращаясь к определенному веб-сервису предоставляет идентичный набор данных, а конкретно:
Личные пользовательские данные: имя, фамилия, дата рождения, пол и так далее.
Номер телефона и/или электронная почта.
Пароль.
Номер телефона или электронная почта предоставляются неспроста. Если кто бы то ни был, захочет создать несколько аккаунтов, то ему придется постараться найти несколько номеров телефонов, почт. В большинстве случаев почты связаны с номерами телефона, а номера телефона можно получить только в салонах связи мобильного оператора, то есть придется предоставлять паспортные данные для оформления каждого нового номера телефона.
Пароль нужен для того, чтобы предварительно ограничить доступ к своему аккаунту (но только предварительно, дальше зайдет речь, почему пароли сами по себе небезопасны).
II. Отправка данных на сервер авторизации и получение токена
Давайте наконец-то подберемся к определению электронной подписи:
Электронная подпись - это информация в электронном в виде, которая формируется при помощи уникальной комбинации символов, позволяющих идентифицировать владельца, а также его личные данные.
Токен — это средство идентификации пользователя или отдельного сеанса работы в компьютерных сетях и приложениях. Токен в большинстве случаев имеет ограниченное время жизни и, глядя на определение электронной подписи, можно сказать, что токен — это один из аналогов электронной подписи.
Сервер авторизации — проверяет подлинность информации, которую предоставил пользователь, а также выдает авторизационные токены.
Получение пользователем доступа к ресурсам веб-сервиса
Пусть пользователь ввел свои личные данные, номер телефона и/или электронную почту, пароль и нажал кнопку зарегистрироваться/авторизоваться. Пароли при попадании в блок пользовательских данных, уже непосредственно шифруются кодировками предназначенными для шифрования паролей (например, одна из распространенных кодировок для шифрования паролей — BCrypt). Перед тем, как данные будут отправлены на сервер авторизации, их нужно зашифровать. Шифрование позволяет усилить уровень безопасности передаваемых данных, а происходит оно при помощи хэш-функций. Одно из самых распространенных семейств хэш-функций — это семейство SHA.
Например: SHA128, SHA256, SHA512. Все названия имеют структуру SHAN. Число N в названии алгоритма означает, что на выходе мы получим строку фиксированной длины N бит независимо от того, какие данные поступят на вход, то есть даже если на вход поступит пустой буфер, он все равно будет зашифрован.
Вот пример шифрования пути, используя кодировку SHA512:
Генерация хэша по алгоритму SHA512 из строки «c:\windows\notepad.exe»
Также, если вы захотите попробовать зашифровать данные, то это можно сделать по ссылке.
Для более глубокого понимания, я написал свою программу аутентификации используя язык программирования JAVA и фреймворк Spring Security, подняв локальный сервер на хосте 8081, где:
Происходит регистрирация пользователя с почтой «zaitcevaleksandr@gmail.com» и паролем »0000», используя POST-запрос (т.е. запрос для отправки данных на сервер) по адресу «localhost:8081/auth/register» и генерация токена.
Далее, меняя пароль на »0001», но не меняя пользователя, токен не будет сгенерирован по той причине, что такой пользователь уже есть в базе данных.
Теперь авторизовываемся, вводя корректные данные, опять же используя POST-запрос по адресу «localhost:8081/auth/login» и происходит генерация нового токена доступа к веб-сервису.
Если изменим данные на некоректные (например, введем опять неправильный пароль »0001»), то токен не будет сгенерирован, а пользователь останется не аутентифицированным.
Генерация JWT-токена и демонстрация его работы
Существует и ряд других причин, по которым токен может быть не сгенерирован. После генерации токена, пользователь может взаимодействовать с ресурсами сервиса. Также хотелось бы отметить, что токен может содержать права доступа для различных пользователей. Например, у модератора сервиса и обычного пользователя могут различаться права и токен доступа может нести эту информацию.
III. Двухфакторная аутентификация
Несомненно, способы защиты клиентов развиваются и интегрируются в веб-сервисы с каждым днем, но эволюционируют и способы взлома клиентских акаунтов. Несмотря на то, что токен, казалось бы, сводит уровень угрозы к нулю, оказывается, существует банальный способ получить доступ к чужому аккаунту — подобрать пароль. Зачастую, разработчики выставляют требования к паролю (например, пароль должен содержать заглавные и прописные буквы, цифры и специальные символы, состоять минимум из 8 символов), но 80% пользователей ассоциируют пароль с чем-либо, чтобы было легко запомнить (например, это может быть дата рождения или город проживания и т.д и т.п.), поэтому подобрать пароль становится проще, тем более у хакеров есть свой словарь, где содержатся наиболее встречающиеся пароли. Разработчики веб-сервиса не обязуют, но рекомендуют пользоваться двухфакторной аутентификацией.
Двухфакторная аутентификация — аутентификация, которая предусматривает из себя процедурную проверку подлинности, но дважды. После того, как вы вводите данные от аккаунта (номер телефона/почту + пароль):
Приходит сообщение с кодом авторизации на электронную почту.
Приходит сообщение с кодом авторизации в СМС сообщении на ваш номер телефона.
Генерируется пароль, в специальном приложении. Примеры таких приложений:
MobilePass+, Google Authenticator.
В каждом из трех вариантов аутентификационный код имеет время жизни (обычно небольшое, чтобы злоумышленник не успел подобрать код).
Двухфакторная аутентификация
Как это работает ?
Обычно реализовано это следующим образом: в базе данных существует таблица с идентификатором пользователя, аутентификационным кодом и временем его истекания (отсчитывается от момента попытки входа клиента в сервис). Более того, генерация аутентификационного кода — это отдельный микросервис, который скрыт от всех, так что у злоумышленника остается 1 вариант — это перебор, что сводит шансы взлома к нулю, поскольку время перебора ограничено.
Таблица в базе данных
Только после успешного ввода пароля и аутентификационного кода, пользователь может начать взаимодействовать с ресурсами сервиса.
Итоги
В рамках данной статьи, я рассказал о встречающихся уязвимостях в веб-сервисах, рассмотрел два наиболее популярных аналога электронной подписи — токен доступа и аутентификационный код.
