Двухфакторная аутентификация что это – Аутентификация — что это такое и почему сейчас повсеместно используется двухфакторная аутентификация

Почему большинство людей не используют двухфакторную аутентификацию? / GlobalSign corporate blog / Habr

Прошло почти семь лет с того момента, как Google представила двухфакторную аутентификацию (2FA), но до сих пор практически никто не использует её.

На январской конференции по информационной безопасности Usenix’s Enigma 2018 с презентацией выступил инженер-программист Google Гжегож Милка (Grzegorz Milka). Он опубликовал печальную статистику того, как обычные пользователи относятся к своей безопасности: менее чем на 10% активных аккаунтов Google используется 2FA и всего около 12% американцев используют менеджеры паролей (статистика Pew Research Center). Недавно эта тема обсуждалась на Geektimes.

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

Google является одним из первопроходцев по внедрению 2FA среди крупных интернет-сервисов. Кроме того, компания активно пропагандирует этот метод и распространяет приложение Google Authentificator App для привязки аккаунта к конкретному устройству. Двухфакторная аутентификация работает и просто по SMS.

Небезопасность 2FA по SMS

Нужно отметить, что 2FA по SMS уже официально признана небезопасным методом аутентификации из-за неустранимых уязвимостей в сигнальной системе Signaling System 7 (SS7), которая используется сотовыми сетями для взаимодействия между собой.

Специалисты компании Positive Technologies ещё несколько лет назад показали, как происходит перехват SMS. Если вкратце, то атака представляет собой процедуру регистрации абонента в зоне действия «фальшивого» MSC/VLR. Исходными данными являются IMSI абонента и адрес текущего MSC/VLR, что можно получить с помощью соответствующего запроса в сети SS7. После регистрации абонента в зоне «фальшивого» MSC/VLR он перестанет получать входящие вызовы и SMS, а все его SMS будут приходить на узел атакующего.

Конкретный случай проведения атаки со всеми необходимыми командами и скриншотами опубликован в корпоративном блоге Positive Technologies на Хабре.

Перехват чужих SMS — вовсе не теоретические изыски, такие атаки уже проводились неоднократно как хакерами, так и спецслужбами разных стран (см. статью «Спецслужбы начали перехватывать SMS-коды авторизации Telegram»). Хотя в российском случае это могли быть вовсе не спецслужбы, ведь атака через SS7 доступна любому желающему: кто угодно мог перехватить эти SMS, необязательно это были спецслужбы.

Так или иначе, 2FA по SMS уже не является безопасным способом двухфакторной аутентификации. Это официально признал NIST (Национальный институт стандартов и технологий США), который в 2016 году опубликовал новую версию Руководства по цифровой аутентификации. Там сказано, что аутентификация по SMS более не поддерживается и не будет включена как рекомендованный способ аутентификации в будущих версиях Руководства.

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

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

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

Неудобно?

Собственно, предположение о неудобстве подтвердил и Гжегож Милка, тот самый докладчик из Google. Журналисты The Register спросили у него, почему Google не включит двухфакторную аутентификацию по умолчанию для всех аккаунтов? Ответ был такой: юзабилити. «Речь о том, сколько пользователей уйдёт, если вынудим их использовать дополнительную безопасность».

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

Но судя по статистике, пользователям даже такой способ 2FA кажется излишне сложным. Любое лишнее нажатие клавиши, любой дополнительный экран — это затруднение, ухудшение удобства использования. Даже самое простейшее действие в интернете может вызвать затруднение у части аудитории. Google говорит, что при попытке установить этот защитный механизм более 10% пользователей не смогли ввести в окно код, присланный по SMS.

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

Анатомия типичного взлома. Из презентации Google. Как видим, злоумышленник успевает осуществить все действия за 15 минут

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

Google как может пытается бороться с такой активностью, уведомляя владельца аккаунта разными способами и подталкивая его активировать 2FA. Но как говорила Маша Седова, сооснователь компании Elevate Security, тривиальные способы не работают из-за общего

отсутствия интереса к безопасности у пользователей.

Герои двухфакторной аутентификации, или как «походить в чужих ботинках»

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

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

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

Под катом мы расскажем как попытались представить себя на месте лиц, принимающих решение о внедрении 2FA в организации, и поняли, как их заинтересовать.

Для желающих немного теории:

Как воруют паролиКогда выясняется, что сотрудники используют простые пароли («Qq1234567«), то обычно устанавливают жесткие политики по работе с паролями. Например: пароль должен быть не короче 10 символов, минимум одна буква строчная и одна прописная, минимум одна цифра и один прочий символ; пароль не должен включать общеупотребительных слови и числовых последовательностей; пароль должен меняться раз в месяц и не должен совпадать с 12 предыдущими паролями.

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

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

В состав дистрибутива Kali Linux, формально предназначенного для тестирования на проникновение (penetration testing) входит программное обеспечение, которое может быть для перехвата и анализа трафика для получения паролей при аутентификации, причем делает это практически в автоматическом режиме. Не нужно иметь высокой квалификации или специальных знаний — достаточно скачать установить дистрибутив Kali Linux и запустить программу.

