Системное администрирование → Аутентификация на сетевых устройствах CISCO средствами Active Directory из песочницы
Интеграция CISCO AAA и Microsoft Active Directory
Наверняка многие системные администраторы рано или поздно сталкиваются с проблемой аутентификации на сетевых устройствах. Если руководствоваться best-practices, то учетные записи должны быть персонифицированными, пароли должны отвечать критериям устойчивости, время жизни паролей должно быть ограничено. Также не будем забывать о разграничении уровней доступа в соответствии с выполняемыми задачами и поддержке актуальности базы пользователей, связанной с изменениями в штате сотрудников. При соблюдении этих требований ведении базы пользователей на каждом устройстве становится трудоемкой и нетривиальной задачей, а на практике часто просто игнорируется, администраторы ограничиваются заданием паролей на физическую и виртуальную консоль и заданием пароля суперпользователя (enable). Логичным решением этой проблемы является ведение единой базы пользователей с контролем выдвигаемых к учетным записям требований. Если у нас есть Active Directory, почему бы не использовать его?

Рис.1 Топология системы
Информационная безопасность → Новый механизм аутентификации в Windows 8: «вход по картинке»
Похоже, что разработчики новой операционной системы Windows 8 не сидят на месте, а действительно воплощают в жизнь новые идеи, не ограничиваясь только визуальными отличиями от конкурентов, такими, например, как интерфейс Metro.
Традиционный механизм аутентификации пользователей при помощи логина и пароля в Windows 8 предлагается дополнить альтернативным, цель которого упростить работу с системой, когда особых требований для безопасности не предъявляется, что типично для домашних условий. Суть нового способа будет заключаться в следующем:
Демонстрация этого процесса приведена на видео:
[Источник]
Традиционный механизм аутентификации пользователей при помощи логина и пароля в Windows 8 предлагается дополнить альтернативным, цель которого упростить работу с системой, когда особых требований для безопасности не предъявляется, что типично для домашних условий. Суть нового способа будет заключаться в следующем:
- Пользователь включает альтернативный режим входа — «по картинке».
- Далее загружает в систему некоторую известную ему картинку, которая будет использоваться для процесса аутентификации
- Система просит выполнить по картинке несколько определенных характерных жестов — «тапов», «кругов» и т.п. и запоминает их.
- В дальнейшем эти жесты предлагается повторить — «введите пароль еще раз» — и при следующем входе в систему пользователь, увидев знакомую ему картинку, должен будет выполнить уже знакомые ему жесты по картинке. Естественно, в случае успеха он получает доступ к своей учетной записи.
Демонстрация этого процесса приведена на видео:
[Источник]
Веб-стандарты → BrowserID: почтовый адрес как ID пользователя
Mozilla закончила разработку BrowserID — единой децентрализованной системы аутентификации, которая использует HTML5, криптографию с открытым ключом и цифровые подписи. Она основана на упрощённой интерпретации Verified Email Protocol.
Даже сейчас, на первом этапе внедрения, система довольно проста для пользователя: ему нужно один раз подтвердить email, после чего он получает возможность безопасной авторизации на любом сайте в два клика мышкой, без ввода пароля. В будущем авторизация ещё более упростится, когда поддержку BrowserID внедрят в браузеры, а почтовые провайдеры станут центрами идентификации первого уровня.

Так будет работать система, если Gmail станет поддерживать BrowserID. В этом случае отпадёт необходимость подтверждать свой email на сайте Browserid.org, который сейчас является пока единственным центром идентификации первого уровня.
Кроме отсутствия паролей, ключевым преимуществом BrowserID является защита приватности — в отличие от OpenID и всех подобных систем, провайдер identity в BrowserID не получает данных о том, на каком сайте залогинился пользователь.
Даже сейчас, на первом этапе внедрения, система довольно проста для пользователя: ему нужно один раз подтвердить email, после чего он получает возможность безопасной авторизации на любом сайте в два клика мышкой, без ввода пароля. В будущем авторизация ещё более упростится, когда поддержку BrowserID внедрят в браузеры, а почтовые провайдеры станут центрами идентификации первого уровня.

