Идентификация и аутентификация пользователя это разные действия. Первое, что делает пользователь, соединяясь с компьютером, это идентификация. Цель этой операции состоит в вводе пользователем своего пользовательского имени, личного кода, итд. Этот идентификатор должен быть зарегистрирован в базе данных пользователей. Затем система проверяет, является ли пользователь тем, за кого себя выдаёт. Это проверка идентификатора (личтности) пользователя, или аутентификация пользователя.
Идентификация – процедура распознавания субъекта по его идентификатору. В процессе регистрации субъект предъявляет системе свой идентификатор и она проверяет наличие в своей базе данных. Субъекты с известными системе идентификаторами считаются легальными (законными), остальные субъекты относятся к нелегальным.
Аутентификация – процедура проверки подлинности субъекта, позволяющая достоверно убедиться в том, что субъект, предъявивший свой идентификатор, на самом деле является именно тем субъектом, идентификатор которого он использует. Для этого он должен подтвердить факт обладания некоторой информацией, которая может быть доступна только ему одному (пароль, ключ и т.п.)
Авторизация – процедура предоставления субъекту определенных прав доступа к ресурсам системы после прохождения им процедуры аутентификации. Для каждого субъекта в системе определяется набор прав, которые он может использовать при обращении к её ресурсам.
При аутентификации от пользователя требуется подтвердить свою личность, и для этого за основу берутся следующие понятия:
Благодаря своей простоте аутентификация с помощью пароля получила наибольшее распространение. Основная слабость этого метода в том, что пароль часто трудно сохранить в секрете. Хороший пароль (например, случайная комбинация букв) достаточно надёжен, но часто пользователи предпочитают пароли, которые легко запомнить (например, важные даты). Такие пароли легко подобрать, и существуют базы данных распространённых паролей и программы, использующие это базы данных для незаконного проникновения в компьютерные системы через Интернет. Пароль можно похитить визуально или с помощью электронного слежения: сотрудник может подсмотреть пароль при вводе его на клавиатуре, или может использовать программу, напоминающая процедуру аутентификации, чтобы пользователь непреднамеренно свой ввёл сам.
Для защиты паролей от прослушивания, нужно применять их одностороннее шифрование, т.е. алгоритм хеширования. Хеширование это алгоритм одностороннего шифрования, при котором вычисляется контрольная сумма какой-то информации, которая всегда одна и та же, если только она не изменена. Пароли в системе сохраняются в зашифрованном виде и их невозможно расшифровать к изначальному виду. Для проверки введённого пользователем пароля, пароль зашифровывается тем же алгоритмом хеширования, и полученный результат сравнивается с сохранённым в системе. Если аутентификация происходит через терминал, то на сервер не передаётся незашифрованный пароль, а применяется метод вызова-ответа (Challenge-Response) вместе с техникой шифрования.
Симметричные криптосистемы не годятся для эффективной аутентификации. Например, проиcходит покупка товара через интернет с помощью кредитной карты: если покупатель и продавец договорились использовать симметричный ключ, то сообщение, содержащее номер кредитной карты, можно открыть с помощью договорённого ключа. Но как безопасно обмениваться ключом симметричного шифрования междy партнёрами? Ключ нельзя просто переслать, поскольку третье лицо может захватить ключ и с его помощью расшифровать отправленный номер кредитной карты. Поэтому современные каналы безопасной связи используют для аутентификации ассиметричное шифрование.
Многофакторная аутентификация (MFA) - это компонент управления доступом, который требует от пользователей подтверждения своей личности с использованием как минимум двух различных факторов проверки, прежде чем получить доступ к веб-сайту, мобильному приложению или другому онлайн-ресурсу. С MFA, если один фактор скомпрометирован, у злоумышленника все еще есть как минимум еще один барьер, который нужно преодолеть, прежде чем он сможет получить доступ к учетной записи цели.
Многофакторная аутентификация (MFA) использует несколько технологий для аутентификации личности пользователя. Напротив, однофакторная аутентификация (или просто «аутентификация») использует единую технологию для подтверждения подлинности пользователя. С MFA пользователи должны комбинировать технологии проверки как минимум из двух разных групп или факторов аутентификации. Вот почему использование PIN-кода с паролем (как из категории «что-то, что вы знаете») не будет считаться многофакторной аутентификацией, в то время как использование PIN-кода с распознаванием лиц (из категории «что-то вы есть») будет считаться. Обратите внимание, что пароль не требуется для получения права на MFA. Решение MFA может быть полностью беспарольным. Также допустимо использовать более двух методов аутентификации. Однако большинству пользователей нужна беспроблемная аутентификация (возможность проверки без необходимости выполнения проверки).
Ниже приведены распространенные технологии используемые в MFA:
Мошенничество с захватом учетных записей (ATO) - это растущая угроза кибербезопасности, подпитываемая изощренной социальной инженерией (например, фишинговыми атаками), мобильным вредоносным ПО и другими атаками. Правильно разработанные и реализованные методы MFA более надежны и эффективны против изощренных атак, чем устаревшая однофакторная аутентификация по имени пользователя и паролю, которая может быть легко взломана киберпреступниками с помощью широко доступных хакерских инструментов.
Банки, финансовые учреждения и другие организации, предоставляющие финансовые услуги, начинают переходить от приложений с внутренним хостингом к облачным приложениям типа «программное обеспечение как услуга» (SaaS), таким как Office 365, Salesforce, Slack и OneSpan Sign. В результате количество конфиденциальных данных и файлов, размещенных в облаке, увеличивается, что повышает риск утечки данных скомпрометированной личной информации (PII), что приводит к захвату учетных записей. Угрозу безопасности усугубляет то, что пользователи приложений SaaS могут находиться где угодно, а не только в корпоративных сетях. Дополнительные уровни безопасности, обеспечиваемые MFA, по сравнению с простой защитой паролем могут помочь противостоять этим рискам. В дополнение к факторам знания, владения и принадлежности некоторые технологии MFA используют факторы местоположения, такие как адреса управления доступом к среде (MAC) для устройств, чтобы гарантировать, что ресурс доступен только с определенных устройств.
Еще один способ воздействия облака на MFA - облачный хостинг решений MFA, которые, как правило, более рентабельны в реализации, менее сложны в администрировании и более гибки, чем локальные решения. Облачные продукты могут предоставлять больше возможностей, ориентированных на мобильных пользователей, таких как мобильные приложения для аутентификации, push-уведомления, контекстная аналитика, такая как геолокация, и биометрия.
Потребители должны использовать MFA всякий раз, когда они получают доступ к конфиденциальным данным. Хороший пример - использование банкомата для доступа к банковскому счету. Владелец учетной записи использует MFA, комбинируя то, что он знает (PIN-код), и то, что у него есть (карта банкомата). Точно так же при входе в учетную запись Facebook, Google или Microsoft из нового места или устройства потребители используют MFA, вводя что-то, что они знают (пароль), и второй фактор, что-то, что у них есть (мобильное приложение, которое получает push или SMS-уведомление).
Безопасность на основе ролей. Роли часто используются в финансовых и деловых приложениях для применения политики. Например, приложение может установить ограничение на размер транзакции в зависимости от того, является ли сделавший запрос пользователь участником определенной роли. Служащие могут иметь доступ к проведению транзакций, размер которых меньше определенного порога, менеджер может иметь больший предел, а вице-президент — еще больший или неограниченный. Безопасность на основе ролей также можно использовать, когда приложению для завершения действия требуются многократные утверждения. В качестве примера можно привести систему закупок, в которой каждый сотрудник может создать заявку на покупку, но преобразовать эту заявку в заказ на покупку для отправки поставщику может только агент по закупкам. Больше про безопасность на основе ролей можно узнать на сайте Microsoft.
Большинство веб-приложений, предлагающих учетные записи пользователей, делают это в части, чтобы предоставить определенным посетителям доступ к определенным страницам в пределах сайта. В большинстве сетевых мессажебоард сайтов, например, все пользователи — анонимные и аутентифицированные, могут просматривать записи мессажебоард, но только пользователи, прошедшие проверку подлинности, могут посетить веб-страницу, чтобы создать новую запись. И могут существовать административные страницы, доступные только определенному пользователю (или определенному набору пользователей). Более того, функции на уровне страницы могут различаться для каждого пользователя. При просмотре списка записей прошедшие проверку пользователи показывают интерфейс для оценки каждой записи, в то время как этот интерфейс недоступен для анонимных посетителей. С небольшой разметкой можно заблокировать определенные веб-страницы или целые каталоги, чтобы они были доступны только определенному подмножеству пользователей. Функции на уровне страницы можно включать или отключать в зависимости от текущего пользователя с помощью программных и декларативных средств.
Для аутентификации в веб-приложениях используется протокол HTTP. HTTPS — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Протокол HTTP предназначен для обеспечения связи между клиентами и серверами. HTTP работает как протокол запроса-ответа между клиентом и сервером. Веб-обозреватель может быть клиентом, а приложение на компьютере, на котором размещается веб-узел, может быть сервером. таким образом клиент (обозреватель) отправляет HTTP-запрос на сервер, затем сервер возвращает ответ клиенту. Ответ содержит сведения о состоянии запроса, а также может содержать запрошенное содержимое.
Два часто используемых метода запроса-ответа между клиентом и сервером: Get и POST.
В следующей таблице сравниваются два метода HTTP: Get и POST.
| GET | POST | |
|---|---|---|
| Кнопка возврата/перезагрузка | Безвредны | Данные будут повторно отправлены (браузер должен предупредить пользователя о том, что данные будут повторно отправлены) |
| Закладка | Можно закладка | Не может быть Закладка |
| Кэшированные | Может кэшироваться | Не кэшируется |
| Тип кодировки | application/x-www-form-urlencoded | application/x-www-form-urlencoded or multipart/form-data. Использование многокомпонентной кодировки для двоичных данных |
| Истории | Параметры остаются в журнале обозревателя | Параметры не сохраняются в журнале обозревателя |
| Ограничения по длине данных | Да, при отправке данных метод Get добавляет данные в URL-адрес; и длина URL ограничена (максимальная длина URL составляет 2048 символов) | Без ограничений |
| Ограничения типа данных | Разрешены только символы ASCII | Никаких ограничений. Двоичные данные также разрешены |
| Безопасности | Get менее безопасен по сравнению с POST, поскольку отправляемые данные являются частью URL-адреса | POST немного безопаснее, чем Get, поскольку параметры не сохраняются в журнале обозревателя или в журналах веб-сервера |
| Видимость | Данные видны всем в URL Данные не отображаются в URL-адресе |
Таким образом, любые важные данные — логины, пароли, данные карты, персональные данные — лучше передавать с помощью метода POST. Также метод POST поддерживает тип кодирования данных multipart/form-data, что позволяет передавать файлы. Никогда не используйте Get при отправке паролей или другой конфиденциальной информации!
Пример простейшей реализации аутентификации в MVC приложении с использованием метода POST на языке C#.
//Класс данных
public class User
{
public string UName { get; set; }
public string UPassword { get; set; }
public byte[] UPass { get; set; }
public string URole { get; set; }
public string UText { get; set; }
public bool Ulogin { get; set; }
}
//Метод контроллера
public IActionResult Index(User user)
{
User Check_user = new User()
{
UName = "User",
UPass = GetHash("123"),
URole = "User",
UText = "Your role is user.",
Ulogin = false
};
try
{
byte[] Hash = GetHash(user.UPassword);
if (Hash.SequenceEqual(Check_user.UPass))
{
Check_user.Ulogin = true;
}
}
catch (Exception)
{
}
return View(Check_user);
}
//Представление
@model WebApplication3.Models.User
@{
ViewData["Title"] = "Home Page";
}
<div class="text-center">
<h1 class="display-4">Welcome</h1>
<p>Learn about <a href="https://docs.microsoft.com/aspnet/core"> building Web apps with ASP.NET Core</a>.</p>
@if (!Model.Ulogin)
{
@using (Html.BeginForm("Index", "Home", FormMethod.Post))
{
@Html.AntiForgeryToken()
<div class="form-group">
@Html.LabelFor(m => m.UName)
@Html.TextBoxFor(m => m.UName, "", new { @class = "form-control", @placeholder = "Name" })
</div>
<div class="form-group">
@Html.LabelFor(m => m.UPassword)
@Html.PasswordFor(m => m.UPassword, new { @class = "form-control", @placeholder = "Password" })
</div>
<div class= "form-group" >
<input type = "submit" name = "submit" class= "btn btn-primary" value = "Login" />
</div>
}
}
else
{
<p>@Model.UText</p>
}
</div>
Большинство взломов сайтов это не банальные кража данных или поломка шаблона сайта, а попытка использовать сайт для распространения спама или создания на нем временного хранилища файлов незаконного характера. Другие, не менее распространенные случаи злоупотребления взломанными сайтами, заключаются в использовании сайтов для ботнета или для скрытого майнинга криптовалюты или интернет-вымогателей.
Для обеспечения хотя бы базовой безопасности веб-приложений необходимо:
Регулярно обновлять ПО веб-приложения. Регулярное обновление программного обеспечения имеет важное значение для обеспечения безопасности веб-приложения. Когда в программном обеспечении обнаруживается уязвимость, хакеры моментально пытаются ее эксплуатировать. Однако не стоит перед этим забывать делать резервную копию.
Устанавливать SSL-сертификаты. На сайте, который защищен SSL-сертификатом, злоумышленники не могут перехватывать личные данные посетителей: логины, пароли, данные банковских карт и другую информацию. SSL-сертификат гарантирует их защиту. Компании, выпускающие SSL-сертификаты, называются удостоверяющими центрами, которые, в свою очередь, делятся на коммерческие и некоммерческие. В случае взлома платного сертификата удостоверяющий центр может выплатить компенсацию.
Хешировать пароли. Пароли на сайте всегда должны храниться в виде зашифрованных значений, предпочтительно с использованием алгоритма хеширования (например, SHA). Использование этого алгоритма означает, что при аутентификации пользователей вы будете сверять только зашифрованные значения. В случае взлома и кражи захешированных паролей это минимизирует ущерб, поскольку расшифровка таких паролей невозможна. Единственное, что с ними можно сделать, это провести атаку с использованием словаря или угадывать каждую комбинацию скриптом, что в вычислительном плане долго и нецелесообразно. Также крайне важно использовать надежные пароли и учить этому посетителей сайта, чтобы защитить их учетные записи. Внедрение таких требований к паролям, как минимальное количество символов, наличие заглавных букв и цифр поможет защитить пользовательские данные в долгосрочной перспективе.
Выполнять резервное копирование. Резервное копирование может спасти сайт даже тогда, когда нет надежды вернуть работоспособность проекту. Для бизнеса в сети наличие резервного копирования должно быть не менее важным, чем продажи. Если сайт пропадет, торговля не только будет остановлена, но нужно будет создавать сайт с нуля, что требует инвестиций и времени. Таким образом, резервное копирование спасает, если: произошел взлом злоумышленниками, от случайного удаления файлов сайта, от падения сервера, пожара и других катастроф.