Если сотрудник работает вне офиса (командировка, выезд к заказчику, отпуск, домашний офис), то для кражи паролей создают фальшивые точки доступа с тем же именем, что и легальные, например с помощью WiFi-Pumpkin из того же Kali Linux. Человек подключается в Шереметьево к точке доступа «Sheremetievo-WiFi» и весь его трафик становится доступен злоумышленнику. Другой способ кражи паролей — заражение точек доступа вредоносным кодом, после чего злоумышленник получает возможность анализировать проходящий трафик.

Как работает двухфакторная аутентификацияАутентификация — это процесс проверки личности пользователя. Подтвердить свою личность пользователь может с помощью нескольких факторов:

• Фактор знания («я знаю»). Пользователь знает свой уникальный секретный пароль или PIN-код. Пароль можно украсть с помощью специального программного и аппаратного обеспечения, или просто подсмотреть. А также получить с помощью социальной инженерии, когда жертва самостоятельно передаст свой пароль злоумышленнику.
• Фактор обладания («я имею»). Пользователь обладает физическим устройством, которые он должен использовать в процессе аутентификации. Обычно таким устройством является USB-токен или смарт-карта (также может выступать в качестве электронного пропуска в офис). Для аутентификации токен или смарт-карту нужно подключить к компьютеру или мобильному устройству. Также можно использовать программный или аппаратный генератор одноразовых паролей.
• Фактор свойства («я есть»). Биометрические показатели, такие как отпечатки пальцев, рисунок радужной оболочки глаза, ДНК и т.п. Фактор, который кажется очень надежным, но на самом деле имеет множество недостатков. Качественные биометрические считыватели достаточно дороги, а дешевые не достаточно надежны. Отпечатки пальцев научились подделывать, сканеры радужной оболочки глаза часто ошибаются, а идентификацию по лицу можно обмануть с помощью трехмерной модели головы. Кроме того, количество показателей сильно ограничено (10 пальцев, два глаза, один голос). Скомпрометированный пароль можно сменить, утерянный токен — заменить, а вот рубить пальцы, если информация об отпечатке попадет к злоумышленнику, как-то не очень правильно (а отрастить новые и вовсе невозможно). Также не будем рассматривать болезненную процедуру лазерного выжигания отпечатков пальцев.

Комбинация из двух связанных между собой факторов и является двухфакторной аутентификацией.

В большинстве случаев пользователю необходимо подключить токен/смарт-карту к компьютеру и ввести PIN-код, открывающий доступ к токену (для некоторых ОТР токенов нужно будет ввести код с экрана устройства).

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

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

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

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

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

В последнее время вместо передачи кодов через SMS предлагается использовать PUSH-уведомления. Утверждается, что они безопаснее, однако это не так, поскольку все уведомления проходят через Push Notification Service, прежде, чем попадают на устройство пользователя. И, например, Apple Developer Program напрямую запрещает (License Agreement, Приложение 1, пункт 4) данные действия ввиду небезопасности таких уведомлений. Подробности описаны в этой весьма толковой статье.

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

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

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

Мы создали четырех персонажей: двух директоров и двух начальников ИТ-отделов для двух компаний — крупной и средней. И для каждого их них написали свою историю. Вот первая из них.

Федор

Компания

Нефтеперерабатывающий завод ФлайТек, часть крупного нефтяного холдинга ФлайОйл. Всего на НПЗ работает более 3 тыс. человек, но с вычислительной техникой связано около тысячи. Это как вспомогательные подразделения (управленцы, бухгалтерия, логистика, служба сбыта, маркетинг), так и производственники, работающие с АСУ ТП (автоматизированные системы управления технологическими процессами — производством нефтепродуктов) через терминалы на Microsoft Windows.

Должность

Руководитель ИТ-департамента. Руководит командой из 10 человек.

За что отвечает

За работоспособность ИТ-инфраструктуры предприятия. Грубо говоря, чтобы никто ни на что не жаловался.

1. Федору известно, что низкая ИТ-квалификация сотрудников может приводить к сбоям на их ПК. Он организовал службу технической поддержки, которая работает с подобными незначительными проблемами.
2. Федор знает, что оборудование стареет и может отказать, сделав работу сотрудника, отдела или всего завода невозможной. Поэтому он организовал резервный фонд на случай замены и прописал политики экстренной замены — процедуру и ответственных.
3. Федору известно, что из-за атак хакеров, аппаратных сбоев, пожаров, наводнений и пр. данные могут быть повреждены. Он организовал создание резервных копий данных и прописал политику восстановления данных в случае сбоя.
4. Федор знает, что в серверном ПО происходят сбои, которые могут поставить под угрозу работу офиса или производство. Поэтому он использует методы оперативной диагностики неисправностей и прописал политики восстановления работоспособности серверного ПО.
5. Федор боится вирусов. Он знает, что они могут заразить компьютеры сотрудников или системы АСУ ТП. Поэтому он закупил и установил антивирусное ПО и настроил его регулярное обновление.
6. Федор боится сетевых взломщиков, поэтому он использует средства обнаружения и предотвращения вторжений и прочие сетевые средства защиты.

