Аналоги Электронных Подписей

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

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

1. Взять лист бумаги, написать на нем сообщение, купить конверт, запаковать письмо, отнести на почту;

2. Зайти в одну из социальных сетей, мессенджер или электронную почту и написать сообщение там.

Казалось бы, 2-й вариант очевиден, потому что не нужно совершать много действий и тратить много времени, по сравнению с 1-м вариантом, но зато 1-й вариант безопаснее, ведь конверт никто не сможет перехватить (кроме сотрудников таможни), а электронное сообщение может попасть в чужие руки намного проще.

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

Регистрация — это процесс создания учетной записи.

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

Аутентификация — процедура проверки подлинности, например:

• проверка подлинности пользователя путём сравнения введённого им пароля (для указанного логина с паролем), сохранённым в базе данных пользовательских логинов;

• подтверждение подлинности электронного письма путём проверки цифровой подписи письма по открытому ключу отправителя;

• проверка контрольнной суммы файла на соответствие сумме, заявленной автором этого файла.

  Аутентификация всегда происходит перед регистрацией/авторизацией.

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

Давайте рассмотрим процесс аутентификации более подробно.

I. Блок пользовательских данных

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

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

1. Личные пользовательские данные: имя, фамилия, дата рождения, пол и так далее.

2. Номер телефона и/или электронная почта.

3. Пароль.

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

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

II. Отправка данных на сервер авторизации и получение токена

Давайте наконец-то подберемся к определению электронной подписи:

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

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

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

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

Например: SHA128, SHA256, SHA512. Все названия имеют структуру SHAN. Число N в названии алгоритма означает, что на выходе мы получим строку фиксированной длины N бит независимо от того, какие данные поступят на вход, то есть даже если на вход поступит пустой буфер, он все равно будет хеширован.

Вот пример хеширования пути, используя алгоритм SHA512:

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

Для более глубокого понимания, я написал свою программу аутентификации используя язык программирования JAVA и фреймворк Spring Security, подняв локальный сервер на хосте 8081, где:

1. Происходит регистрирация пользователя с почтой “zaitcevaleksandr@gmail.com” и паролем “0000”, используя POST-запрос (т.е. запрос для отправки данных на сервер) по адресу ”localhost:8081/auth/register” и генерация токена.

2. Далее, меняя пароль на “0001”, но не меняя пользователя, токен не будет сгенерирован по той причине, что такой пользователь уже есть в базе данных.

3. Теперь авторизовываемся, вводя корректные данные, опять же используя POST-запрос по адресу “localhost:8081/auth/login” и происходит генерация нового токена доступа к веб-сервису.

4. Если изменим данные на некоректные (например, введем опять неправильный пароль “0001”), то токен не будет сгенерирован, а пользователь останется не аутентифицированным.

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

III. Двухфакторная аутентификация

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

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

1. Приходит сообщение с кодом авторизации на электронную почту.

2. Приходит сообщение с кодом авторизации в СМС сообщении на ваш номер телефона.

3. Генерируется пароль, в специальном приложении. Примеры таких приложений:
   MobilePass+, Google Authenticator.

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

Как это работает ?

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

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

package com.project.security.mail;   import org.springframework.beans.factory.annotation.Autowired; import org.springframework.mail.SimpleMailMessage; import org.springframework.mail.javamail.JavaMailSender; import org.springframework.stereotype.Service;  import java.util.Date; import java.util.Random;   @Service public class ConfirmEmailConfig {      @Autowired     private JavaMailSender javaMailSender;      @Autowired     private ConfirmEmailRepository confirmEmailRepository;      private static final long CONFIRM_CODE_MIN_VALUE = 100000;     private static final long CONFIRM_CODE_MAX_VALUE = 999999;     private static final long CONFIRM_TIME = 600 * 1000;     public static final String CONFIRM_SUBJECT_MESSAGE = "Confirm your account.";     public static final String CONFIRM_BODY_MESSAGE = "Your confirm code: ";     public static final String MAIL = "phystechdate@gmail.com";     public static final String WELCOME_MESSAGE_SUBJECT = "Welcome to Phystech Date !!!";     public static final String WELCOME_MESSAGE_BODY = "You confirmed your mail. Start to use Phystech Date already now.";      public void GenerateCode(String username) {         long confirmCode = (new Random()).nextLong(CONFIRM_CODE_MAX_VALUE  -                                                    CONFIRM_CODE_MIN_VALUE) +                                                    CONFIRM_CODE_MIN_VALUE;          Date currentTime = new Date();         currentTime.setTime(new Date().getTime() + CONFIRM_TIME);         confirmEmailRepository.save(new ConfirmCode(username,                                                     confirmCode,                                                     currentTime));         Send(username, CONFIRM_SUBJECT_MESSAGE, CONFIRM_BODY_MESSAGE +                                                 confirmCode);     }      public void Send(String toEmail, String subject, String body) {         SimpleMailMessage message = new SimpleMailMessage();         message.setFrom(MAIL);         message.setTo(toEmail);         message.setText(body);         message.setSubject(subject);         javaMailSender.send(message);     }  } 

Итоги

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