Привет, Хабр! Меня зовут Екатерина Саяпина, я Product Owner личного кабинета платформы МТС Exolve. В разных проектах я вижу одну и ту же ошибку: разработчики пытаются внедрить как можно больше разных методов аутентификации. В результате падает безопасность, пользователям сложнее ориентироваться, а разработчикам — управлять и поддерживать продукт.
В этой статье я объясню отличие аутентификации от авторизации, идентификации от верификации и опишу два простых варианта ее реализации с использованием node.js: по SMS и через Telegram.
Разница в терминах: верификация, аутентификация, авторизация, идентификация
В мире информационной безопасности термины «верификация», «аутентификация», «авторизация» и «идентификация» часто используются от балды. Чтобы правильно реализовывать их в своих системах, важно четко понимать, что они значат и чем различаются. Дальше — разберем каждый термин подробно и посмотрим, какими нормативными документами они регулируются.
Идентификация: «Так-с, а это ведь Вася»
Идентификация — процесс определения, кто именно пытается получить доступ к системе. Это может быть просто имя пользователя или email-адрес. Например, когда вы вводите свой логин в форму входа, система идентифицирует вас по этому идентификатору.
Нормативный документ: ISO/IEC 24760-1:2011 определяет рамки идентификации в системах управления идентичностью.
Аутентификация: «Ну, Вася, докажи, что ты это ты»
Аутентификация подтверждает подлинность предоставленного идентификатора путем проверки доказательств: пароля, отпечатка пальца или голосового образца. Например, после указания логина вы вводите пароль, который система сравнивает с сохраненным хешем этого пароля.
Нормативный документ: ISO/IEC 29115:2013 устанавливает требования к уровням уверенности в аутентификации.
Верификация: «А не накладные ли у тебя, Вася, усы, лапы и хвост»
Верификацию часто путают с аутентификацией. На самом деле это процесс подтверждения, что система или компонент соответствует определенным требованиям или стандартам. В контексте безопасности это может включать такие процессы, как двухфакторная аутентификация (например, после ввода пароля требуется ввести код, полученный по SMS).
Нормативный документ: ISO/IEC 15408-1:2022 (Common Criteria) описывает процедуры верификации для оценки безопасности информационных технологий.
Авторизация: «Вася, ты сюда ходи, а туда не ходи»
Авторизация определяет, какие действия или ресурсы доступны пользователю после его идентификации и аутентификации. Например, может быть доступ к чтению файлов, но не к их изменению.
Нормативный документ: ОСТ 34.003-90 описывает процессы авторизации в информационных системах.
Когда мы поняли, что значат эти термины и чем они отличаются, можно двигаться дальше. Посмотрим, как реализовать аутентификацию и подтвердить подлинность аккаунта с помощью того же SMS-сообщения.
Два самых распространенных метода аутентификации — по e-mail и SMS
Они часто используются из-за простоты и удобства, но у них много недостатков:
Уязвимы к фишингу и социальной инженерии. Злоумышленники часто маскируются, отправляют письма с поддельными ссылками, по которым пользователи переходят и передают свои учетные данные.
Есть техническая возможность перехвата сообщений. Так в руках злоумышленников оказываются одноразовые пароли, ссылки для сброса пароля и другие конфиденциальные данные.
Злоумышленники могут угнать сам аккаунт. Например, использовать SIM-своппинг и перенести номер пользователя на свою SIM-карту или взломать почтовый аккаунт.
Для повышения безопасности и удобства пользователей эти методы дополняются другими и используются в рамках многофакторной аутентификации (MFA). Рассмотрим несколько способов.
Варианты реализации MFA
Требования к аутентификации меняются в зависимости от поведения пользователя и контекста (географического положение или устройства), но при повышении рисков используется многофакторная аутентификация (MFA). Есть разные варианты ее реализации:
Через приложение для аутентификации. В таком приложении пользователь получает одноразовый код (OTP), который обновляется каждые 30 секунд и не зависит от сетевых подключений.
С помощью api специальных сервисов и платформ. Приложения для аутентификации предоставляют только OTP, а через API можно настроить свою систему аутентификации с дополнительной защитой и проверками. Мы в МТС Exolve предоставляем CPaaS-платформу, где можно реализовать отправку OTP через SMS.
С использованием сторонних систем: биометрии, SSO, аппаратных токенов или смарт-карт.
Реализация аутентификации через SMS
Ниже покажу, как создать простой сервер на Node.js для отправки OTP через SMS API МТС Exolve. В реальном приложении рекомендую работать с базой данных для хранения OTP и создать дополнительные меры безопасности: ограничение времени действия OTP и защиту от брутфорс-атак.
Шаг 1. Предварительная настройка
Создайте папку, в которой будет храниться проект. Войдите в нее:
C:\work\>mkdir otp-authentication
C:\work\>cd otp-authentication
Инициализируйте проект Node.js и установите зависимости:
C:\work\otp-authentication>npm init -y
C:\work\otp-authentication>npm install express body-parser axios dotenv
Создайте файл .env в корневой папке проекта и добавьте туда API-ключ вашего приложения МТС Exolve:
EXOLVE_API_KEY = Bearer ВАШ_ТОКЕН_АВТОРИЗАЦИИ_EXOLVE
Шаг 2. Создание сервера и маршрута для отправки OTP
Создайте файл index.js и добавьте следующий код:
const expressFramework = require('express');
const bodyParserMiddleware = require('body-parser');
const axiosHttp = require('axios');
require('dotenv').config();
const app = expressFramework();
const port = process.env.PORT || 3000;
app.use(bodyParserMiddleware.json());
let otpStorage = {}; // Временное хранилище для одноразовых паролей, но лучше использовать базу данных
// Данные для тестирования
const senderPhoneNumber = "ВАШ_НОМЕР_ОТПРАВИТЕЛЯ_EXOLVE"; // Номер отправителя или альфа-имя
const receiverPhoneNumber = "ВАШ_НОМЕР_ПОЛУЧАТЕЛЯ_СМС"; // Номер получателя
const otpMessageText = "Это ваш временный код: "; // Текст сообщения для пароля
// Маршрут для отправки пароля
app.post('/send-otp', async (req, res) => {
const otp = Math.floor(100000 + Math.random() * 900000); // Генерация 6-значного одноразового пароля
const smsText = `${otpMessageText} ${otp}`;
console.log("Отправка пароля на номер телефона ", receiverPhoneNumber);
console.log("Текст отправленного сообщения ", smsText);
try {
const response = await axiosHttp.post('https://api.exolve.ru/messaging/v1/SendSMS', {
number: senderPhoneNumber,
destination: receiverPhoneNumber,
text: smsText
}, {
headers: {
'Authorization': process.env.EXOLVE_API_KEY,
'Content-Type': 'application/json'
}
});
console.log("API Response:", response.data);
// Сохранение пароля для будущей проверки (используйте базу данных в реальном приложении)
otpStorage[receiverPhoneNumber] = otp;
res.status(200).send("Пароль успешно отправлен");
} catch (error) {
if (error.response) {
console.error('Ошибка при отправке: ', error.response.data);
res.status(500).send(`Не удалось отправить пароль: ${error.response.data.error.message}`);
} else {
console.error('Ошибка: ', error.message);
res.status(500).send(`Не удалось отправить пароль: ${error.message}`);
}
}
});
app.listen(port, () => {
console.log(`Сервер слушает на http://localhost:${port}`);
});
Шаг 3. Тестирование с использованием Postman
Postman позволяет легко тестировать маршруты API. Для этого сначала запустите сервер Node.js:
C:\work\otp-authentication>node index.js
Дальше откройте Postman и создайте новый запрос:
Метод: POST.
Во вкладке Headers добавьте новый заголовок:
Key: Content-Type.
Value: application/json.
Во вкладке Body добавьте тело запроса: выберите raw и убедитесь, что тип данных установлен на JSON. Нажмите на кнопку Send и отправьте запрос. Тело запроса можно оставить пустым.
Реализация аутентификации через мессенджеры
Мессенджеры — это относительно новый канал аутентификации. Они конкурируют с социальными сетями, но обладают более высокой защитой, так как коммуникация часто зашифрована end-to-end. Но все же остается риск, что доступ к ним могут получить неавторизованные лица.
Посмотрим, как организовать аутентификацию через бота Telegram с помощью Node.js и фреймворк Express.js. Мессенджер предлагает удобный и мощный API для разработки различных функций авторизации.
Шаг 1. Создание telegram-бота
Откройте Telegram и найдите бота @BotFather.
Стартуйте диалог с @BotFather и создайте в нем своего бота командой /newbot. Ответьте на несколько уточняющих вопросов, и у вас появится свой бот.
В конце @BotFather выдаст токен доступа. Позже мы используем его для отправки сообщения через вашего бота.
Шаг 2. Инициализация проекта
Для файлов проекта создайте папку. Войдите в нее:
$ mkdir my-telegram-bot
$ cd my-telegram-bot
Инициализируйте новый проект Node.js:
$ npm init -y
Эта команда создаст файл package.json, который будет управлять зависимостями проекта.
Установите необходимые зависимости:
$ npm install express node-telegram-bot-api
Express — это фреймворк для Node.js, а node-telegram-bot-api — библиотека для работы с Telegram Bot API.
Шаг 3. Разработка сервера
В созданной папке проекта создайте файл index.js. Откройте его в редакторе кода и добавьте код для запуска сервера Express и настройки бота:
const expressFramework = require('express');
const TelegramBotLibrary = require('node-telegram-bot-api');
const botToken = 'ВАШ_ТЕЛЕГРАМ_БОТ_ТОКЕН_ОТ_BOTFATHER';
const bot = new TelegramBotLibrary(botToken, { polling: true });
const app = expressFramework();
const portNumber = 3000;
app.listen(portNumber, () => {
console.log(`Порт запущенного сервера ${portNumber}`);
});
// Определение обработчика сообщений
bot.on('message', (message) => {
const chatIdentifier = message.chat.id;
// Отправка сообщения пользователю
bot.sendMessage(chatIdentifier, 'Аутентификация пройдена!');
});
Замените 'ВАШ_ТЕЛЕГРАМ_БОТ_ТОКЕН_ОТ_BOTFATHER'
на ваш настоящий токен.
Шаг 4. Тестирование функциональности
Запустите сервер:
$ node index.js
Откройте вашего бота в Telegram и отправьте команду /start или любое другое сообщение. Если все настроено правильно, бот должен ответить: «Аутентификация пройдена!».
Поздравляю, у вас готова базовая аутентификация пользователей с использованием telegram-бота. В дальнейшем можно расширять и дорабатывать функциональность, добавляя другие методы аутентификации и безопасности.
Выводы
Выбор метода аутентификации зависит от задач проекта. SMS OTP подходят для широкой аудитории, потому что доступ к телефону сейчас есть почти у всех. Мессенджеры — более быстрый и надежный способ, но так вы ограничены их пользователями. В любом случае, оба этих метода лучше использовать в рамках многофакторной аутентификации в зависимости от контекста и доверия к пользователю, а еще — применять шифрование и механизмы защиты от брутфорс-атак.
Через облачную платформу МТС Exolve можно реализовать разные сценарии общения с клиентами: обратный звонок, кол-трекинг, защиту номера, выбор исходящего номера, SMS-информирование и другие. Если вам интересна эта тема, то оставляйте вопросы комментариях, объясню подробнее.
Комментарии (9)
aax
05.08.2024 12:10+1В п. 4.2.9. Письма от 24.03.2014 No 49-Т ЦБ РФ рекомендует использовать SMS в качестве канала уведомления клиента о совершении операции, но никак не о передаче таким образом кодов подтверждения операций. Последнее банки делают на свой страх и риск используя канал не предназначенный для предачи инфы по защищенным транзакциям.
Существует судебная практика, где суды взыскивают с банка убытки даже в случае наличия SMS-информирования (Апелляционное определение Санкт-Петербургского городского суда от 28.04.2016 No 33-7902/2016 по делу No 2-6233/2015, Апелляционное определение Санкт-Петербургского городского суда от 11.06.2015 No 33-8603/2015 по делу No 2-622/2015).
Логика судов в этих делах заключается не в том, что SMS-информирование небезопасно, а в том, что сам клиент ничего не нарушал.
aax
Автор, в силу специфики бизнеса, оживляет мягко говоря старо-костыльную тему с мобильником при идентификации/аутентификации. Так вижу.
Касаемо F2A, там где это нужно, есть более совершенные методы - Госуслуги, например, ввели F2A посредством TOTP (Time-based One-Time Password Algorithm). Одноразовый код, при этом, автономно генерерируется на стороне клиента.
Необходимость как в услугах сотовой сети, так и в передаче дополнительной личной информации(актуальный телефонный номер абонента, привязанный в РФ к паспортным данным) исчезает полностью.
Пользователю предоставляется индивидуальный ключ(цифробуквенный код), для открытого алгоритма RFC 6238, а далее пользователь сам решает на каком вычислительном устройстве он будет генерить одноразовый код авторизации(при желании хоть на покупном брелке, хоть на Ардуине).