Что общего в этих шести пунктах? Федор понимает, что если что-то случится в рамках вышеперечисленного, то спросят с него. Иногда за причину (вирусы, если они будут бесконтрольно распространяться по сети), иногда за последствия (отсутствие резервных копий при восстановлении).

За что не отвечает

1. За то, что хотя и имеет источником ИТ, но попадает в зону ответственности других руководителей. Например, если сломается терминал оператора АСУ ТП, то за это отвечает Федор. Если же оператор АСУ ТП введет неправильную команду, то это будут проблемы производственников. По их заказу Федор может дать команду доработать софт АСУ ТП так, чтобы он распознавал неверные команды и не давал их выполнять. Но ТЗ будут писать производственники, Федор будет только посредником и ответственным за внедрение и беспроблемность эксплуатации. Более близкий к рассматриваемой теме пример — если сотрудник, легально обладающий правами работы в ИТ-инфраструктуре предприятия, попробует использовать их для деструктивных действий или захочет использовать корпоративную информацию в личных целях, то Федор будет отвечать только в случае, если было дано больше прав, чем необходимо сотруднику в данный момент для выполнения его должностных обязанностей. В остальном это будет проблема службы безопасности и непосредственного руководителя сотрудника.
2. За реализацию рисков, принятых руководством. От всего защититься невозможно или слишком дорого. Если руководство решит, например, что полная утрата серверов из-за пожара или наводнения невозможна из-за особенностей расположения или защиты серверной, то денег на резервные сервера не выделят. А в случае возникновения проблем ответственность будет нести уже руководство.

Однако! Это справедливо, если Федор заранее проинформировал руководство об этих рисках. Дело в том, что топ-менеджеры редко являются специалистами в ИТ, поэтому они могут даже не предполагать сколько всего плохого может случиться. Поэтому если происходит что-то, о чем топы не были осведомлены, то виновным объявят Федора. Поэтому он старается предупредить о возможных проблемах, но после этого ответственность за принятие решение переходит на топов.

Профессиональное мировоззрение

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

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

Когда Федор узнает о новой угрозе, в которую он верит, то пишет простой план защиты от данной угрозы с указанием того, какие ресурсы (люди, ПО, hardware) для этого потребуются. Этот план представляется топам. Если топы согласны выделит соответствующие ресурсы, то защита от конкретной угрозы внедряется на НПЗ, Но поскольку топы — не профессионалы в ИТ, то согласие на реализацию плана зачастую зависит от правильной подачи Федора. От того, хочется ли ему на самом деле внедрить защиту от данной угрозы или хочется переложить потенциальную ответственность на топов, если угроза и правда окажется реальной, а план по ее предотвращению не будет принят.

Текущее отношение к 2FA

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

По мнению Федора, за борьбу с утечками отвечает служба безопасности (департамент ИТ только может предоставить необходимые технические средства). В конце концов, не заставляют же ИТ следить за хранением бумажных документов и железных ключей от офиса — даже если ИТ и обслуживает установленные по заказу СБ камеры видео-наблюдения.

Федор считает, что в компании есть политики, обязывающие сотрудников надежно хранить свои пароли, подписанные самими сотрудниками. И если что-то произойдет, то конкретный человек понесет наказание за свою беспечность. А надзирает за исполнением политик пусть СБ. Тут, правда, нельзя не заметить, что теория часто расходится с практикой. Особо важного или заслуженного сотрудника не тронут даже если он себе на лбу пароль напишет, а бесправному низкоуровневому сотруднику все равно, так как терять ему особо нечего. Лишь использование технических средства может всех уравнять.

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

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

А пока очень хотелось бы узнать, что думаете о 2FA вы — и в виде свободных комментариев и в виде ответов на опрос. Считаете ли вы эту тему актуальной? Реальна ли с вашей точки зрения угроза? Стоит ли предприятиям тратить деньги на внедрение 2FA?

И кстати — узнали ли вы себя в Фёдоре, или быть может на него похож ваш начальник / коллега? А возможно мы ошиблись и у подобных персонажей совсем другие интересы сфера ответственности?

Двухфакторная аутентификация: что это такое?

В последнее время все чаще встречается выражение «двухфакторная аутентификация», иногда — «многофакторная аутентификация», что по сути одно и то же. Слово «аутентификация» также неизвестно многим пользователям. О чем же идет речь?

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

Двухфакторная аутентификация — это метод идентификации пользователя, при котором обеспечивается дополнительная защита аккаунта: первая — пароль от аккаунта, вторая — допустим, специальный код, который приходит на номер телефона, привязанный к аккаунту. Нужно это для того, чтобы злоумышленник, даже если у него есть логин и пароль от вашего аккаунта, не смог в него попасть. Если прежде двухфакторную использовали редко, то сейчас многие сервисы вообще без нее не обходятся. Сюда можно отнести, например, онлайн-банкинг. Еще двухфакторная аутентификация встречается в Instagram, ВКонтакте, Одноклассники, Twitter и прочих популярных социальных сетях.

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

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

