Вы когда-нибудь интересовались механизмом работы ssh-ключей? Или тем, насколько безопасно они хранятся?

Я использую ssh каждый день много раз — когда запускаю git fetch или git push, когда развертываю код или логинюсь на сервере. Не так давно я осознал, что для меня ssh стал магией, которой я привык пользоваться без понимация принципов ее работы. Мне это не сильно понравилось — я люблю разбираться в инструментах, которые использую. Поэтому я провел небольшое исследование и делюсь с вами результатами.

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

Итак, если вам доводилось прибегать к аутентификации по ключу, то у вас, скорее всего, есть файл ~/.ssh/id_rsa или ~/.ssh/id_dsa в домашнем каталоге. Это закрытый (он же приватный) RSA/DSA ключ, а ~/.ssh/id_rsa.pub или ~/.ssh/id_dsa.pub — открытый (он же публичный) ключ. На сервере, на котором вы хотите залогиниться, должна быть копия открытого ключа в ~/.ssh/authorized_keys. Когда вы пытаетесь залогиниться, ssh-клиент подтвержает, что у вас есть закрытый ключ, используя цифровую подпись; сервер проверяет, что подпись действительна и в ~/.ssh/authorized_keys есть открытый ключ, и вы получаете доступ.

Что же хранится внутри закрытого ключа?

Медленно, но неотвратимо наступает смена решений SSO на основе SAML на решения OpenID стека. С недавних пор компания Google реализовала поддержку OpenID Connect протокола на своих серверах. Насколько он может быть приемлем для Вашего проекта и как с ним работать, оценить по спецификации протокола довольно трудно. Немного облегчить это решение должна статья одного из авторов спецификации в своём блоге, перевод которой я и предоставляю аудитории хабра. В целях упростить понимание, некоторые моменты были добавлены от себя, таким образом, чтобы не приходилось обязательно читать ссылки на используемые технологии, но ознакомится с некоторыми из них всё же я рекомендую.

Когда вы читаете спецификацию по OpenID Connect, вы можете испытывать довольно неприятные чувства от лёгкой испуганности до полнейшего разочарования. Всё это происходит потому, что они написаны на “сухом” языке спецификации, и по большей части они описывают граничные случаи, исключения и т.д. Тем не менее, когда вы переводите их на нормальный человеческий язык и переключаетесь на конкретные случаи, всё становится довольно очевидно. Итак, давайте приступим! (Ремарочка: большая часть текста совпадает с первоначальным предложением, написанным Дэвидом Рекордоном. В основном, мои правки затронули лишь некоторые из имен параметров и другие мелочи)

Многим из вас знаком Wireshark — анализатор трафика, который помогает понять работу сети, диагностировать проблемы, и вообще умеет кучу вещей.



Одна из проблем с тем, как работает Wireshark, заключается в невозможности легко проанализировать зашифрованный трафик, вроде TLS. Раньше вы могли указать Wireshark приватные ключи, если они у вас были, и расшифровывать трафик на лету, но это работало только в том случае, если использовался исключительно RSA. Эта функциональность сломалась из-за того, что люди начали продвигать совершенную прямую секретность (Perfect Forward Secrecy), и приватного ключа стало недостаточно, чтобы получить сессионный ключ, который используется для расшифровки данных. Вторая проблема заключается в том, что приватный ключ не должен или не может быть выгружен с клиента, сервера или HSM (Hardware Security Module), в котором находится. Из-за этого, мне приходилось прибегать к сомнительным ухищрениям с расшифровкой трафика через man-in-the-middle (например, через sslstrip).

Логгирование сессионных ключей спешит на помощь!

Что ж, друзья, сегодня я вам расскажу о способе проще! Оказалось, что Firefox и Development-версия Chrome поддерживают логгирование симметричных сессионных ключей, которые используются для зашифровки трафика, в файл. Вы можете указать этот файл в Wireshark, и (вуаля!) трафик расшифровался. Давайте-ка настроим это дело.

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

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

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

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

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

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

_{Grimoire ensorcele by naiiade}

Любую достаточно развитую технологию можно сравнить с оружием: когда у врага есть ружье, а у тебя нет, поневоле хочется изменить баланс сил в свою пользу. В области IT-безопасности знания, передаваемые различными способами, и есть то самое оружие, использование которого ограничивается не столько нормами УК, сколько этическим выбором.

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

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

Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

Американский институт стандартов и технологий (NIST) выступил за отказ от использования SMS в качестве одного из элементов двухфакторной аутентификации. В очередном черновике стандарта Digtial Authentication Guideline представители ведомства указывают, что «[внеполосная аутентификация] с помощью SMS будет запрещена стандартом и не будет допускаться в его последующих изданиях».

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

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

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

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

Моя компания не стала исключением, и мы так же, как и многие другие, пользуемся этой технологией. И, как многие другие, используем, в качестве шлюза удаленного доступа — Cisco ASA 55xx.

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

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

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