Так будет работать система, если Gmail станет поддерживать BrowserID. В этом случае отпадёт необходимость подтверждать свой email на сайте Browserid.org, который сейчас является пока единственным центром идентификации первого уровня.
Кроме отсутствия паролей, ключевым преимуществом BrowserID является защита приватности — в отличие от OpenID и всех подобных систем, провайдер identity в BrowserID не получает данных о том, на каком сайте залогинился пользователь.
Веб-разработка → Одновременная межсайтовая аутентификация без велосипеда
Одновременная межсайтовая аутентификация (SSO), для чего же она нужна? Допустим у нас есть, назовём его анахроничным термином «портал», с блогами, фотками, фейлами (или файлами, кому как), назовём его fail.ru (не путать с одноимённым сервисом почты на букву М), причём всё это усложнено следующими факторами:
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.
И вот у такого Кощея нам нужно будет сломать яйцо и дать пользователю возможность зайти только один раз, а потом заходить на все дружественные ресурсы не подтвеждая свою личность ещё раз.
Об этом уже достаточно много писали, причём и код в том числе. Но мы не пойдём по проторенной дороге велосипедостроения, а как настоящие инженеры возьмём готовые наработки и используем их. Способ прост, и подходит даже для такой сложной ситуации.
Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.
И вот у такого Кощея нам нужно будет сломать яйцо и дать пользователю возможность зайти только один раз, а потом заходить на все дружественные ресурсы не подтвеждая свою личность ещё раз.
Об этом уже достаточно много писали, причём и код в том числе. Но мы не пойдём по проторенной дороге велосипедостроения, а как настоящие инженеры возьмём готовые наработки и используем их. Способ прост, и подходит даже для такой сложной ситуации.
Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.
Информационная безопасность → Вторичная аутентификация аккаунта на сайте
Что такое вторичная аутентификация?
Когда на сайте имеются учетные записи пользователей, применяется аутентификация или идентификация пользователя.
Но с некоторых пор стали применять и вторичную аутентификацию – пароли крадут, они могут теряться, часто забываются. Да и ошибочные действия пользователей или банальная невнимательность может к этому привести.
Вторичная аутентификация поможет идентифицировать и вернуть доступ к данным.
Используются различные процедуры вторичной аутентификации:
• пересылка пользователю по e-mail ключа доступа;
• отправка SMS с кодом доступом;
• ответ на определенный контрольный вопрос;
• ввод старого пароля;
• подтверждение личности от третьего лица (третьих лиц).
Если взлом сайта, системы будет направлен на систему вторичной аутентификации (а не на обход более сложной системы доступа по паролю), то аккаунт может стать менее защищенным.
Например, в 2008 году в США хакер взломал аккаунт Сары Пэйлин (кандидата в президенты США) только лишь отгадав ответ на секретный вопрос к ее аккаунту: «Где Вы познакомились со своим будущим супругом?» (т.е. хакер имитировал известный вирус Морриса).
Когда на сайте имеются учетные записи пользователей, применяется аутентификация или идентификация пользователя.
Но с некоторых пор стали применять и вторичную аутентификацию – пароли крадут, они могут теряться, часто забываются. Да и ошибочные действия пользователей или банальная невнимательность может к этому привести.
Вторичная аутентификация поможет идентифицировать и вернуть доступ к данным.
Используются различные процедуры вторичной аутентификации:
• пересылка пользователю по e-mail ключа доступа;
• отправка SMS с кодом доступом;
• ответ на определенный контрольный вопрос;
• ввод старого пароля;
• подтверждение личности от третьего лица (третьих лиц).
Если взлом сайта, системы будет направлен на систему вторичной аутентификации (а не на обход более сложной системы доступа по паролю), то аккаунт может стать менее защищенным.
Например, в 2008 году в США хакер взломал аккаунт Сары Пэйлин (кандидата в президенты США) только лишь отгадав ответ на секретный вопрос к ее аккаунту: «Где Вы познакомились со своим будущим супругом?» (т.е. хакер имитировал известный вирус Морриса).
Информационная безопасность → Токены vs Пароли
Пост навеян недавней темой про токены, в комментариях к которой царила некоторая неразбериха. Я сделал вывод, что многие не до конца понимают или даже вообще не понимают, что такое токен, с чем его едят и чем токен не является. Желание расставить все точки над i привело к написанию нижеследующего текста. Далее речь пойдет именно о USB-токенах, которые можно подключать к компьютеру, давать команды и получать результаты их выполнения. Приступим.
Информационная безопасность → Основы биометрии
Эта статья в какой-то мере является продолжением прошлой, а в какой-то её приквэлом. Здесь я расскажу про основы построения любой биометрической системы и про то, что осталось за кадром прошлой статьи, но обсуждалось в комментариях. Акцент сделан не на сами биометрические системы, а на их принципах и области действия.
Тем, кто не читал статью, или уже забыл — советую просмотреть что такое FAR и FRR, так как эти понятия будут использоваться и здесь.
Тем, кто не читал статью, или уже забыл — советую просмотреть что такое FAR и FRR, так как эти понятия будут использоваться и здесь.
Google → Двухэтапная аутентификация Google в России
Google запустил двухэтапную аутентификацию в России, а так же еще в 150 странах и на 40 языках. Опция доступна в настройках аккаунта
Вопросы безопасности в веб-технологиях → Опасность использования «учебных» криптопротоколов из песочницы
Написать данную статью меня побудил не столько сам пост от пользователя EugeneSukhov, сколько первый комментарий от AstralMan.
Действительно, зачастую увидев описание или даже готовую реализацию (соответствующую описанию) криптографического протокола высокого уровня, некоторые люди пытаются её тут же внедрить в собственный проект и объявить об этом широкой общественности (просьба не воспринимать это как камень в огород AstralMan). А ведь такое решение далеко не самое удачное! Описание криптопротокола, как правило, не содержит различных необходимых проверок на стороне участников и уточнений, имеющих критическую важность при реальном использовании. История знает множество примеров, когда протокол, основанный на стойких и прошедших испытание временем алгоритмах шифрования, хеширования и т.д. оказывался взломанным именно из-за самой логики построения, и из-за таких «мелочей» как проверки и уточнения. Описание криптопротокола, демонстрирующее саму его идею, будем называть учебным.
Действительно, зачастую увидев описание или даже готовую реализацию (соответствующую описанию) криптографического протокола высокого уровня, некоторые люди пытаются её тут же внедрить в собственный проект и объявить об этом широкой общественности (просьба не воспринимать это как камень в огород AstralMan). А ведь такое решение далеко не самое удачное! Описание криптопротокола, как правило, не содержит различных необходимых проверок на стороне участников и уточнений, имеющих критическую важность при реальном использовании. История знает множество примеров, когда протокол, основанный на стойких и прошедших испытание временем алгоритмах шифрования, хеширования и т.д. оказывался взломанным именно из-за самой логики построения, и из-за таких «мелочей» как проверки и уточнения. Описание криптопротокола, демонстрирующее саму его идею, будем называть учебным.
Вопросы безопасности в веб-технологиях → Аутентификация на базе ЭЦП
Уже в нескольких топиках рассматривались проблемы построения безопасного механизма аутентификации при небезопасном соединении. Ниже предлагается к обсуждению схема с использованием асимметричной криптографии. Такой подход позволит аутентифицироваться на сервере, никогда не передавая серверу пароль, ни при регистрации, ни при аутентификации. Как всегда, будет демонстрация и исходные коды. Кому данная тема интересна, прошу под кат.