Существуют и другие методы двухфакторной аутентификации, не связанные с СМС-сообщениями:

• Код, который приходит на электронную почту

• Генераторы кодов

• Мобильные приложения для смартфонов

• Сканирование отпечатка пальца

Простой пример использования двухфакторной аутентификации на базе Gmail — постового сервиса Google. Изначально данная функция должна быть включена в настройках почтового ящика. Далее при входе указываете свой логин (адрес e-mail):

Вводите пароль и нажимаете «Далее».

Указывает код, который пришел на привязанный номер телефона.

Далее, если данные верны, вы окажитесь в своем почтовом ящике.

Аутентификация — Википедия

Аутентифика́ция (англ. authentication < греч. αὐθεντικός [authentikos] «реальный, подлинный» < αὐτός [autos] «сам; он самый») — процедура проверки подлинности, например:

В русском языке термин применяется, в основном, в области информационных технологий.

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

Аутентификацию не следует путать с авторизацией (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).

С древних времён перед людьми стояла довольно сложная задача — убедиться в достоверности важных сообщений. Придумывались речевые пароли, сложные печати. Появление методов аутентификации с применением механических устройств сильно упрощало задачу, например, обычный замок и ключ были придуманы очень давно. Пример системы аутентификации можно увидеть в старинной сказке «Приключения Али́-Бабы́ и сорока разбойников». В этой сказке говорится о сокровищах, спрятанных в пещере. Пещера была загорожена камнем. Отодвинуть его можно было только с помощью уникального речевого пароля: «Сим-Сим, откройся!».

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

Документы, определяющие стандарты аутентификации

ГОСТ Р ИСО/МЭК 9594-8-98 — Основы аутентификации[править | править код]

Настоящий стандарт:

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

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

FIPS 113 — COMPUTER DATA AUTHENTICATION[править | править код]

Настоящий стандарт устанавливает Data Authentication Algorithm(DAA), который может быть использован для обнаружения несанкционированных изменений данных, как преднамеренных, так и случайных, стандарт основан на алгоритме, указанном в Data Encryption Standard(DES) Federal Information Processing Standards Publication(FIPS PUB) 46, и совместим как с Department of the Treasury’s Electronic Funds and Security Transfer Policy and the American National Standards Institute(ANSI) так и с Standard for Financial Institution Message Authentication.

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

В любой системе аутентификации обычно можно выделить несколько элементов:

• субъект, который будет проходить процедуру
• характеристика субъекта — отличительная черта
• хозяин системы аутентификации, несущий ответственность и контролирующий её работу
• сам механизм аутентификации, то есть принцип работы системы
• механизм управления доступом, предоставляющий определённые права доступа субъекту

Элемент аутентификации	Пещера 40 разбойников	Регистрация в системе	Банкомат
Субъект	Человек, знающий пароль	Авторизованный пользователь	Держатель банковской карты
Характеристика	Пароль «Сим-Сим, откройся!»	Тайный пароль	Банковская карта и персональный идентификатор
Хозяин системы	40 разбойников	Предприятие, которому принадлежит система	Банк
Механизм аутентификации	Волшебное устройство, реагирующее на слова	Программное обеспечение, проверяющее пароль	Программное обеспечение, проверяющее карту и персональный идентификатор
Механизм управления доступом	Механизм, отодвигающий камень от входа в пещеру	Процесс регистрации, управления доступом	Разрешение на выполнение банковских действий

Ещё до появления компьютеров использовались различные отличительные черты субъекта, его характеристики. Сейчас использование той или иной характеристики в системе зависит от требуемой надёжности, защищённости и стоимости внедрения. Выделяют 3 фактора аутентификации:

• Нечто, что нам известно, например, какая-либо секретная информация. Это тайные сведения, которыми должен обладать только авторизованный субъект. Секретом может быть некая фраза или пароль, например в виде устного сообщения, текстового представления, комбинации для замка или личного идентификационного номера (PIN). Парольный механизм может быть довольно легко воплощён и имеет низкую стоимость. Но имеет существенные недостатки: сохранить пароль в тайне зачастую бывает сложно, злоумышленники постоянно придумывают новые способы кражи, взлома и подбора пароля (см. бандитский криптоанализ, метод грубой силы). Это делает парольный механизм слабозащищённым.
• Нечто, чем мы обладаем, например, какой-либо уникальный физический объект. Здесь важно обстоятельство обладания субъектом каким-то неповторимым предметом. Это может быть личная печать, ключ от замка, для компьютера это файл данных, содержащих характеристику. Характеристика часто встраивается в особое устройство аутентификации, например, пластиковая карта, смарт-карта. Для злоумышленника заполучить такое устройство становится более сложно, чем взломать пароль, а субъект может сразу же сообщить в случае кражи устройства. Это делает данный метод более защищённым, чем парольный механизм, однако стоимость такой системы более высокая.
• Нечто, что является неотъемлемой частью нас самих — биометрика. Характеристикой является физическая особенность субъекта. Это может быть портрет, отпечаток пальца или ладони, голос или особенность глаза. С точки зрения субъекта, данный способ является наиболее простым: не надо ни запоминать пароль, ни переносить с собой устройство аутентификации. Однако биометрическая система должна обладать высокой чувствительностью, чтобы подтверждать авторизованного пользователя, но отвергать злоумышленника со схожими биометрическими параметрами. Также стоимость такой системы довольно велика. Но, несмотря на свои недостатки, биометрика остается довольно перспективным фактором.