С появлением библиотеки GCrypt-1.7.0 с поддержкой российской криптографии (ГОСТ 28147-89, ГОСТ Р 34.11-94/2012 и ГОСТ Р 34.10-2001/2012), стало возможным говорить о поддержке российского PKI в таких проектах как Kleopatra и KMail.

KMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME. И то и другое базируется на архитектуре PKI, сертификатах X509 и протоколах CMS/PKCS#7:

Много где написано о том, как получить 100% и A+ по тесту от Qualys. При всём при том практически везде директивы ssl_ciphers и подобные даются как эдакие магические строки, которые нужно просто вставить, и надеяться, что автор не подводит вас под монастырь. Эта статья призвана исправить это недоразумение. По прочтению этой статьи директива ssl_ciphers потеряет для вас всякую магию, а ECDHE и AES будут как друзья да братья.

Также вы узнаете почему 100% по тестам — не всегда хорошо в реальности.

При выполнении очередного госзаказа наша команда столкнулась с проблемой интеграции сайта с ЕСИА. Инструкции по решению этой задачи в сети нет, кроме информации в официальных документах МинКомСвязи (примерно 300 страниц в трех регламентах). Также есть компании, которые оказывают платные услуги по интеграции ЕСИА. Мы реализовали, описали процесс интеграции и решили поделиться с сообществом habrahabr.

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

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



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

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

Привет, Хабр! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк для соло-технономада.

Надо ли нам каждый месяц читать очередной пост про это?

Несколько лет участия в проектах на границе энтерпрайза и системщины окончательно отбили нюх. Чтобы разобраться в вопросе, я заглянул в топ гугла и обнаружил там кучу однобоких рейтингов. Наверное, самым лучшим оказался Java Web Frameworks Index от ZeroTurnaround.

Помните одну из тех самых надоедливых возможностей Windows, особенно знакомую геймерам, когда пятикратное нажатие Shift вызывает специальное окошечко, предлагающее включить режим залипания клавиш? Эта «фича» дожила аж до Windows 10, к слову. Ну так вот, я, стоя у терминала Сбербанка с полноразмерной клавиатурой и ожидая ответа оператора по телефону, от скуки решил понажимать этот самый Shift, наивно полагая, что без функциональных клавиш это ни к чему не приведёт. Как бы не так! Пятикратное быстрое нажатие этой клавиши выдало мне то самое окошечко, к тому же обнажив панель задач со всем банковским ПО. Остановив работу пакетного файла (см. панель задач на видео ниже), а затем и всего банковского ПО, можно сломать терминал.

Наконец-то я доделал игру, которая работает на видеокарте. Она несколько месяцев повисела в раннем доступе на стиме, и теперь я её окончательно выпустил. Основная фишка игры в том, что она представляет собой физическую симуляцию, которая выполняется на графическом процессоре. Основной код игры — это огромный compute shader, 6 тысяч строк на HLSL. Десятки тысяч взаимодействующих частиц обрабатываются параллельно, и выходит довольно быстро. Всё в игре сделано из этих частиц. Вот несколько гифок о том, как это работает:

UPD2. По данным Центробанка в 2017 году было похищено 339,5 млн.р. Нетрудно догадаться, что речь именно про Глобэкс. В обзоре FinCERT говорится: «В Банк России направлена информация об одной успешной атаке на рабочее место оператора системы SWIFT. Объем несанкционированных операций в результате данной атаки составил 339,5 миллиона рублей».

UPD. Банк-жертва — Глобэкс. Размер украденного исчисляют десятками миллионов рублей.

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

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

Как правило, этот процесс работает достаточно хорошо, и ошибочно выпущенных сертификатов немного. Однако проблем хватает с лихвой. EV сертификаты содержат информацию о юридическом лице, стоящем за сертификатом, но не более того. Наименование юридического лица, однако, может быть достаточно вариативным; Например, Джеймс Бертон недавно получил EV сертификат для своей компании «Identity Verified»(англ. Подлинность проверена — прим. перев.). К сожалению, у пользователей просто нет возможности увидеть и разобраться в таких особенностях, и это создает значительный простор для фишинга.

Принцип работы протокола SSL/TLS основан на криптографии с открытым ключом. Одна или обе стороны взаимодействия обладают сертификатами и соответствующими закрытыми ключами. Это позволяет производить аутентификацию и шифрование трафика.

На сайте проекта Let's Encrypt появилась информация, что 19 октября 2015 удостоверяющие центры «Let's Encrypt Authority X1» и «Let's Encrypt Authority X2» получили кросс-подписи от IdenTrust. Теперь сертификаты выпущенные Let's Encrypt стали доверенными для всех основных браузеров. Проверить это можно, зайдя на страницу, защищенную первым сертификатом Let's Encrypt: helloworld.letsencrypt.org. Если ваш браузер не выдает предупреждения, значит, считает сертификат этого домена доверенным.