Динамический пароль что это такое: Динамический пароль 2.0 / Хабр

Содержание

Динамический пароль 2.0 / Хабр

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

Итак, далее будет:

итоги на написанную ранее статью
еще идеи на её счет
расскажу о принципиально другом «динамическом пароле 2.0», лишенном недостатков первого.
а так же, ~~скандалы, интриги, расследования~~ идею как задать пароль:
который вы сами не сможете набрать в состоянии алкогольного опьянения,
который можно набрать на глазах у друга, и состоящий из символов «QQQQQ»
и он не сможет его повторить…

Прежде всего, предлагаю не относиться слишком критично к данной статье, оставьте в восприятии толику юмора, ведь это прежде всего идеи, брошенные в море облачного IT-интеллекта

Итоги из статьи Динамический пароль

Способ реализации — не жесткая последовательность, а конструктор динамического пароля, позволяющий вставить приведенные автором шаблоны в любых местах и в любых количествах в своем шаблоне пароля
Сфера применения — не общественные системы для обычного потребителя. В первую очередь идея может быть использована в закрытых системах и организациях, которые хотят усложнить механизм обычного ввода пароля, но не задействовать доп железо (телефоны, токены, смарт-карты и тд)
Недостатки — невозможность хранить на сервере в виде хеша, придется часть шаблона пароля оставлять в открытом виде. Сложность, надо потратить немного времени что бы подготовить пароль по известному вам шаблону и, как следствие, слабая применяемость «в народе».
Преимущества — бесполезность идеи взлома пароля методом перебора (пока идет перебор паролей, сабж может стать тем, который уже был использован генератором ранее). Защита от «подглядываний» пароля (точный пароль, набранный через [1-N] минут может оказаться уже неактуальным)

Идеи и пояснения

Меня, как и некоторых других Хабра-юзеров, посещала идея динамического пароля еще несколько лет назад.
Тогда, я сформулировал её для себя следующим образом:
Есть шаблоны: MM, YY, DD и т.д. перечисляем сюда все шаблоны из форматера дат и указанные автором в парент-топике и еще кучу на свой вкус.

Что бы задать пароль надо совместить статический текст пароля, с динамическим, что бы это сделать, выбираем обрамляющие символы которые будут указывать где начинается и оканчивается шаблон. Например можно использовать двойные квадратные скобки «[[….]]», по принципу наклонной черты в java «\\».
Несколько примеров шаблонов пароля сформированные таким образом:

«qqq[[MM]]qqq» (верный пароль «qqq+2х-значная минута+qqq»)
«[[YYYY]] тысяч обезьян в [[USER]] сунули банан» ( 🙂 )
«2+2=[[M]]» (верный пароль — «2+2=первая цифра текущей минуты»)

«[[SS]][[SS]][[M]][[SS]][[SS]]» (пароль, завязанный на секунды, потребует предварительной его подготовки к определенной секунде и минуте в будущем)

Можно даже предусмотреть вычисление внутри «[[…]]», например:

k1s$a[[MM]][[MM+1]][[MM+9]][[MM+7]][[MM+9]] (пароль, это «k1s$a»+ повторяющиеся 4 раза цифры текущей минуты, к которым прибавляем цифры вашего года рождения)
[[HH%2==0]] (пароль true или false, в зависимости четная минута или нет)
[[MM+-2]] (пароль, это текущая минута с погрешностью +- 2 минуты)
[[MM+-2]][[MM+-2]][[ MM+-2]][[MM+-2]][[MM+-2]] (развитие предыдущего пункта — пароль (например 1920222120) может состоять из разных цифр в пределах погрешности и никто не догадается что базовая цифра, это текущая минута — 20 в моем случае )

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

Динамический пароль 2.0

Вот и подошла очередь описать принципиально новый «Динамический пароль 2.0». Включаем юмор, и оставляем включенной логику

Представьте ситуацию:
Вы видите как ваш друг набирает в поле пароля банальный пароль «QQQQQ» или «11111» и входит, вы говорите ему, что он полный чайник, раз использует подобный пароль, а он в ответ, выходит из программы и предлагает ввести его вам. Вы пытаетесь ввести пароль 5 раз и вас не пускает, после этого вы вспоминаете что когда-то читали статью на хабре Динамический пароль и предполагаете что пароль просто перегенерился и, скорее всего, тогда на часах была или 11-я минута или что то еще… Но ваш приятель садится за комп и опять у вас на глазах начинает вводить «11111» и его пускает!
В чем секрет?
В фразе «Динамический пароль 2.0» основным словом является « динамический«, но не в смысле «изменяемый», а в смысле «динамичный, танцевальный» 😉
Помните реакцию винды на неправильный ввод пароля 3 раза подряд? Она не дает ничего вводить пару минут, что бы исключить подбор пароля, а потом, через пару минут снова дает 3 попытки.
Что, если контролировать время между введенными символами и использовать его как еще один параметр при входе в систему?
Не буду разжевывать то, что вы и так поняли, и сразу приведу шаблон пароля нашего «продвинутого» приятеля:
Q[[T>500]]Q[[T>500]]Q[[T>500]]Q[[T>1000]]Q
Где [[T>500]], говорит о том что между символами должно быть время в миллисекундах большее чем пол секунды, а между предпоследним и последним символами — больше секунды.
Включаем фантазию и думаем какие еще правила можно придумать: минимальное/максимальное время ввода всего пароля, больше, меньше, погрешность в миллисекундах, динамическое время основанное на первом промежутке времени между вводом первого и второго символа пароля, и много чего еще…

Сразу о преимуществах:

легкий набор
возможность хранить хеш самого пароля на сервере
возможность, при отменной реакции и чувстве такта, задать простейшую мелодию при «настукивании» пароля
невозможность подбора, так как время это тоже параметр
wow! вы можете рассчитать минимальное время набора пароля (скажем вы легко набираете его за 1.5 секунды), а в случае вашего
~~измененного сознания~~ опьянения, не сможете набрать его с такой же скоростью, так как время реакции сильно пострадало и база защищена вами от вас! ))

Теперь о недостатках:

Сложное программирование, придется точно контролировать время между вводимыми символами, для реализации надо хорошенько подумать что сделать на клиенте, а что на сервере
возможно, сложное придумывание шаблона (если шаблон сложнее чем набрать 3 символа, подождать 3 секунды, набрать остальные символы пароля)
дополнительное нешифруемое поле в базе в нагрузку к Хешу пароля, для того что бы знать правила контроля времени между символами или общего времени набора

Не забываем, всё это концепты, идеи для размышления, не надо сразу прикладывать идею к сайту «Одноклассники» и его ~~хомячков~~ обитателей 😉

В общем, интересных проектов и удачи Всем!

Update1: Коментарии в статье Третье измерение защиты паролей окончательно меня убедили, что пользователи Хабра мыслят одинаково. До написания своей статьи, я не читал «Третье измерение защиты паролей» и его каментов.

Динамический пароль / Хабр

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

Сам я не программирую на таком уровне и не связан с сайтами, которые осуществляют доступ к аккаунтам пользователей, то есть — не смогу реализовать и проверить идею, поэтому решил поделиться мыслью со знающим человеком.

Кому это нужнее? Наверное Гуглю, подумал я… С трудом нашел адрес одного сотрудника, написал письмо.

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

Я. Это совсем не то! Там предложен метод двухэтапной аутентификации. Для нее нужен телефон (не очень хорошая и надежная привязка), на который шлется код второго этапа аутентификации. Причем код можно поменять лишь один раз в 30 дней…
С.… (молчок).
Я. Напоминаю.
С. Идея плохая, не тратьте время, я ее никому пересылать не буду.

Если идея плохая, значит так оно и есть, забросил этот процесс.

Сегодня читаю Хабр. Уже как зарегистрированный пользователь.
Обращаю внимание на статью «Сезам, откройся!» — вход в аккаунт Google при помощи QR кода.

Думаю, вот ведь люди, думают как защитить своих пользователей! И вспоминаю свою идею. Может все же кому-то понадобится?

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

Может все же кто-то реализует эту задумку? Как мне кажется, ничего особо сложного тут нет. Обсудите, только я сильно не смогу помочь — не моя стезя.

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

Предлагаю сделать автоматически изменяющийся (динамический) пароль.
При этом в пароле может присутствовать как классическая — неизменяемая часть, так и динамически изменяемая.

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

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

Если уж совсем примитивно, то можно привести такой пример:
Вариант пароля (лучше всего — часть пароля) — текущее время с точностью плюс-минус пару минут.

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

Простейшие примеры привязки динамической части к различным параметрам:
— Текущий час в одном из часовых поясов.
— Текущая четверть часа — 1, 2, 3, 4.
— Текущий десяток минут — 0, 1, 2, 3, 4, 5.
— Текущая минута — 0 … 59.
— Порядковый номер дня в году (сколько дней осталось до Нового года) — 0 … 365.
— Текущий месяц (порядковый номер) — 1, 2, 3, …, 12.
— Текущий месяц (первая буква названия) — J, F, M, …, D.
— Буквы имени или фамилии президента страны — A … Z.
— Время года — зима, весна, лето, осень — win, spr, sum, aut.
— Последний курс выбранной валюты — ?
— Количество лет со дня рождения любого выбранного человека — 0 … 2011.
— Сколько лет осталось до определенного события — 0 …?
— Температура воздуха в определенном городе по прогнозу выбранного сайта.
— Перевод числа в двоичный или другой код.

Пример пароля. 415Med125
4 — количество десятков минут.
15 — текущий час в одном из часовых поясов.
Med — текущий президент.
125 — порядковый день в году.

Для запоминания можно придумывать мнемонические правила.
Для конкретного примера — “Время президента — день”.

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

Результаты.

1. Мнения разделились. В обсуждении кто-то считает идею так себе, кто-то нашел рациональное зерно.

2. Aquahawk 17 января 2012, 21:26 и чуть ниже привел примеры 1, 2 и 3, где применен подобный принцип.
Получается, что идея с динамической частью рабочая. Динамическая часть будет работать примерно как Токен RSA SecurID в приведенных ссылках.

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

3. MazeFAQa 17 января 2012, 22:10 написал правильную мысль, которую я не смог донести сразу. Пароль, статическая и динамическая часть являются конструктором, который пользователь собирает самостоятельно. Ставит что хочет и где хочет.

4. Похоже, что эта идея так себе и прав был С из диалога…
Спасибо всем, принявшим участие в обсуждении!

5. Оказывается, этот алгоритм уже реализовали.

6. Появилось дальнейшее развитие идеи Динамический пароль 2.0 автора djvu

P.S. 2014.
Идею реализовали для разблокировки экрана смартфона. TimePIN: украденный пароль локскрина не поможет уже через минуту.

Динамический код на банковской карте или технология 3-D Secure?

На различных тематических информационных ресурсах, посвящённых электронной коммерции и платежным картам, производители и обозреватели рассказывают об инновациях, призванных делать наши покупки в интернете еще безопаснее. В последнее время в интернете появилось множество статей о последней новинке компании Gemalto – пластиковой карте с автоматически изменяющимся кодом проверки подлинности — Dynamic Code Verification или сокращенно DCV. Особо подчеркивается высокий уровень защиты владельцев карт от мошеннических онлайн-платежей.

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

Традиционный СVV/CVC – трехзначный код на банковской карте

Любому владельцу банковской платежной карты, который хоть раз оплачивал что-либо через интернет, хорошо известно, что для совершения платежа наряду со всеми реквизитами карты нужно ввести и трехзначный код, напечатанный на ее обратной стороне. В русскоязычном сегменте интернета эти три цифры обычно так и называют «трехзначный код». В англоязычном мире он известен как CVV (Card Verification Value) или CVC (Card Verification Code).

Изначально CVV/CVC был призван защитить электронную коммерцию от платежей, с использованием похищенных реквизитов банковских платёжных карт. В недавнем прошлом, как минимум лет 20 назад, основным источником хищения карточных реквизитов для интернет-мошенников являлся мир «оффлайна». Номер карты, имя владельца и срок ее действия можно было или подсмотреть и запомнить, когда владелец расплачивался в торговой точке, или скопировать со слип-чеков. А поскольку CVV/CVC просто печатался на обратной стороне карты, увидеть его и похитить было значительно сложнее, чем остальные карточные реквизиты.