Аутентификация при помощи электронной подписи[править | править код]

Федеральный закон от 06.04.2011 N 63-ФЗ «Об электронной подписи» (с изменениями) предусматривает следующие виды электронной подписи:

• Простая электронная подпись — электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом.
• Неквалифицированная электронная подпись — электронная подпись, которая:

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

• Квалифицированная электронная подпись — электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:

1. ключ проверки электронной подписи указан в квалифицированном сертификате;
2. для создания и проверки электронной подписи используются средства электронной подписи, получившие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.

Аутентификация по паролям[править | править код]

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

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

Форма ввода связки логин-пароля

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

Простая аутентификация имеет следующий общий алгоритм:

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

Введённый субъектом пароль может передаваться в сети двумя способами:

• Незашифрованно, в открытом виде, на основе протокола парольной аутентификации (Password Authentication Protocol, PAP)
• С использованием шифрования SSL или TLS. В этом случае неповторимые данные, введённые субъектом, передаются по сети защищённо.

Защищённость[править | править код]

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

Использование многоразовых паролей имеет ряд существенных недостатков. Во-первых, сам эталонный пароль или его хешированный образ хранятся на сервере аутентификации. Зачастую хранение пароля производится без криптографических преобразований, в системных файлах. Получив доступ к ним, злоумышленник легко доберётся до конфиденциальных сведений. Во-вторых, субъект вынужден запоминать (или записывать) свой многоразовый пароль. Злоумышленник может заполучить его, просто применив навыки социальной инженерии, без всяких технических средств. Кроме того, сильно снижается защищенность системы в случае, когда субъект сам выбирает себе пароль. Зачастую им оказывается какое-то слово или сочетание слов, присутствующие в словаре. В ГОСТ 28147-89 длина ключа составляет 256 бит (32 байта). При использовании генератора псевдослучайных чисел ключ обладает хорошими статистическими свойствами. Пароль же, который является, например, словом из словаря, можно свести к псевдослучайному числу длиной 16 бит, что короче ГОСТ-ового ключа в 16 раз. При достаточном количестве времени злоумышленник может взломать пароль простым перебором. Решением этой проблемы является использование случайных паролей или ограниченность по времени действия пароля субъекта, по истечении которого пароль необходимо поменять.

Базы учетных записей[править | править код]

На компьютерах с ОС семейства UNIX базой является файл /etc/master.passwd (в дистрибутивах Linux обычно файл /etc/shadow, доступный для чтения только root), в котором пароли пользователей хранятся в виде хеш-функций от открытых паролей, кроме этого, в этом же файле хранится информация о правах пользователя. Изначально в Unix-системах пароль (в зашифрованном виде) хранился в файле /etc/passwd, доступном для чтения всем пользователям, что было небезопасно.

На компьютерах с операционной системой Windows NT/2000/XP/2003 (не входящих в домен Windows) такая база данных называется SAM (Security Account Manager — Диспетчер защиты учётных записей). База SAM хранит учётные записи пользователей, включающие в себя все данные, необходимые системе защиты для функционирования. Находится в каталоге %windir%\system32\config\.

В доменах Windows Server 2000/2003 такой базой является Active Directory.

Однако более надёжным способом хранения аутентификационных данных признано использование особых аппаратных средств (компонентов).

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

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

Заполучив однажды многоразовый пароль субъекта, злоумышленник имеет постоянный доступ к взломанным конфиденциальным сведениям. Эта проблема решается применением одноразовых паролей (OTP — One Time Password). Суть этого метода — пароль действителен только для одного входа в систему, при каждом следующем запросе доступа — требуется новый пароль. Реализован механизм аутентификации по одноразовым паролям может быть как аппаратно, так и программно.

Технологии использования одноразовых паролей можно разделить на:

• Использование генератора псевдослучайных чисел, единого для субъекта и системы
• Использование временных меток вместе с системой единого времени
• Использование базы случайных паролей, единой для субъекта и для системы

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

Во втором методе используются временные метки. В качестве примера такой технологии можно привести SecurID. Она основана на использовании аппаратных ключей и синхронизации по времени. Аутентификация основана на генерации случайных чисел через определенные временные интервалы. Уникальный секретный ключ хранится только в базе системы и в аппаратном устройстве субъекта. Когда субъект запрашивает доступ в систему, ему предлагается ввести PIN-код, а также случайно генерируемое число, отображаемое в этот момент на аппаратном устройстве. Система сопоставляет введенный PIN-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введённого субъектом.

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

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

Аутентификация с помощью SMS[править | править код]

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

Процедура такой аутентификации включает в себя следующие шаги:

1. Ввод имени пользователя и пароля
2. Сразу после этого PhoneFactor (служба безопасности) присылает одноразовый аутентификационный ключ в виде текстового SMS-сообщения.
3. Полученный ключ используется для аутентификации

