В начале июня сотрудник компании Sakurity Егор Хомяков (Egor Homakov) написал пост о созданной им технологии SecureLogin, являющейся заменой парольной аутентификации. Несмотря на то что Егор наверняка прекрасно говорит и пишет по-русски, мы не смогли найти русскоязычного варианта и решили сделать перевод оригинальной статьи. Результат вы можете найти под катом. Сегодня я с гордостью представляю SecureLogin Authentication Protocol 1.0, над которым работал последние 3 года. Как насчет демки? Легко! Нет, это не менеджер паролей. Да, это очередная попытка заменить пароли, причем для всех, а не только для гиков. Кстати, я горжусь не нативными приложениями и реализациями  —  это была лишь небольшая часть работы, объем которой не превышает нескольких тысяч строк кода. 
Я горжусь тем, что разработал наиболее сбалансированный протокол, который, как специалист по безопасности, искренне рекомендую. Этот баланс основывается на 3 принципах. Никакая третья сторона не должна иметь возможность войти в вашу учетную запись откуда бы то ни было: ни провайдер телефонной связи, сливающий ваши SMS-коды, ни провайдер электронной почты, сбрасывающий ваши пароли, ни Facebook Connect/Google OAuth, выдающий ваш access_token кому-то другому, ни правительства и хакеры, тем или иным способом делающие это через вышеперечисленные сервисы. Только ваше личное устройство должно иметь возможность удостоверять запросы для вашей учетной записи. На первый взгляд более привлекательные «2FA как сервис»-провайдеры, такие как Authy или Duo, не подпадают под определение end-2-end-децентрализованных, поскольку представляют из себя централизованные службы, подтверждающие запросы от имени пользователя. По большому счету это альтернативная реализация механизма «подтверждение по ссылке в email». В настоящий момент добиться действительно безопасной аутентификации можно с помощью TOTP (например, Google Authenticator) или USB-ключа типа U2F. Оба подхода требуют ручных манипуляций, поэтому их почти никто не использует. Работать с ними очень неудобно. В первом случае приходится записывать резервные коды на бумаге (что я никогда не делал), а второй вариант мало кем поддерживается. Поэтому их уровень проникновения крайне мал. Пришло время поговорить о втором принципе, на котором основан SecureLogin. Демонстрация пользовательского интерфейса десктопного и мобильного приложений Это очень похоже на Facebook Connect (исключая зависимость от серверов Facebook): вы нажимаете кнопку Login, приложение открывается, вы подтверждаете запрос, и это все. Никакой возни с аппаратными ключами, одноразовыми паролями, ожидания электронных писем или SMS, доставания телефона из кармана, сканирования QR-кодов и т. д. Это настолько просто, насколько вообще возможно для аутентификации. Для соответствия этому принципу SecureLogin сделан детерминированным и реализован на программной основе. Он готов к обслуживанию четырех миллиардов людей уже завтра утром, и не существует единой точки отказа, которая могла бы этому помешать. О резервных копиях беспокоиться не стоит, так как их не существует: ваш закрытый ключ генерируется на основе вашего же мастер-пароля. Серверы SecureLogin не смогут испортить production-базу, так как этой базы не существует. Система работает в автономном режиме (offline). Никакого аппаратного обеспечения покупать не нужно. Написаны приложения для iOS, Android, macOS, Windows, Linux, и при этом вы всегда можете воспользоваться веб-клиентом. Протокол полностью свободен (entirely free), и код всех клиентов открыт. За использование системы никогда ничего не придется платить. API протокола настолько прост, что даже нет необходимости в SDK-библиотеках: 20 строк JS-кода на клиенте, 50 строк на сервере. Если вы ищете идею для open-source-проекта, рассмотрите реализацию SecureLogin-плагина для вашей любимой CMS. Напишите мне письмо, чтобы присоединиться к нашему Slack. Кстати, первопроходцы SecureLogin могут получить бесплатный аудит безопасности. Буду рад ответить на них в Twitter! Но сначала поищите ответ в FAQ — 90% вопросов повторяют друг друга. Прошу заметить, что SecureLogin не задумывался как самое безопасное решение, которое покрывало бы все граничные случаи (однако для версии 2.0 планируется функциональность Doublesign), или самое комфортное решение (тут вряд ли удастся переплюнуть Facebook Connect — он слишком удобен). Здесь весь смысл в балансе. Ссылки: CEO в Southbridge