Слип-чек – это чек, на который переносились карточные данные, эмбоссированные (или, проще говоря, выдавленные) на карте, путем ее прокатки в слип-машинке. Был такой способ приема карточных платежей, когда электронные каналы связи не были так хорошо развиты как сейчас, и торговые предприятия были оборудованы не электронными POS-терминалами, а такими вот механическими устройствами.

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

Эволюция CVV/CVC — динамический трехзначный код

Динамический код, DCV – это эволюционное развитие устаревших CVV/CVC. В отличие от них, на протяжении всего действия срока карты DCV регулярно меняется через равные промежутки времени (по умолчанию каждые 20 минут) по определенному алгоритму, известному только банку-эмитенту. Для отображения DCV в платежную карту встроен миниатюрный дисплей.

По замыслу разработчика технологии, DCV делает невозможным использование похищенных карточных реквизитов. Даже если мошенникам удалось получить полный набор данных, как максимум, через 20 минут код изменится, и попытка интернет-платежа с использованием устаревшего трехзначного кода будет отклонена банком-эмитентом.

Динамический верификационный код или 3-D Secure? Вопросы безопасности, удобства, стоимости.

Идея DCV понятна, логична и, действительно, обеспечивает более высокую защиту интернет-платежей по сравнению с использованием статичных CVV/CVC.

Но не опоздала ли технология DCV с выходом на рынок? Сможет ли она составить конкуренцию уже устоявшемуся и общепринятому стандарту в платежной индустрии — верификации владельца карты при совершении интернет-платежа c 3-D Secure? И, наконец, насколько карты с DCV могут быть удобны для эмитентов и конечных пользователей?

Вероятно, DCV могла бы стать революционно прорывной технологией обеспечения безопасности интернет-платежей, если бы в этой области уже не существовало 3-D Secure. Дело в том, что при всей своей инновационности и технологичности DCV все же уступает 3-D Secure в уровне обеспечения безопасности платежей.

Да, DCV меняется каждые 20 минут. Но при использовании современных реализаций 3-D Secure, код подтверждения платежа генерируется и сообщается владельцу карты непосредственно в процессе обработки транзакции (платежа). И поэтому, если в случае с DCV у злоумышленника теоретически есть, пусть и очень небольшой, но шанс использовать похищенные карточные данные до очередной смены DCV, то в случае 3-D Secure у мошенника такого шанса в принципе нет.

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

В случае, если интернет-платежи защищены 3-D Secure, преступник не сможет воспользоваться украденной картой. Но, даже если каким-то образом и сможет (например, интернет-торговец отключил опцию проверки по 3-D Secure для всех своих покупателей), правила платежных систем будут на стороне владельца карты и банка–эмитента. Если транзакция по карте, защищенной 3-D Secure, прошла без проверки плательщика (т.е. у владельца карты в процессе покупки не был запрошен код), то ответственность за такую транзакцию лежит на продавце и банке-эквайере, и в случае мошенничества деньги будут возвращены покупателю.

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

И также очевидно, что стоимость изготовления карты с DCV должна быть выше, чем карты с обычными CVV/CVC.

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

А вот в тех платежных системах, где 3-D Secure по каким-то причинам до сих пор не внедрена (например, БЕЛКАРТ или российской «Мир»), DCV может стать неплохой альтернативой.

Время покажет. К слову интернет-магазины, принимающие платежи по банковским картам через процессинговую платформу bePaid, надежно защищены от мошенничества технологией 3-D Secure и другими инновационными инструментами безопасности.

С уважением,

Команда bePaid

что это значит, как подключить

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

Что это значит?

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

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

Как подключить адрес динамической аутентификации

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

Для старой карты

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

Для новой карты

Подключить динамическую аутентификацию для новых карт можно несколькими способами:

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

Самостоятельно подключить данную функцию можно следующим образом:

Авторизоваться в личном кабинете.
Открыть настройки и найти пункт «Уведомления и безопасность».
Выбрать пункт «Включение динамической аутентификации».

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

Банк Санкт-Петербург: номер горячей линии 8 (800) 500-59-39 (вызов бесплатный), [email protected];
Минбанк (Московский Индустриальный Банк): 7474 (с мобильного – оплата не взымается), номер горячей линии 8 (495) 74-000-74;
Курскпромбанк: телефон горячей линии 8 (4712) 703-703 (звонок сопровождается инструкциями робота).

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

Итак, код подтверждения необходим для осуществления расходной операции с использованием карточных реквизитов. Пользователи могут столкнуться с уведомлением «У вас нет адреса динамической аутентификации» только в тех случаях, если на сайтах активирована система 3D Secure. Для проведения оплаты на ресурсах с такой системой владельцу банковской карты необходимо подключить СМС-информирование. Посредством оповещений держатель пластика будет получать на свой мобильный телефон коды для подтверждения оплаты.

Обзор способов и протоколов аутентификации в веб-приложениях

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

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

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

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

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

Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.

Пример HTTP аутентификации с использованием Basic схемы.
Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.

Другие протоколы аутентификации по паролю

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

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.

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

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

Веб-приложение позволяет пользователям создавать простые пароли.
Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.
Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.

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

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

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

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
Сертификат должен быть действительным на текущую дату (проверка срока действия).
Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

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

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

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

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

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

Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