Привлекательность данного метода заключается в том, что ключ получается не по тому каналу, по которому производится аутентификация (out-of-band), что практически исключает атаку типа «человек посередине». Дополнительный уровень безопасности может дать требование ввода PIN-кода мобильного средства.

Данный метод получил широкое распространение в банковских операциях через интернет.

Биометрическая аутентификация[править | править код]

Методы аутентификации, основанные на измерении биометрических параметров человека, обеспечивают почти 100 % идентификацию, решая проблемы утраты паролей и личных идентификаторов.

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

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

Наиболее используемые биометрические атрибуты и соответствующие системы[править | править код]

• Отпечатки пальцев. Такие сканеры имеют небольшой размер, универсальны, относительно недороги. Биологическая повторяемость отпечатка пальца составляет 10⁻⁵ %. В настоящее время пропагандируются правоохранительными органами из-за крупных ассигнований в электронные архивы отпечатков пальцев.
• Геометрия руки. Соответствующие устройства используются, когда из-за грязи или травм трудно применять сканеры пальцев. Биологическая повторяемость геометрии руки около 2 %.
• Радужная оболочка глаза. Данные устройства обладают наивысшей точностью. Теоретическая вероятность совпадения двух радужных оболочек составляет 1 из 10⁷⁸.
• Термический образ лица. Системы позволяют идентифицировать человека на расстоянии до десятков метров. В комбинации с поиском данных по базе данных такие системы используются для опознания авторизованных сотрудников и отсеивания посторонних. Однако при изменении освещенности сканеры лица имеют относительно высокий процент ошибок.
• Распознавание по лицу. Системы на основе данного подхода позволяют идентифицировать персону в определенных условиях с погрешностью не более 3 %. В зависимости от метода позволяют идентифицировать человека на расстояниях от полуметра до нескольких десятков метров. Данный метод удобен тем, что он позволяет реализацию штатными средствами (веб-камера и т. п.). Более сложные методы требуют более изощренных устройств. Некоторые (не все) методы обладают недостатком подмены: можно провести идентификацию подменив лицо реального человека на его фотографию.
• Голос. Проверка голоса удобна для использования в телекоммуникационных приложениях. Необходимые для этого 16-разрядная звуковая плата и конденсаторный микрофон стоят менее 25 $. Вероятность ошибки составляет 2 — 5 %. Данная технология подходит для верификации по голосу по телефонным каналам связи, она более надежна по сравнению с частотным набором личного номера. Сейчас развиваются направления идентификации личности и его состояния по голосу — возбужден, болен, говорит правду, не в себе и т. д.
• Ввод с клавиатуры. Здесь при вводе, например, пароля отслеживаются скорость и интервалы между нажатиями.
• Подпись. Для контроля рукописной подписи используются дигитайзеры

В то же время биометрическая аутентификация имеет ряд недостатков:

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

Аутентификация через географическое местоположение[править | править код]

• Аутентификация посредством GPS
• Аутентификация, основанная на местоположении выхода в интернет

Аутентификация посредством GPS[править | править код]

Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местонахождению. Данный защитный механизм основан на использовании системы космической навигации, типа GPS (Global Positioning System).

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

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

Аппаратура GPS проста и надежна в использовании и сравнительно недорога. Это позволяет её использовать в случаях, когда авторизованный удаленный пользователь должен находиться в нужном месте.

Аутентификация, основанная на местоположении выхода в интернет[править | править код]

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

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

Многофакторная аутентификация[править | править код]

В последнее время всё чаще применяется так называемая расширенная, или многофакторная, аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищённость системы.

В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).

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

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

Можно привести сравнительную таблицу:

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

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

Таким образом, можно выделить несколько семейств аутентификации:

Аутентификация пользователя на PC:

• Шифрованное имя (login)
• Password Authentication Protocol, PAP (связка логин-пароль)
• Карта доступа (USB с сертификатом, SSO)
• Биометрия (голос, отпечаток пальца/ладони/радужки глаза)

Аутентификация в сети:

В операционных системах семейства Windows NT 4 используется протокол NTLM (NT LAN Manager — Диспетчер локальной сети NT). А в доменах Windows 2000/2003 применяется гораздо более совершенный протокол Kerberos.

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

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

• Ричард Э. Смит. Аутентификация: от паролей до открытых ключей = Authentication: From Passwords to Public Keys First Edition. — М.: Вильямс, 2002. — С. 432. — ISBN 0-201-61599-1.
• под. редакцией А.А. Шелупанова, С.Л. Груздева, Ю.С. Нахаева. Аутентификация. Теория и практика обеспечения доступа к информационным ресурсам. = Authentication. Theory and practice of ensuring access to information resources.. — М.: Горячая линия – Телеком, 2009. — С. 552. — ISBN 978-5-9912-0110-0.
• Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
• Linn J. Common Authentication Technology Overview,.
• Bellovin S. and M. Merritt. Limitations of the Kerberos Authentication System.
• Kaufman, C. Distributed Authentication Security Service (DASS).
• Anderson, B.,. TACACS User Identification Telnet Option. — December 1984.
• Tardo J. and K. Alagappan. SPX: Global Authentication Using Public Key Certificates. — М.California, 1991. — С. pp.232-244.
• А.А. Гладких, В.Е. Дементьев. Базовые принципы информационной безопасности вычислительных сетей.. — Ульяновск: УлГТУ, 2009. — С. 156.

