что такое транспортный пароль
Инструкция по запросу пользовательского сертификата
Если необходимо выпустить сертификат для мобильного устройства, ознакомьтесь с этой инструкцией: https://cert.sberbank.ru/files/instructions.docx
2. Нажмите на ссылку «Запросить сертификат для рабочей станции».
3.1. Если Вы не знаете свой логин и пароль, то необходимо создать обращение на сброс пароля к учетной записи SIGMA.
Внимание! Обращение на сброс пароля к учетной записи SIGMA обязательно должен выставить администратор информационной безопасности (АИБ) Вашего подразделения.
Используя портал «ДРУГ», АИБ создает обращение, выбрав из каталога шаблон:
4. В диалоговом окне предупреждения нажмите Да ( Yes ).
6. В диалоговом окне предупреждения снова нажмите Да ( Yes ).
7. На следующей странице нажмите на ссылку «Установить сертификат».
8. После появления станицы с сообщением «Ваш сертификат успешно установлен» можно закрыть браузер
Как работают одноразовые пароли
Вступление
Как показывает практика, существует определенное непонимание принципов работы одноразовых паролей (это те самые, которые используются в GMail, в спец. токенах платежных систем и так далее).
Прочитав эту небольшую статью, Вы разберетесь в принципе работы одноразовых паролей на основе хэшей, а заодно напишете на Python небольшую программу, которая умеет вычислять пароли для двухэтапной аутентификации Google.
Хэш-функция
Хэш-функция позволяет взять любые данные любой длины и построить по ним короткий «цифровой отпечаток пальца». Длина значения хэш-функции не зависит от длины исходного текста; например, в случае популярного алгоритма SHA-1 длина этого отпечатка составляет 160 бит.
Чтобы понять, почему значение всегда имеет одинаковую длину и не зависит от исходного текста, можно упрощенно представить хэш-функцию в виде кодового замка с колесиками. Вначале мы выставляем все колесики в «ноль», затем идем по тексту и для каждой буквы прокручиваем колесики в соответствии с некоторыми правилами. То число, которое окажется на замке в конце, и есть значение хэш-функции. Примерами таких функций являются MD5, SHA-1, ГОСТ_Р_34.11-94.
Не придумывайте свои хэш-функции, используйте стандартные реализации (например, в случае Python):
Идея хэш-функции в том, что она работает только в одном направлении: ее очень легко подсчитать для «Войны и мира», но практически невозможно по уже готовому значению хэш-функции найти документ, который даст такое же значение. Даже если изменить в документе всего одну букву, хэш изменится полностью:
В связи с этим возникает естественное желание использовать хэш-функцию для контроля целостности сообщений, которые Алиса посылает Бобу: Алиса подсчитывает для каждого своего сообщения значение SHA-1 и вкладывает его в конверт; Боб, самостоятельно подсчитав SHA-1 текста, может сравнить свой результат с Алисиным и удостовериться, что сообщение не было изменено где-то по дороге.
Однако мы забыли о Меллори, который находится где-то между Алисой и Бобом, перехватывает их переписку и вскрывает конверты! Он вполне может изменить сообщение, после чего подсчитать для него SHA-1 и приложить к письму; Боб сверит значения и ничего не заметит.
Проверка подлинности
Подумав, Алиса и Боб при встрече договариваются, что при подсчете SHA-1 они будут временно дописывать к тексту секретное слово, например, «Secret» (конечно, в реальности Алиса и Боб решили использовать куда более длинное слово, чтобы его было сложно подобрать). Меллори не знает это слово, а следовательно, даже если изменит сообщение, то не сможет скорректировать его хэш, не так ли?
К сожалению, тут есть проблемы. Да, Меллори не может изменить тело сообщения, но (раз он знает хэш от текущего текста) он всегда может дописать в конце «P.S. На самом деле все это чушь, нам пора расстаться, Боб» и просто досчитать хэш от остатка (вспомним аналогию с кодовым замком).
Чтобы защититься от этого, мы немного усложним нашу функцию:
Теперь дописывание чего-либо в конец сообщения полностью изменит исходные данные для «внешнего» вызова SHA-1 и Меллори остается вне игры.
Алиса и Боб только что придумали то, что называется HMAC (или hash-based message authentication code): основанный на хэш-функции код проверки подлинности сообщений. В реальности HMAC, принятый как стандарт RFC2104 выглядит чуть-чуть сложнее за счет выравнивания длины ключа, пары XOR’ов внутри, участия ключа во «внутреннем» хэше, но суть не меняется.
Не придумывайте свои реализации HMAC, используйте стандартные реализации, например, HMAC-SHA1:
Одноразовые пароли
Что такое «одноразовый пароль»? Это пароль, который бесполезно перехватывать с помощью кейлоггера, подглядывания через плечо или прослушивания телефонной линии — т.к. этот пароль используется ровно один раз.
Как можно было бы реализовать эту схему? Например, Алиса может сгененировать сотню случайных паролей и отдать копию Бобу. Когда Боб позвонит в следующий раз, он продиктует самый верхний пароль в списке, Алиса сверит его со своим, после чего оба вычеркнут его. При следующем звонке они используют очередной пароль и так далее, пока они не закончатся. Это не очень удобно: хранение списков, генерация новых паролей и так далее.
Лучше реализовать эту схему в виде алгоритма. Например, паролем является его номер по порядку, умноженный на секретное число. Пусть Алиса и Боб договорились, что секретным числом является 42; тогда первым паролем будет 42, вторым 84, третьим 126 и так далее. Меллори, не знающий алгоритма и секретного числа, никогда не догадается, какой пароль будет следующим!
Конечно, алгоритм лучше выбрать посложнее. Алиса вспоминает про HMAC и предлагает Бобу считать пароль номер N по формуле: HMAC(«Secret», номер-пароля). После этого им нужно договориться о ключе (в данном случае это «Secret»), зато потом Бобу нужно только помнить, какой по счету пароль он генерирует (например, двадцатый):
Впрочем, Бобу совсем не улыбается каждый раз диктовать такой длинный пароль. Они с Алисой договариваются, что будут использовать только его часть, например, последние 6 символов.
Некоторое время все идет хорошо. До момента, пока Бобу и Алисе не надоедает вести подсчет, какой по счету пароль они используют. Кто-то подсказывает им, что в качестве аргумента HMAC() вместо номера можно использовать все, к чему Алиса и Боб имеют одновременный доступ… например, текущее время!
Наши герои синхронизируют свои часы и договариваются, что будут в качестве аргумента HMAC() использовать unix time — количество секунд, прошедших с момента наступления эпохи UNIX (в UTC). Чтобы вводить пароль не торопясь, они решают разделить время на 30 секундные «окна»; таким образом, на протяжении 30 секунд действует один и тот же пароль. Естественно, Алиса, проверяющая пароли, в течение 30 секунд не позволяет использовать пароль повторно (просто запоминая его) и тем самым оставляет его по-настоящему «одноразовым».
Теперь пароль вычисляется по следующей формуле: HMAC(«Secret», unix_timestamp / 30).
Мы получили одноразовые пароли на основе текущего времени. Сгенерировать и проверить эти пароли может только тот, кто обладает ключом («Secret» в примере выше); иначе говоря, сервер и пользователь.
Следует отметить, что одноразовые пароли могут считаться и по другим алгоритмам; главное, чтобы алгоритм и секрет были известны обеим сторонам. Но т.к. у нас есть стандарт, дальше мы будем говорить именно о нем
OATH, TOTP, HOTP, RFC… WTF?
Итак, мы только что описали основные идеи, лежащие в основе:
1) HMAC, hash-based message authentication code: RFC2104
2) HOTP, hash-based one-time password: RFC4226
3) TOTP, time-based one-time password: RFC6238
Эти идеи — один из краеугольных камней инициативы Initiative For Open Authentication (OATH), направленной на стандартизацию методов аутентификации.
Двухэтапная аутентификация Google
Одноразовые пароли, основанные на времени (и подсчитываемые на основе алгоритма TOTP RFC 6238) используются также компанией Google в приложении Google Authenticator, которое можно установить на iOS, Android, BlackBerry. Это приложение автоматически генерирует одноразовые пароли раз в 30 секунд (в дополнение к основному паролю на Google Account). Это означает, что даже если Ваш основной пароль кто-то подглядит или перехватит, без очередного одноразового пароля в систему войти будет невозможно. Удобно.
ВНИМАНИЕ : Я НЕ НЕСУ НИКАКОЙ ОТВЕТСТВЕННОСТИ ЗА ВАШИ ДЕЙСТВИЯ С ВКЛЮЧЕНИЕМ И ВЫКЛЮЧЕНИЕМ ДВУХЭТАПНОЙ АУТЕНТИФИКАЦИИ GOOGLE; ВЫ СОГЛАСНЫ, ЧТО ВЫ ВЫПОЛНЯЕТЕ ИХ НА СВОЙ СТРАХ И РИСК.
На самом деле там нет ничего страшного (есть инструкции, есть trusted-компьютеры, есть резервные коды и т.д.), но если от души постараться, бездумно нажимая на кнопки, то вполне можно лишиться доступа к своему аккаунту. И все же: если не готовы экспериментировать, не трогайте Gmail; просто скачайте приложение Google Authenticator на телефон, вручную добавьте «ключ по времени» (например, «a abc def abc def abc» или просто отсканируйте QR-код ниже).
Для начала нам нужно получить секретный ключ, который используется для создания одноразового пароля. Его можно посмотреть на странице добавления Google Authenticator’а в настройках аккаунта, он находится под QR-кодом:
Обратите внимание, что если двухэтапная аутентификация уже включена, то старый ключ узнать нельзя: придется удалить старый и сгенерировать новый. Это несложно; главное, не забыть сразу обновить ключ и в Google Authenticator, если Вы им пользуетесь.
Ключ закодирован в Base32 (для удобства уберите пробелы и переведите буквы в верхний регистр).
Программа, которая подсчитывает текущий одноразовый пароль:
Теперь можно положить рядом запущенный Google Authenticator и сравнить значения.
upd #2: если хотите поиграть с 2-step verification от dropbox, в конце секрета допишите «======» (это необходимо для паддинга и корректной работы base32-декодера).
В России решили ограничить использование личных автомобилей
В рамках транспортной стратегии России до 2035 года россиян решили ограничить в использовании личных автомобилей ради общественного транспорта. Об этом пишет «Коммерсантъ» со ссылкой на соответствующее сообщение на сайте правительства.
Такие меры направлены на то, чтобы владельцы машин наносили меньший вред окружающей среде. В рамках плана предлагается минимизировать использование транспортных средств с неэкологичными двигателями, установить «цифровой контроль» за дорожным шумом и более чем в тысячу раз нарастить число заправок для электромобилей. Гражданам, которые в таких условиях останутся верны своим автомобилям, предложат «совместное использование транспортных средств» с другими россиянами, пишет «Ъ».
Документ в том числе включает долгосрочные планы по развитию автомобильного, железнодорожного, водного, воздушного и других видов транспорта на ближайшие 15 лет. На эти цели предполагается потратить 60 триллионов рублей.
Детали стратегии
Как пишет издание, авторы стратегии указали на необходимость снизить выбросы в атмосферу. Они отмечают, в частности, что 61 процент загрязняющих веществ, эмитируемых транспортом, приходится на автотранспорт. При этом с помощью обновления парка проблему решить невозможно, поскольку 82 процента от всех вредных выбросов появляется за счет стирания дорожного покрытия и «составных частей» автомобиля.
По этой причине в правительстве предлагают ограничить использование личных авто, пересаживая их владельцев на общественный транспорт. Такой вариант, сказано в стратегии, является «безальтернативным».
Авторы документа в качестве одного из сценариев рассматривают поэтапное установление ограничений на использование транспортных средств «низких экологических классов». Это предполагается осуществить в том числе за счет создания специальных экологических зон, куда запрещено въезжать машинам с неэкологичными двигателями.
Для борьбы с шумом от транспорта авторы инициативы предлагают ограничить скоростной режим внутри жилых кварталов, ставить шумозащитные экраны, а также внедрять «цифровые методы контроля уровня шума».
Кроме того, правительство намерено построить сеть заправок для электромобилей в России. По предварительным оценкам, необходимо около 250 тысяч станций для европейской части России.
В городах собираются развивать улично-дорожную сеть, за их пределами — ликвидировать «узкие места» на нынешних дорогах, а также строить новые обходы.
В городах США 30-35 процентов застроенной территории выделяется под дороги или улицы, в Европе — порядка 25 процентов. Российские же города, даже самые развитые, балансируют на отметке в 10 процентов. Поэтому введение ограничений по использованию автомобилей неизбежно. Нужно задумываться и о регулировании размера автопарка, как это сделано в Сингапуре, Японии
Другие планы транспортной стратегии
В рамках транспортной стратегии также предполагается, что более 80 процентов пассажиров автомобильного, железнодорожного и воздушного транспорта в России должны будут предоставлять свои биометрические данные для проезда.
Благодаря этому увеличится уровень комфорта и безопасности пассажиров. Также ожидается, что к 2035-му 30 процентов общественного транспорта станет беспилотным в 20 крупнейших городах России. При этом доля беспилотных грузоперевозок по основным магистралям возрастет до 50 процентов.
Также высказывались идеи о появлении к 2035 году бесплатного общественного транспорта. Однако инициативу отказались включать в новую версию документа.
TOTP (Time-based one-time Password algorithm)
С ростом числа угроз кибербезопасности, для разработчиков становится все более и более необходимым обновлять стандарты безопасности веб-приложений и быть при этом уверенными в том, что аккаунты пользователей в безопасности. Для этого в настоящее время многие онлайн-приложения просят пользователей добавить дополнительный уровень безопасности для своей учетной записи. Они делают это за счет включения двухфакторной аутентификации. Существуют различные методы реализации двухфакторной аутентификации, и аутентификация TOTP (алгоритм одноразового пароля на основе времени) является одним из них.
Чтобы понять, что из себя представляет TOTP и как он используется, необходимо сначала кратко рассмотреть более базовые понятия. Первое из них – двухфакторная аутентификация. Двухфакторная аутентификация (или многофакторная аутентификация) — это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. Это означает, что после включения двухфакторной аутентификации пользователь должен пройти еще один шаг для успешного входа в систему. Стандартные шаги для входа в учетную запись – это ввод логина и ввод пароля (рис.1).
Рисунок 1. Порядок входа в учетную запись без двухфакторной аутентификации
Включение двухфакторной аутентификации добавляет в порядок входа дополнительный шаг (рис.2). Этот метод более безопасен, поскольку преступник не может получить доступ к учетной записи пользователя, если у него нет доступа как к обычному паролю пользователя, так и к одноразовому паролю.
Рисунок 2. Вход в учетную запись с подключенной двухфакторной аутентификацией
В настоящее время существует два широко используемых метода получения одноразового пароля:
На основе SMS. Каждый раз, когда пользователь входит в систему, он получает на указанный в учетной записи номер мобильного телефона текстовое сообщение, которое содержит одноразовый пароль.
На основе TOTP. При включении двухфакторной аутентификации пользователю предлагается отсканировать QR-код с помощью специального приложения для смартфона, которое в дальнейшем постоянно генерирует одноразовый пароль для пользователя.
Метод на основе SMS не требует пояснений. Несмотря на свою простоту, он имеет ряд проблем. Например, ожидание SMS при каждой попытке входа в систему, проблемы с безопасностью и т. д. Вследствие чего NIST еще в 2016 году рекомендовала не использовать его в новых системах аутентификации. В связи с минусами метода на основе SMS, метод на основе TOTP становится популярным из-за его преимуществ.
Также, стоит отметить, что в настоящий момент есть некоторые разногласия о том, что именно считать шагами, а что факторами аутентификации. Общепризнанным является существование трех факторов:
Знание, например, пароль
Обладание (в физическом смысле), например, смартфон
То, чем вы являетесь, например, биометрические данные
При этом шаги аутентификации являются субъединицами факторов, так, если для входа в систему необходимо введение двух паролей, то по сути мы используем только фактор знания. Если говорить о рассматриваемых нами методах, то метод на основе SMS принято относить к двухшаговой, но однофакторной аутентификации, т. к. пароль для SMS генерируется на сервере, а TOTP к двухфакторной, поскольку для генерации пароля необходимо наличие определенного приложения на смартфоне, что усложняет задачу доступа злоумышленников к этой информации.
Итак, используя для двухфакторной аутентификации метод на основе TOTP, мы создаем одноразовый пароль на стороне пользователя (а не на стороне сервера) через приложение для смартфона. Это означает, что у пользователя всегда есть доступ к своему одноразовому паролю. А также предотвращает отправку текстового сообщения сервером при каждой попытке войти в систему. Кроме того, сгенерированный пароль изменяется через определенный промежуток времени, что делает его, по сути, одноразовым.
Для реализации двухфакторной аутентификации с использованием TOTP необходимо учитывать основное требование – пароль должен создаваться на стороне пользователя, а также постоянно меняться.
Решение данной задачи может выглядеть следующим образом:
Когда пользователь включает двухфакторную аутентификацию, происходит следующее
Внутренний сервер создает секретный ключ для этого конкретного пользователя
Затем сервер передает этот секретный ключ телефонному приложению пользователя
Телефонное приложение инициализирует счетчик
Телефонное приложение генерирует одноразовый пароль, используя этот секретный ключ и счетчик
Телефонное приложение изменяет счетчик через определенный интервал и восстанавливает одноразовый пароль, делая его динамическим
Этот алгоритм включает в себя два этапа:
Создать хеш HMAC (используя алгоритм хеширования SHA-1) из секретного ключа и счетчика
В этом коде на выходе будет строка длиной 20 байт. Эта длинная строка не подходит в качестве одноразового пароля. Итак, нам нужен способ обрезать эту строку. HOTP определяет способ обрезать эту строку до желаемой длины
Это в значительной степени определяет алгоритм HOTP. Документ RFA4226 объясняет, почему это наиболее безопасный способ получить одноразовый пароль из этих двух значений.
Итак, мы нашли способ получить одноразовый пароль с помощью секретного ключа и счетчика. А как следить за счетчиком? Ответ на этот вопрос находится в TOTP. TOTP переводится как «Одноразовый пароль на основе времени». Он был опубликован IETF как RFC6238. TOTP использует алгоритм HOTP для получения одноразового пароля. Единственная разница в том, что здесь вместо «счетчика» используется «время», и это дает решение нашей проблемы. Это означает, что вместо инициализации счетчика и его отслеживания мы можем использовать время в качестве счетчика в алгоритме HOTP для получения OTP. Поскольку и сервер, и телефон имеют доступ ко времени, ни один из них не должен отслеживать счетчик. Кроме того, чтобы избежать проблемы с разными часовыми поясами сервера и телефона, мы можем использовать временную метку Unix, которая не зависит от часовых поясов. Однако время Unix определяется в секундах, поэтому оно меняется каждую секунду. Это означает, что сгенерированный пароль будет меняться каждую секунду, что не очень хорошо. Вместо этого нам нужно добавить значительный интервал перед изменением пароля. Например, приложение Google Authenticator меняет код каждые 30 секунд.
Итак, мы решили проблему счетчика. Теперь нам нужно решить нашу третью проблему: поделиться секретным ключом с приложением телефона. Здесь нам может помочь QR-код. Хотя есть возможность попросить пользователей вводить секретный ключ напрямую в приложение телефона, безопасность ключа зависит от его длины, и пользователю будет неудобно вводить такую длинную строку. Поскольку большинство смартфонов оснащено камерой, пользователь может использовать ее для того, чтобы отсканировать QR-код, и получить от него секретный ключ. Все, что для этого нужно – преобразовать секретный ключ в QR-код и показать его пользователю. В настоящее время есть несколько бесплатных телефонных приложений (например, Google Authenticator App, Authy и т.д.), которые могут генерировать одноразовый пароль для пользователя. Поэтому в большинстве случаев создавать собственное телефонное приложение не нужно. Следующие псевдокоды объясняют способ реализации двухфакторной аутентификации на основе TOTP в веб-приложении.
Пользователя просят отсканировать этот QR-код. Когда приложение телефона сканирует QR-код, оно получает секретный ключ пользователя. Используя этот секретный ключ, текущее время Unix и алгоритм HOTP, приложение телефона сгенерирует и отобразит пароль. Затем система просит пользователя ввести сгенерированный код после сканирования QR-кода. Это необходимо, чтобы убедиться, что пользователь успешно отсканировал изображение и приложение для телефона успешно сгенерировало код.
Здесь используется алгоритм HOTP на стороне сервера, чтобы получить аутентификацию на основе OTP по секретному ключу и текущему времени Unix. Если этот OTP совпадает с введенным пользователем, то появляется возможность включить двухфакторную аутентификацию для этого пользователя. Теперь, после каждой операции входа в систему, проверяется, включена ли для этого конкретного пользователя двухфакторная аутентификация. Если да, то запрашивается одноразовый пароль, отображаемый в приложении телефона. И если этот набранный код правильный, только тогда пользователь аутентифицируется.
Если пользователь потеряет код, есть несколько способов помочь пользователю восстановить его. Обычно, когда они включают двухфакторную аутентификацию, есть возможность показать секретный ключ вместе с QR-кодом и попросить их сохранить этот код в безопасном месте. Такие приложения, как Google Authenticator App, позволяют сгенерировать пароль путем прямого ввода секретного ключа. Если пользователь потеряет код, он может ввести этот надежно сохраненный секретный ключ в приложение телефона, чтобы снова сгенерировать одноразовый пароль. При наличии номера телефона пользователя возможно использовать метод на основе SMS, чтобы отправить пользователю одноразовый пароль, чтобы помочь ему восстановить код.
Двухфакторная аутентификация набирает популярность. Многие веб-приложения реализуют его для дополнительной безопасности. В отличие от метода на основе SMS, метод TOTP также не требует особых усилий. Так что эту функцию стоит реализовать для любого приложения.