Рубрика «аутентификация»

Некоторые термины, заимствуемые из английского, входят в русский язык с нарушением всех языковых правил. Характерный пример из 90-х — слово флуд, непохожее ни на транскрипцию [flʌd], ни на транслитерацию flood. Более свежий пример — биткоин: окончание -оин характерно для химических веществ (героин, бензоин и т.д.), и читается совсем не так, как английское bitcoin; но там хотя бы можно оправдать русское написание транслитерацией.

Теперь я всё чаще, и в т.ч. на хабре, встречаю слово аутентификация в качестве кальки английского authentication. Английское слово образовано от латинского authenticatus и далее от греческого αὐθεντικός — ни в одном из них нет -фи-, -fi- или -φι-! Более того, братья-славяне пишут автентикация по-болгарски и аутентикација по-сербски.

Слово аутентикация когда-то и по-русски писалось без -фи-. Гугл находит примеры из книг 1927, 1964 и 2002 г.г.:

Аутенти(фи?)кация - 1

Аутенти(фи?)кация - 2

Аутенти(фи?)кация - 3Читать полностью »

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

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

Не стоит создавать собственные решения для аутентификации пользователей - 1

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

Разработка безопасной системы аутентификации пользователей — это по-настоящему сложная задача. Она гораздо масштабнее, чем многие думают. Эту задачу очень легко решить неправильно. Хуже того: ошибки при создании подсистем аутентификации могут повлечь за собой катастрофические последствия. В базовую структуру систем аутентификации и управления пользователями входит всего несколько форм. Из-за этого создание подобных систем может показаться весьма простым делом. Но, как известно, дьявол кроется в деталях. Нужно немало потрудиться для того чтобы сделать такие системы безопасными (и, когда это возможно или даже необходимо, учесть в них требования конфиденциальности персональных данных).
Читать полностью »

Классическими задачами, которые решаются криптографическими методами, являются обеспечение конфиденциальности и обеспечение аутентичности/имитостойкости хранимых и передаваемых данных. Ранее (примерно до середины 2000-х годов) для решения подобных задач использовались шифрование (конфиденциальность) и функции выработки имитовставки/кодов аутентификации (имитостойоксть). При этом шифрование и функция выработки имитовставки реализовывались отдельными криптографическими механизмами, что вызывало много проблем. В первую очередь, это связано с управлением ключевой информацией: при использовании одного ключа для шифрования и имитозащиты ряд схем, например, AES-CBC + AES-CBC-MAC являются полностью нестойкими. Для того, чтобы сделать такие конструкции безопасности приходится вырабатывать дополнительные ключи используя, например, функции выработки производных ключей (KDF). Это, в свою очередь, зачастую приводит к сильному усложнению криптографических протоколов, использующих подобные схемы. Кроме этого, последовательное использование двух механизмов не всегда является самым быстрым решением с точки зрения производительности.

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

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

Как организовать удаленный доступ и не пострадать от хакеров - 1

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

Как подписывать почтовую переписку GPG-ключом, используя PKCS#11-токены - 1

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

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

Читать полностью »

Apple предлагает разработать единый стандарт SMS для двухфакторной аутентификации - 1

Инженеры компании Apple, работавшие над браузером Safari, предложили создать стандартизированные SMS-сообщения для двухфакторной аутентификации на сайтах. Как утверждают в компании, стандартизация позволит связать OTP (one-time-password) SMS-сообщения с URL-адресом. Читать полностью »

image

Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.
Читать полностью »

Никто (почти) не знает, что такое авторизация - 1

За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
Читать полностью »

Как использовать MySQL без пароля (и рисков для безопасности) - 1

Говорят, что лучший пароль — тот, который не надо запоминать. В случае с MySQL это реально благодаря плагину auth_socket и его версии для MariaDB — unix_socket.

Оба эти плагина — вовсе не новы, о них много говорилось в этом же блоге, например в статье о том, как изменять пароли в MySQL 5.7, используя плагин auth_socket. Однако, разбирая, что новенького в MariaDB 10.4, я обнаружил, что unix_socket теперь устанавливается по умолчанию и является одним из методов аутентификации ("одним из", потому как в MariaDB 10.4 одному пользователю для аутентификации доступно больше одного плагина, что и объяснятется в документе "Аутентификация" от MariaDB 10.04).

Читать полностью »

Прим. перев.: В этом замечательном материале компании Okta просто и наглядно рассказывается о принципах работы OAuth и OIDC (OpenID Connect). Эти знания будут полезны разработчикам, системным администраторам и даже «обычным пользователям» популярных веб-приложений, которые скорее всего тоже обмениваются конфиденциальными данными с другими сервисами.

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

Иллюстрированное руководство по OAuth и OpenID Connect - 1
«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*

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

Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).

Иллюстрированное руководство по OAuth и OpenID Connect - 2Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js