Как ты реализуешь аутентификацию, приятель? / Mail.ru Group corporate blog / Habr

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

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

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

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

Готовы? Поехали.

Аутентификация на основе сессий

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

Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.

Процедура аутентификации на основе сессий:

1. Пользователь вводит в браузере своё имя и пароль, после чего клиентское приложение отправляет на сервер запрос.
2. Сервер проверяет пользователя, аутентифицирует его, шлёт приложению уникальный пользовательский токен (сохранив его в памяти или базе данных).
3. Клиентское приложение сохраняет токены в куках и отправляет их при каждом последующем запросе.
4. Сервер получает каждый запрос, требующий аутентификации, с помощью токена аутентифицирует пользователя и возвращает запрошенные данные клиентскому приложению.
5. Когда пользователь выходит, клиентское приложение удаляет его токен, поэтому все последующие запросы от этого клиента становятся неаутентифицированными.

У этого метода несколько недостатков.

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

Аутентификация на основе токенов

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

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

Процедура аутентификации на основе токенов:

1. Пользователь вводит имя и пароль.
2. Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
3. Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
4. Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
5. Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
6. Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

Более подробное описание.

У метода есть ряд преимуществ:

• Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
• В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
• При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
  Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
  А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
• У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.

Беспарольная аутентификация

Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»

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

Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:

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

Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.

И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.

Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.

Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.

Что может пойти не так?

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

В чём преимущества?

Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.

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

Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.

Сегодня беспарольная аутентификация быстро набирает популярность.

Единая точка входа (Single Sign On, SSO)

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

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

1. Пользователь входит в один из сервисов Google.
2. Пользователь получает сгенерированную в Google Accounts куку.
3. Пользователь идёт в другой продукт Google.
4. Пользователь снова перенаправляется в Google Accounts.
5. Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

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

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

Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

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