Токен был выдан доверенным identity provider приложением (проверка поля issuer).
Токен предназначается текущему SP-приложению (проверка поля audience).
Срок действия токена еще не истек (проверка поля expiration date).
Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.
Пример SWT токена (после декодирования).
Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
{ «alg»: «HS256», «typ»: «JWT» }.
{ «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Assertions — собственный формат SAML токенов в XML формате.
Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

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

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

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

Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

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

Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ	Основное применение	Протоколы
По паролю	Аутентификация пользователей	HTTP, Forms
По сертификатам	Аутентификация пользователей в безопасных приложениях; аутентификация сервисов	SSL/TLS
По одноразовым паролям	Дополнительная аутентификация пользователей (для достижения two-factor authentication)	Forms
По ключам доступа	Аутентификация сервисов и приложений	—
По токенам	Делегированная аутентификация пользователей; делегированная авторизация приложений	SAML, WS-Federation, OAuth, OpenID Connect

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

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

динамический пароль — это… Что такое динамический пароль?

динамический пароль: Security: dynamic password

динамический параметр цели
динамический пассив

Смотреть что такое «динамический пароль» в других словарях:

Регистрация пользователя сайта — Регистрация пользователя сайта процедура, в результате которой пользователь становится пользователем конкретного сайта с определёнными правами доступа к определённому ограниченному объёму функций сайта. Процедура регистрации на сайте в… … Википедия
Фидонет — Запрос «Фидо» перенаправляется сюда; см. также другие значения. Фидонет (от англ. FidoNet, /ˈfaɪdəʊnɛt/; коротко Фидо) международная любительская компьютерная сеть, построенная по технологии «из точки в точку».[1] Изначально программное… … Википедия
Редактор сообщений Фидонет — Запрос «Фидо» перенаправляется сюда. Cм. также другие значения. Фидонет (коротко Фидо; от англ. Fidonet, /ˈfaɪdəʊnɛt/) международная некоммерческая компьютерная сеть, построенная по технологиям «из точки в точку» и «коммутация с запоминанием»[1] … Википедия
ФИДО — Запрос «Фидо» перенаправляется сюда. Cм. также другие значения. Фидонет (коротко Фидо; от англ. Fidonet, /ˈfaɪdəʊnɛt/) международная некоммерческая компьютерная сеть, построенная по технологиям «из точки в точку» и «коммутация с запоминанием»[1] … Википедия
Фидошник — Запрос «Фидо» перенаправляется сюда. Cм. также другие значения. Фидонет (коротко Фидо; от англ. Fidonet, /ˈfaɪdəʊnɛt/) международная некоммерческая компьютерная сеть, построенная по технологиям «из точки в точку» и «коммутация с запоминанием»[1] … Википедия
Фидо — Запрос «Фидо» перенаправляется сюда. Cм. также другие значения. Фидонет (коротко Фидо; от англ. Fidonet, /ˈfaɪdəʊnɛt/) международная некоммерческая компьютерная сеть, построенная по технологиям «из точки в точку» и «коммутация с запоминанием»[1] … Википедия
Фидонетчик — Запрос «Фидо» перенаправляется сюда. Cм. также другие значения. Фидонет (коротко Фидо; от англ. Fidonet, /ˈfaɪdəʊnɛt/) международная некоммерческая компьютерная сеть, построенная по технологиям «из точки в точку» и «коммутация с запоминанием»[1] … Википедия
Переполнение буфера — У этого термина существуют и другие значения, см. Переполнение. Переполнение буфера (Buffer Overflow) явление, возникающее, когда компьютерная программа записывает данные за пределами выделенного в памяти буфера. Переполнение буфера обычно… … Википедия
ГОСТ Р 52633.0-2006: Защита информации. Техника защиты информации. Требования к средствам высоконадежной биометрической аутентификации — Терминология ГОСТ Р 52633.0 2006: Защита информации. Техника защиты информации. Требования к средствам высоконадежной биометрической аутентификации оригинал документа: 3.1 автоматическое обучение: Обучение, осуществляемое автоматически без… … Словарь-справочник терминов нормативно-технической документации
СИМВОЛ — (от греч. symbolon знак, опознавательная примета) идея, образ или объект, имеющий собственное содержание и одновременно представляющий в обобщенной, неразвернутой форме некоторое иное содержание. С. стоит между (чистым) знаком, у которого… … Философская энциклопедия
JavaScript — Не следует путать с Java. JavaScript Класс языка: мультипарадигменный … Википедия

А давайте заставим пользователя использовать безопасный пароль

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

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

Если у вас есть пользователи и они авторизуются по паролю, я предлагаю еще раз посмотреть на свежие рекомендации от таких организаций как National Institute of Standards and Technologies и National Cyber Security Centre.

В частности, требовать ротации паролей уже не модно. И требовать определенных символов в лучших традициях анекдота про «1ГРЕБАНАЯрозоваяроза» тоже. Давайте пробежимся по основным тезисам и попробуем сделать пользователям удобнее и безопаснее.

Аутентификация не бинарна

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

Идеально доверенный пользователь сумел верно ввести пароль и заходит с авторизованного устройства. Чуть меньше доверия пользователю, который зашел с доверенного устройства, но ошибся при вводе пароля. И совсем плохо, если пользователь верно ввел пароль, но устройство недоверенное, второй фактор не подтвержден и IP принадлежит выходной ноде Тора. Вот в третьем случае пора дергать рубильник с надписью «Аларма! Волк украл зайчат!».

Наша задача, как людей предоставляющих сервис, сделать людям удобно, безопасно и не очень больно, если они ошибаются. Поэтому стоит расставить определенные признаки аномальной активности по порядку, чтобы включать те или иные дополнительные меры защиты аккаунта. Например, после 3-5 неверного ввода пароля предложить пользователю пройти CAPTCHA. Да, ее все ненавидят, но большинство пользователей с ней не столкнется. А те, кто понизил свой рейтинг доверия просто немного замедлятся перед очередным вводом пароля. Зато мы отсечем автоматические атаки на перебор пароля.

Не надо ограничивать максимальную длину пароля

Длинные пароли безопаснее. Дайте пользователям их использовать.

Ну не то, чтобы совсем не надо. Жирные пароли длиной в несколько мегабайт могут потенциально аукнуться переполнением в неожиданном месте или другими странными эффектами. Но условная максимальная длина в 300 символов гарантированно устроит любого типичного пользователя. Более того, этих же рекомендаций придерживается NIST:

Аутентифицирующая сторона должна разрешать пользователю использование запоминаемых паролей длиной не менее 64 символов.

А еще для особо одаренных сервисов NIST также дает еще одну важную рекомендацию:

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

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

Убедитесь, что любые ASCII символы допустимы

Есть определенные проблемы со спецсимволами. Например, использование «{}/\» или других подобных символов может быть потенциально недопустимым в некоторых ситуациях. Скажем, фигурные скобки могут ломать валидный JSON и вызывать падение обработки пароля. Или символ апострофа, который может использоваться в SQL-инъекциях. Да, форма ввода пароля тоже может быть входными воротами для атаки.

В теории вы могли бы просто запретить использование подобных символов, чтобы сделать себе проще. Но тем самым вы снизите энтропию пароля пользователя и сделаете ему неудобно, если пароль генерируется автоматически. Придется подбирать определенные паттерны для исключений. Опять же обратимся к ~~Марксу~~ NIST:

Все печатаемые символы ASCII [RFC 20], включая пробел, должны быть допустимыми для ввода в качестве пароля. Символы Unicode [ISO/ISC 10646] также должны быть допустимыми.

Да. Все верно. Это ваша головная боль и дополнительное тестирование. Но если пользователь хочет использовать ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ или මෙයද ඉතා දුෂ්කර මුරපදයකි — дайте ему это сделать. Или добавить символ буррито в пароль для криптостойкости. Имеет право.

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

Большинство людей использует однотипные паттерны, например, заглавная буква в качестве первого символа, спецсимволы и цифры на последних двух позициях. Киберпреступники знают об этом и настраивают свои атаки с перебором по словарю с учетом типичных замен, таких как «s» на «$», «a» на «@» и «i» на «l».

Да-да, тот самый Microsoft из-за которого миллионы людей каждый месяц придумывают новый пароль, не совпадающий с предыдущими, содержащие спецсимволы и буквы в разном регистре. Именно они в своих гайдлайнах теперь пишут «Eliminate character-composition requirements».

Ведь в итоге, типичные утилиты вроде cain and abel, hashcat, john the ripper могут подобрать пароль в течение нескольких часов или даже минут на типичной видеокарте, если использовалось стандартное словарное слово и типичный паттерн замены.

Не используйте подсказки для паролей

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

В 2013 году у Adobe утекла база с паролями. Зашифрована она была криво, но самое неприятное, что она содержала подсказки для восстановления, над чем и не преминул поиздеваться Рэндал Монро в xkcd.
Того же мнения придерживается NIST, не рекомендующий хранение подсказок в любом виде. Забыл — восстанавливай через почту со всеми дополнительными проверками.

Снизьте нагрузку на мозг пользователя

National Cyber Security Centre выпустил крутую инфографику. Позволю себе процитировать небольшой фрагмент:

Обратите внимание, что основная проблема с паролями связана с тем, что хороший пароль случаен и его почти нереально запомнить. Если сервисов много, то пользователь почти неизбежно будет использовать один и тот же пароль везде, где можно. Особо продвинутые сделают что-то вроде «myp@ssword_habr.com». Естественно, что компрометация пароля в одном месте автоматически ставит под удар аккаунты во всех остальных сервисах.
Поэтому, дайте пользователю использовать менеджеры паролей. Да, это как специальный кошелек для банковских карт, который позволяет потерять их одновременно. Но тут надо понимать, что компрометация оффлайн хранилища паролей — довольно редкая ситуация, в отличие от компрометации одинаковых паролей на разных ресурсах. Менеджеру паролей не нужно быть идеальным. Ему нужно быть лучше, чем однотипные пароли везде. Не будьте как некоторые нехорошие сервисы, которые блокируют возможность вставки пароля в поле из буфера обмена. Это явно заставляет пользователя отказаться от менеджера паролей и использовать слабый вариант.

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

Выводы

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

динамических паролей — будущее аутентификации |

В нашем последнем посте мы много говорили о статическом пароле и некоторых преимуществах отказа от них в пользу гибкого, динамического пароля. Конечно, мы также обсудили особую авторитетную фигуру в мире технологий, которая смело заявил, что пароли «просто не справляются с задачей, которую вы действительно хотите защитить». Человек, который это пошутил? Его зовут Билл Гейтс, и он не ошибается. Но опять же, мы здесь, годы спустя, и пароль по-прежнему является краеугольным камнем аутентификации для многих веб-сайтов, приложений и т. Д.Таким образом, если пароль как концепция будет упорно не оставить в свалку компьютерной истории, мы, вероятно, следует говорить о том, как мы можем сделать пароль немного лучше с преимуществами динамического пароля.

Уход от статического пароля: часть II — динамический пароль

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

Что такое динамический пароль?

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

Теперь вы можете подумать: : «Это огромное неудобство. Постоянно меняющийся пароль? Означает ли это, что мне нужно менять пароль каждый день? Это просто неудобно! Я имею в виду, кто мог угадать мой пароль $$$ !!! garybusey? » (здесь Busey Pic)

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

Пора скептикам и любителям статических паролей взглянуть правде в глаза — статические пароли исчезнут. Будь то легкое и тихое скольжение в учебники истории или нам придется тащить его, пиная и крича, за дверь, статический пароль исчезнет.Альянс FIDO (в состав которого входят такие технологические тяжеловесы, как Microsoft, Google и другие) опубликовал отчет о системе, позволяющей навсегда устранить статический пароль. Признаюсь, я вижу некоторую привлекательность для статического пароля — установите пароль один раз и забудьте о нем, — но мы живем в эпоху, когда слишком многое защищено простой строкой, состоящей из никогда не меняющихся символов. Мы должны начать использовать динамический пароль и вместе с ним попрощаться со сбросом, изменением пароля и хакерскими атаками.

Следите за нами и ставьте лайки:

Категории: Без категории | Теги: Управление доступом, безопасность данных, надежность пароля, статический пароль, усиленная аутентификация | Постоянная ссылка

динамический пароль — это … Что такое динамический пароль?

Dynamic SSL — это технология безопасности конечных точек, разработанная Дэниелом Макканном и Нимой Шарифимер из NetSecure Technologies Ltd. Динамический SSL был создан для решения проблемы безопасности конечных точек в общедоступных сетях путем прозрачного исправления реализации…… Wikipedia

Dynamic Microprocessor Associates — Типовая дочерняя компания Symantec, основанная в США, головной офис, США, Dynamic Microprocessor Associates, компания-разработчик программного обеспечения из США.Хотя DMA наиболее известна своим продуктом для удаленного администрирования pcAnywhere, она также разработала и… Wikipedia

Пароль — Чтобы узнать о других значениях, см. Пароль (значения). Пароль — это секретное слово или строка символов, которая используется для аутентификации, чтобы подтвердить личность или получить доступ к ресурсу (пример: код доступа — это тип пароля). Пароль…… Википедия

Password-Sniffer — Dieser Artikel oder Abschnitt bedarf einer Überarbeitung.Näheres ist auf der Diskussionsseite angegeben. Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung. Ein Sniffer (англ. «Нюхать» für riechen, schnüffeln) ist eine…… Deutsch Wikipedia

Токен безопасности — Несколько типов токенов безопасности с ценой в пенни… Wikipedia

Система PassPattern — (PPS) — это система аутентификации пользователя с псевдодинамическим паролем, основанная на шаблонах. В отличие от других систем на основе динамических паролей, PassPattern System (PPS) [[http: // netlab.cs.iitm.ernet.in/pps Система PassPattern, NETLAB, Индийский институт…… Википедия

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

Википедия: Справочная служба / Вычислительная техника — Справочная служба Википедии, охватывающая тему вычислений.Вычисления #eee # f5f5f5 #eee #aaa #aaa #aaa # 00f # 36b # 000 # 00f вычисления Википедия: Справочник по… Википедия

OpenLDAP — разработчики программного обеспечения Стабильная версия проекта OpenLDAP 2.4.26 / 30 июня 2011 г .; 4 месяца назад (2011 06 30)… Википедия

Abkürzungen / Computer — Dies ist eine Liste technischer Abkürzungen, die im IT Bereich verwendet werden. A [nach oben] AA Antialiasing AAA аутентификация, авторизация и учет, siehe Triple A System AAC Advanced Audio Coding AACS… Deutsch Wikipedia

Liste der Abkürzungen (Компьютер) — Dies ist eine Liste technischer Abkürzungen, die im IT Bereich verwendet werden.A [nach oben] AA Antialiasing AAA аутентификация, авторизация и учет, siehe Triple A System AAC Advanced Audio Coding AACS… Deutsch Wikipedia

динамический пароль — это … Что такое динамический пароль?

Токен безопасности — Несколько типов токенов безопасности с ценой в пенни… Wikipedia

Введение в динамический контроль доступа — статьи TechNet — США (английский)

Dynamic Access Control представляет собой несколько улучшений функций, представленных в Windows Server 2012 Server, которые работают вместе для улучшения управления авторизацией в Windows Server 2012. файловые серверы.

Поддержка Kerberos для утверждений пользователей и информации об авторизации устройства
Поддержка условных выражений в записях разрешений и аудита
Классификация файлов и политики централизованного доступа обеспечивают решение для сквозного управления авторизацией.
Включить поддержку условных выражений в аудит доступа к глобальным объектам.
Службы автоматического управления правами (RMS) для шифрования конфиденциальных документов Office (не включены в этот документ).
В доступе отказано в помощи для облегчения бремени устранения проблем с общим доступом (не включено в этот документ).

Что такое динамический контроль доступа?

В Windows Server 2012 вы сможете применять управление данными на файловых серверах, чтобы контролировать, кто имеет доступ к информации, и контролировать, кто имел доступ к информации.Динамический доступ Управление обеспечивает:

Идентификация данных — Автоматическая и ручная классификация файлов может применяться к данным тегов на файловых серверах по всей организации
Контроль доступа к файлам — Политики централизованного доступа позволяют организациям применять политики сети безопасности. Например, вы можете определить, кто имеет доступ к медицинской информации в организации.
Аудит доступа к файлам — Политики центрального аудита для составления отчетов о соответствии и криминалистического анализа.Например, вы можете определить, кто получил доступ к конфиденциальной информации.
Применение защиты RMS — Служба автоматического управления правами (RMS) для шифрования конфиденциальных документов Office. Например, вы можете настроить RMS для шифрования всех документов, содержащих информацию HIPAA.

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

Новый механизм авторизации и аудита Windows, который может обрабатывать условные выражения и централизованные политики.
Поддержка проверки подлинности Kerberos для заявлений пользователей и устройств.
Улучшения инфраструктуры классификации файлов.
Поддержка расширяемости RMS, чтобы партнеры могли предоставлять решения для шифрования файлов, не относящихся к Office.

Условные выражения для записей разрешений

Windows Server 2008 R2 и Windows 7 улучшили дескрипторы безопасности Windows, введя запись разрешения условного доступа.Windows Server 2012 использует условный доступ записи разрешений путем вставки утверждений пользователей, утверждений устройств и свойств ресурсов в условные выражения. Безопасность Windows Server 2012 оценивает эти выражения и разрешает или запрещает доступ на основе результатов оценки. Обеспечение доступа к ресурсы через утверждения известны как управление доступом на основе утверждений. Управление доступом на основе утверждений работает с традиционным контролем доступа, чтобы обеспечить дополнительный уровень авторизации, который может быть гибким в соответствии с различными потребностями корпоративной среды.

Инфраструктура классификации файлов

Windows Server 2008 R2 представила инфраструктуру классификации файлов (FCI). FCI предоставляет:

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

В Windows Server 2012 инфраструктура классификации файлов учитывает утверждения. Это усовершенствование позволяет FCI представлять свойства ресурса как свойства классификации. Администраторы могут выбирать классификации вручную с помощью проводника Windows. В качестве альтернативы они могут использовать диспетчер ресурсов файлового сервера (FSRM) для непрерывной классификации. Свойства ресурса позволяют управлять доступом на основе утверждений для оценки того, как утверждения о пользователе относятся к претензиям по поводу ресурса.Windows выполняет эту оценку с помощью записей управления условным доступом, которые являются дополнительным уровнем традиционной авторизации. FCI в Windows Server 2012 также поддерживает:

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

Политики центрального доступа

Политика централизованного доступа

— это новая функция Windows Server 2012.Политики централизованного доступа позволяют администраторам создавать политики доступа, которые применяются к файловым серверам Windows Server 2012, используя Групповая политика. Каждый объект политики централизованного доступа может содержать одно или несколько правил централизованного доступа. Администраторы могут настраивать применимость и разрешения в каждом правиле политики центрального доступа. Windows хранит политики и правила центрального доступа централизованно в Windows Server Active Directory. Это обеспечивает централизованный подход к управлению авторизацией на файловых серверах Windows Server 2012.

Назначение / Преимущества

Dynamic Access Control фокусируется на четырех основных сквозных сценариях:

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

Технический Обзор

Dynamic Access Control — это не отдельная функция, а решение файлового сервера, созданное с использованием инфраструктуры Windows Server 2012 для обеспечения универсальной и гибкой сквозной авторизации. сценарий.Усовершенствования Windows Server 2012, составляющие динамический контроль доступа, включают

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

Предварительные требования

Требуется авторизация и аудит на основе претензий:

• Windows Server 2012

• По крайней мере, один контроллер домена Windows Server 2012 доступен клиенту Windows в домене пользователя.

• По крайней мере, один контроллер домена Windows Server 2012 в каждом домене при использовании утверждений в доверии леса

Клиент Windows 8 (требуется при использовании заявок на устройство)

Технологии основания

Dynamic Access Control опирается на множество технологий.Динамический контроль доступа сочетает в себе множество различных технологий Windows Server 2012 для обеспечения надежной, гибкой и детальной авторизации. и опыт аудита. Некоторые из основных технологий, используемых динамическим контролем доступа, включают:

Сетевые протоколы (включая TCP / IP, RPC, SMB, LDAP)
Разрешение имен (DNS)
Active Directory и зависимые от него технологии
Реализация Microsoft Kerberos v5, включая защиту Kerberos (FAST) и сложную аутентификацию
Безопасность Windows (LSA, Netlogon)

Функциональное описание

Dynamic Access Control обеспечивает гибкий способ применения и управления доступом и аудитом к файловым серверам на основе домена.Динамический контроль доступа обеспечивает гибкость за счет использования требований в токене проверки подлинности, свойствах ресурса для ресурса и условных выражениях в записях разрешений и аудита. Благодаря этой комбинации функций теперь вы можете предоставлять доступ к файлам и папкам на основе атрибутов Active Directory. За Например, пользователю Алисе предоставляется доступ к общему ресурсу файлового сервера, потому что атрибут отдела в ее пользовательском объекте в Active Directory содержит значение Учет.

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

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

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

Разверните Windows Server 2012 и, при необходимости, клиенты Windows 8, если вам нужно использовать утверждения устройства.
Включите клиентов Kerberos Windows 8 для поддержки утверждений и контроллеры домена Windows Server 2012 для поддержки утверждений.
Создайте и активируйте типы утверждений пользователей и устройств, используйте существующие группы безопасности или используйте их комбинацию.
Предоставляет данные об атрибутах пользователей и компьютеров, используемых для типов утверждений источников. Укажите идентификатор объекта (OID) для политики выдачи, используемой для источника утверждения на основе сертификата.
Создайте и включите объекты свойств ресурса.
Классифицируйте файлы и папки.
Создайте условные выражения непосредственно на ресурсе или разверните с помощью политики центрального доступа, используя групповую политику или аудит доступа к глобальным объектам.

Развернуть Windows Server 2012 и Windows 8

Требуется авторизация и аудит на основе требований

Контроллер домена Windows Server 2012
Присоединенный к домену файловый сервер Windows Server 2012
Присоединенный к домену компьютер с Windows 8 (требуется только при использовании утверждений устройства)

Для авторизации и аудита на основе утверждений требуются Windows Server 2012 и Windows 8 по нескольким причинам.

Контроллер домена

Первое требование — это контроллер домена Windows Server 2012.Этот новый механизм авторизации и аудита требует расширения Active Directory. Эти новые расширения создают Windows типы утверждений, в которых Windows хранит утверждения для леса Active Directory.

Другая зависимость, от которой зависит авторизация утверждений в Центре распространения ключей Kerberos (KDC). Windows Server 2012 KDC содержит усовершенствования Kerberos, необходимые для передачи утверждения в билете Kerberos и комплексной проверке подлинности.Windows Server 2012 KDC также включает усовершенствование для поддержки защиты Kerberos.

Примечание:

Для вашей среды требуется Windows Server 2012 KDC, только если вы основываете решения об авторизации на утверждениях, которые получены из атрибутов Active Directory или сертификаты. Решения об авторизации на основе членства в группах, включая условные выражения, использующие оператор memberOf, не требуют Windows Server 2012 KDC.

Наконец, часть диспетчера учетных записей безопасности (SAM) контроллера домена Windows Server 2012 понимает типы утверждений, где они хранятся, и преобразование утверждений. KDC полагается на SAM для получения информации о заявках. которые он использует в билетах Kerberos.

Авторизация и аудит на основе утверждений не имеют функциональных требований леса или домена. Вы можете реализовать и настроить утверждения с помощью Windows Server 2008. и контроллеры домена 2008 R2 при условии, что в домене имеется достаточное количество контроллеров домена Windows Server 2012 для поддержки запросов проверки подлинности, включающих информацию о заявках.

Файловый сервер

Следующее требование для авторизации и аудита на основе утверждений — это файловый сервер Windows Server 2012. Когда пользователь подключается к общему файловому ресурсу, файловый сервер выполняет проверку доступа к общий ресурс с использованием учетных данных входящего соединения. Это означает, что файловый сервер определяет доступ к общему ресурсу. Это также означает, что различные компоненты на файловом сервере должны учитывать утверждения, такие как локальный орган безопасности и приложение Kerberos. сервер.Файловый сервер, на котором размещается общий ресурс, должен быть файловым сервером Windows Server 2012 для чтения утверждений и данных авторизации устройства из билета Kerberos, преобразования этих идентификаторов безопасности (SID) и утверждений из билета в токен аутентификации и сравнить данные авторизации в токене с условными выражениями, включенными в дескриптор безопасности.

Пользовательский компьютер с Windows 8 (требуется для подачи заявки на устройство)

Рядовые компьютеры

Windows 8 требуются для авторизации и аудита на основе утверждений при использовании утверждений устройств.Контроллер домена Windows Server 2012 выдает утверждения в билетах Kerberos, когда клиент Kerberos запрашивает утверждения в своем запросе. Присоединившиеся к домену компьютеры с Windows 8 запрашивают информацию о заявках при выполнении запросов Kerberos, и эти компьютеры понимают, как найти контроллер домена, поддерживающий утверждения. Также клиентские запросы Kerberos с рядовых компьютеров Windows Server 2012 включают билет на выдачу билетов (TGT) устройства (компьютера), если контроллер домена поддерживает динамический контроль доступа.

Вы можете использовать авторизацию на основе утверждений с рядовыми компьютерами под управлением предыдущих версий Windows при условии, что файловый сервер, на котором размещены файлы, работает под управлением Windows Server 2012, настроенного вами сетевой сервер Microsoft : Попытайтесь S4U2Self получить информацию о заявке. Для параметра локальной политики безопасности установлено значение по умолчанию или включено, и файловый сервер может успешно взаимодействовать с контроллером домена Windows Server 2012. Windows Server Файловые серверы 2012 автоматически включают S4U2Self при развертывании одной или нескольких политик центрального доступа на файловом сервере.

Включить поддержку динамического контроля доступа

Необходимо включить компьютеры с Windows 8 и файловые серверы Windows Server 2012 для поддержки утверждений и комплексной проверки подлинности.

KDC

Вы включаете поддержку утверждений, создавая объект групповой политики, который включает параметр групповой политики. Поддержка KDC для утверждений, комплексной аутентификации и защиты Kerberos . Вы применяете этот объект групповой политики к Контроллеры домена организационная единица (OU), чтобы применить этот параметр ко всем контроллерам домена в OU.Контроллеры домена Windows Server 2012 читают эту конфигурацию, тогда как другие контроллеры домена игнорируют этот параметр.

Клиент Kerberos

Вы включаете поддержку утверждений в клиенте Kerberos Windows 8 и Windows Server 2012, создавая объект групповой политики, который включает параметр групповой политики Поддержка клиента Kerberos для утверждений, комплексной проверки подлинности и защиты Kerberos. Клиенты Kerberos для Windows 8 и Windows Server 2012 не запрашивают утверждения, защищают запросы Kerberos и не выполняют комплексную проверку подлинности по умолчанию — вы должны включить его.

После включения поддержки заявок на KDC и клиенте Kerberos перезагрузите рядовые серверы Windows Server 2012 и компьютеры с Windows 8, присоединенных к домену, чтобы эти компьютеры использовали Kerberos. бронирование и запрос претензий. Вам не нужно перезагружать контроллеры домена.

Создание видов требований

Контроллеры домена теперь могут выдавать заявки; однако вам необходимо настроить типы утверждений, прежде чем контроллер домена сможет выдавать утверждения. Используя Центр администрирования Active Directory, вы создаете типы утверждений на основе атрибутов, которые получают информацию из атрибутов пользователя и компьютера.Вы можете создавать типы утверждений на основе сертификатов с помощью модуля Active Directory для Windows PowerShell. Также вы можете создать претензию на основе преобразования типы, которые используются исключительно для преобразования требований через лесные трасты.

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

Важно:

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

Заполнить атрибуты, используемые в качестве источников утверждений

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

Важно:

Dynamic Access Control позволяет использовать данные атрибутов пользователя и компьютера для авторизации. Следовательно, вам необходимо защитить эти атрибуты как подходит для вашей среды.

Создание объектов свойств ресурса

Проверка доступа Windows требует, чтобы информация включалась в файлы и папки для проверки утверждений.Способ настройки этой информации для этих ресурсов — создание объектов свойств ресурса. Объекты свойств ресурса определяют дополнительные свойства, которые появляются в файлах и папках. Windows использует эти свойства для обеспечения соответствия и отчетности, а также для авторизации и аудита. Используйте Центр администрирования Active Directory для создания и управления глобальные свойства ресурса и списки свойств ресурса, к которым они принадлежат.

Классифицировать файлы и папки

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

Защита ресурсов с использованием условных выражений

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

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

Динамический пароль 2.0 / Хабр

Итоги из статьи Динамический пароль

Идеи и пояснения

Динамический пароль 2.0

Динамический пароль / Хабр

Динамический код на банковской карте или технология 3-D Secure?

Традиционный СVV/CVC – трехзначный код на банковской карте

Эволюция CVV/CVC — динамический трехзначный код

Динамический верификационный код или 3-D Secure? Вопросы безопасности, удобства, стоимости.

что это значит, как подключить

Что это значит?

Как подключить адрес динамической аутентификации

Для старой карты

Для новой карты

Обзор способов и протоколов аутентификации в веб-приложениях

Аутентификация по паролю

HTTP authentication

Forms authentication

Другие протоколы аутентификации по паролю

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

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

Аутентификация по ключам доступа

Аутентификация по токенам

Форматы токенов

Стандарт SAML

Стандарты WS-Trust и WS-Federation

Стандарты OAuth и OpenID Connect

Заключение

динамический пароль — это… Что такое динамический пароль?

Смотреть что такое «динамический пароль» в других словарях:

А давайте заставим пользователя использовать безопасный пароль

Аутентификация не бинарна

Не надо ограничивать максимальную длину пароля

Убедитесь, что любые ASCII символы допустимы

Не используйте подсказки для паролей

Снизьте нагрузку на мозг пользователя

Выводы

динамических паролей — будущее аутентификации |

Уход от статического пароля: часть II — динамический пароль

Что такое динамический пароль?

динамический пароль — это … Что такое динамический пароль?

динамический пароль — это … Что такое динамический пароль?

Введение в динамический контроль доступа — статьи TechNet — США (английский)

Что такое динамический контроль доступа?

Условные выражения для записей разрешений

Инфраструктура классификации файлов

Политики центрального доступа

Назначение / Преимущества

Технический Обзор

Предварительные требования

Технологии основания

Функциональное описание

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

Развернуть Windows Server 2012 и Windows 8

Файловый сервер

Пользовательский компьютер с Windows 8 (требуется для подачи заявки на устройство)

KDC

Клиент Kerberos

Создание видов требований

Классифицировать файлы и папки

Защита ресурсов с использованием условных выражений

Добавить комментарий Отменить ответ

Рубрики