Лучшее из двух миров

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

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth3 (некоторые используют OAuth2, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.

Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.

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

При двухфакторной аутентификации пользователь должен предоставить два из трёх:

• То, что вы знаете: пароль или PIN.
• То, что у вас есть: физическое устройство (смартфон) или приложение, генерирующее одноразовые пароли.
• Часть вас: биологически уникальное свойство вроде ваших отпечатков пальцев, голоса или снимка сетчатки.

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

То есть это универсальное решение? Возможно, нет.

И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.

Аутентификация или авторизация?

Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.

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

Ещё тут?

Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.

Однофакторная двухфакторная аутентификация / Habr

Вы являетесь клиентом банка использующего двухфакторную аутентификацию по СМС в интернет-банкинге? У вас телефон на Android? Вы используете один и тот же компьютер для доступа к сервисам Google и для доступа к интернет-банкингу?

Если все три ответа «Да» то доступ к вашим средствам защищен меньше, чем это кажется на первый взгляд.

Схема аутентификации

Сразу оговоримся о схеме доступа к банкингу. В статье рассматривается следующая защита, предлагаемая банками:

• Пара логин/пароль для доступа к сайту банкинга
• Разовый пароль (чаще всего цифровой), отправляемый по SMS на телефон клиента для подтверждения каждой операции

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

Сценарии действия злоумышленника

Для кражи средств злоумышленнику надо знать логин/пароль и иметь доступ к телефону, на который приходит СМС.
Он может этого достичь посредством:

1. Воровства пары логин/пароль (например вместе с ноутбуком) и телефона
2. Получения доступа к компьютеру и телефону через трояна
3. Используя методы фишинга (замаскировать свой сайт под сайт банкинга)

Сейчас первый и третий способ внушают наибольшие опасения. Однако не следует сбрасывать второй способ со счетов.

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

Но на самом деле заражение компьютера может привести к заражению телефона на Android. Для заражения подключение телефона к компьютеру необязательно. Рассмотрим схему атаки подробнее.

Схема атаки

Google Play предлагает удобный механизм дистанционной установки приложений на устройство. С сайта play.google.com/store можно удаленно установить любую программу на телефон, не имея физического доступа к телефону. Это существенно уменьшает уровень защиты посредством СМС-авторизации. Фактически, злоумышеннику достаточно заразить только компьютер, в то время как телефон скачает и установит зловредное приложение сам.

Сама схема выглядит так:

1. Злоумышенник публикует приложение в Google Play, содержащие код пересылки СМС сообщений на специальный email
2. Злоумышленник заражает машину пользователя трояном
3. Троян заходит на play.google.com/store и устанавливает Android приложение на все телефоны пользователя
4. Троян пересылает считанные с помощью кейлоггера логин и пароль на email злоумышленника

Все! Теперь у вора есть логин и пароль на вход в интернет банкинг а разовый пароль из СМС ему перешлет зловред установленный на телефон. При этом ему не потребуется искать какие-то уязвимости для чтения СМС-переписки пользователя (можно использовать механизм Android Permissions, которые троян с компьютера сам и подтвердит) и убеждать пользователя поставить сомнительную программу вручную (все сделает троян через сайт).

Защита

К сожалению я не нашел в приложении Google Play на телефоне запрета на установку программ через WEB-версию сервиса. Поэтому защита сводится к другим способам сделать оба фактора двухфакторной аутентификации независимыми друг от друга:

• Не использовать одну и ту же учетную запись Google на Android телефоне-получателе банковских СМС и на компьютере, через который осуществляется вход в интерент-банкинг
• Не использовать Google Play на телефоне (в некоторых кастомных прошивках его нет)
• Использовать отдельный телефон (не Android) для получения разовых паролей по СМС

Вывод

Двухфакторная аутентификация по СМС менее безопасна, чем кажется.

Двухфакторная аутентификация. Новые вызовы / Habr

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

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

• всевозможные файерволы, сейчас очень популярны WAF (Web Application Firewall),
• дублирование ключевых элементов системы,
• репликация данных; токенизация различных этапов работы системы,
• аппаратное шифрование при помощи HSM (Hardware Security Modules).

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

• ограничение доступа по IP-адресу,
• кодовые карты, платежные пароли, PINы,
• биометрия,
• проверка окружения пользователя.

И конечно же инструменты двухфакторной аутентификации, ЭЦП (Электронная цифровая подпись) и бесконтактные токены — генераторы OTP (One-Time Password).

Я всегда считал, что двухфакторная аутентификация — панацея, чуть ли не от всех возможных уязвимостей в процессе аутентификации пользователя. Следуя последним трендам безопасности, как мы думали на тот момент, своим пользователям для аутентификации в нашей платежной системе мы рекомендовали использовать аппаратные токены (TOTP, его называют “токеном по-времени”) ведущих мировых поставщиков или программный Authenticator от Google. Для подтверждения платежных операций (транзакций) использовались упомянутые выше токены, а для тех у кого их не было — мы требовали ввод одноразового пароля из SMS. Такая защита казалась нам абсолютно надежной, но если бы это было действительно так, то данной статьи не было бы…

Не буду долго ходить вокруг да около, перейду к делу. Однажды, на суппорт пришла заявка от разъяренного пользователя о том, что у него “обнулен” аккаунт, другими словами выведены все средства. После проведения первичного расследования мы увидели из истории операций, что все средства в штатном режиме за несколько транзакций были выведены на разные аккаунты самим пользователем. До этого никакой связи (операций) между пользователем и этими аккаунтами не имелось. После более детального рассмотрения и анализа всех данных, выяснилось, что этот пользователь стал жертвой “Автозалива” и “Реплэйсера”.

Немного теории, собранной на просторах Интернета:

Автозалив — инжект с административной панелью, выполняющий автоматизированные и координированные действия в аккаунте жертвы исходя из положения/ситуации в аккаунте. Эта вредоносная программа собирает данные аккаунта, смотрит какие счета есть в аккаунте и отправляет данные в административную панель. В панели расположена таблица дропов и их состояния, примечания, данные счетов куда переводить средства, и в каком объеме, чтобы обойти лимиты и не вызвать подозрение. Панель на основании автоматических правил или посредством ручной координации выбирает дропа и выдаёт инжекту. Дальше несколько альтернативных вариантов:

вариант 1) инжект отображает пользователю окно с текстом на подобии «Подождите идёт проверка данных», а сам скрытно выполняет действия, приводящие к заливу денег на дропа, путем “кликанья” на нужные ссылки внутри аккаунта и заполнения форм запрашиваемых системой. В случае, если запрашивается ТАН/OTP/PIN код и прочее для завершения перевода, автозалив выдаёт фэйк-страницу холдеру с запросом этого самого кода, но уже под своим предлогом (разводом). Холдер вводит данные в фэйк, автозалив использует эти данные для продолжения/завершения залива.

вариант 2) инжект ждет, когда пользователь захочет выполнить легальную транзакцию для которой будет запрошен ТАН/OTP/PIN код, но этим кодом будет подтверждена нелегальная транзакция — залив денег на дропа.

После чего холдер допускается в аккаунт, на котором уже срабатывает реплэйсер.

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

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

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

После некоторых поисков мы обнаружили, что подобный обход двухфакторной аутентификации уже хорошо известен, и для борьбы с этой уязвимостью многие передовые провайдеры предлагают схожие решения, они называются по разному (подпись данных, CWYS (Confirm What You See), но имеют схожую реализацию. Основной смысл заключается в том, что одноразовый пароль генерируется не только на основании секретного ключа, времени или счетчика, а с использованием всех ключевых данных транзакции, таких как сумма, валюта, получатель. В случае даже, если злоумышленник перехватит пароль, использовать для своих зловредных нужд он его не сможет. Тут все описано в деталях. Для внедрения данной фичи, мы контактировали с несколькими провайдерами, и сделали свой выбор.

Итак, пока вздохнули с облегчением… Ждем новые вызовы.