Главная » Хабрахабр » HL 2018. Конспект доклада «Make passwords great again! Как победить брутфорс и оставить хакеров ни с чем»

HL 2018. Конспект доклада «Make passwords great again! Как победить брутфорс и оставить хакеров ни с чем»


Картинка: источник

Меня зовут Ахмадеев Ринат, я Sr. Привет, Хабр! PHP developer.

Как победить брутфорс и оставить хакеров ни с чем от Алексея Ермишкина из Virgil Security с HighLoad++ 2018. Представляю вашему вниманию конспект доклада Make passwords great again!

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

В самом конце рассматривается новый Simple Password-Hardened Encryption Services (PHE). В докладе рассматриваются способы защиты паролей начиная от хешей и заканчивая более современными подходами, такими как Facebook's password Onion, Sphinx и Pythia.

Всем рекомендую к ознакомлению. Мне так понравился доклад, что я подготовил конспект.

Слайдов в открытом доступе еще нет, поэтому приводится их текстовая расшифровка.

Конспект

Вступление

Я рад всех вас видеть на конференции Highload. Всем здравствуйте, всем доброе утро! Мы занимаемся разработкой различных криптографических продуктов как для индивидуальных разработчиков, так и для бизнеса. Меня зовут Алексей Ермишкин, я работаю в компании Virgil Security. Наши SDK открыты и доступны всем для использования. Фокусируемся на end-to-end решениях, это когда вам не нужно доверять сервису для того что бы выполнять какие-то действия как передача данных, аутентификация, и т.д.

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

Итак, о чем же мы сегодня с вами поговорим?

Когда пароли попадают в ваши БД, после этого пользователь их не контролирует. Я буду рассказывать о защите от offline-атак. Даже если вы как-то пароли защитили, они могут начать их перебирать и им для этого не нужно ни с кем взаимодействовать, у них для этого уже все есть. Если вашу базу данных взломают, она куда-то утечет, то после этого хакеры могут сделать с ней что угодно. Политики паролей конечно вещь полезная, но тоже не всегда удобная, т.е. Так же пользователи не перестают пользоваться слабыми паролями. Так же очевидно, что проблемой является необходимость сравнения того что ввел пользователь с тем что у вас лежит в базе. когда даже люди вводят кажется сильный пароль, политика все равно говорит надо добавить букву или цифру, то для них это не удобно. Ну и не будем забывать, что внутри компании тоже бывают люди, которые не совсем доброжелательные и хотелось бы защититься так же и от них. Как это сделать безопасным образом?

Хеши

Проблема в том, что у пароля маленькая энтропия. В принципе, почему пароли это такая больная тема, почему с ними стоит работать более аккуратно? Это кол-во информации, которая содержится в данных, т.е. Что такое энтропия? Когда сегодня говорят о взломе пароля, говорят что можно за такое-то время взломать пароли с энтропией не больше там или не меньше стольких-то бит. например в слове Highload 8 букв — 8 байт, но если мы посчитаем энтропию, оно будет не 64 бита как все слово, а меньше 30-и бит. даже само кол-во паролей не учитывается. Т.е.

Слайд 1. Хеши

плюсы

— Необратимы

минусы

— Быстро вычисляются

Четыре Nvidia GTX 1080 Ti перебирают около 18 000 000 000 паролей в секунду (SHA-256)
Все пароли с энтропией не более 40 бит переберут приблизительно за 64 секунды.

Первое что пришло в голову — это использовать однонаправленные криптографические хеши. Как же люди начали с безопасностью паролей работать? Т.е. Их замечательная особенность в том, что их нельзя повернуть назад. Но, к сожалению, они очень быстро вычисляются. Если вы в этот хеш передали какую-то информацию, получили на выходе значение, из этого значения обратно эту информацию вы получить не можете. Т.е. Например, современный кластер из 4-х видеокарт NVidia может перебирать несколько миллиардов паролей в секунду. если энтропия вашего пароля меньше 40 бит, то кластер из 4-х видеокарт подберет его там за минуту, а то и того меньше.

Радужные таблицы

Слайд 2. Радужные таблицы

плюсы

— Мгновенный поиск по самым популярным паролям

минусы

— Занимают очень много места

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

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

Соль

Слайд 3. Соль!

плюсы

— Защищает от радужных тиблиц

минусы

— Не защищает от быстрого перебора

Что такое соль? Но опять же на каждую радужную таблицу найдется своя соль. Хранится он в таблице где-то рядом с хешем и защищает от радужных таблиц. Это случайный набор байт, который дописывается к паролю. людям, которые получили к себе в руки базу с посоленными хешами, все равно придется эти хеши вычислять, но проблема в том, что вычисляются эти хеши очень быстро и соль тут особо не помогает. Т.е.

Как замедлить перебор?

Слайд 4. Как замедлить перебор?

Наивный подход:
SHA256(SHA256(SHA256(...)))

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

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

Argon2
image
(картинка взята из WikipediA) Слайд 6.

Он это делает различными способами туда-обратно, память используется очень интенсивно, память используется вся. К примеру самая современная функция Argon2 работает следующим образом: на схеме можно видеть, что есть очень много различных блоков памяти по которым пробегается хеш. Оптимизировать такую функцию (скорость перебора) довольно сложно.

Слайд 7. Password hashing functions

Специально медленные

И на вашем железе тоже!

Простые пароли все равно уязвимы

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

Facebook's password Onion

А можно не нагружать бэкенд? Слайд 8.

Люди задумались над этим и задали вопрос можно ли добиться этих же свойств не нагружая бэкенд, не нагружая собственные сервера?

Слайд 9. Facebook's password Onion

$cur = 'password'
$cur = md5($cur)
$salt = randbytes(20)
$cur = hmac_sha1($cur, $salt)
$cur = remote_hmac_sha256($cur, $secret)
$cur = scrypt($cur, $salt)
$cur = hmac_sha256($cur, $salt)

Archaeological record of FB's struggles
with password security

Эти строчки, которые вы видите, это исторические этапы Facebook, того как они защищали пароли, сначала были просто пароли, потом они взяли старую функцию md5, которая была уже давно взломана, затем они добавили туда соль и взяли хеш sha1, а затем произошла очень интересная штука, они вынесли вычисление функции hmac (это хеш с ключом) на удаленный сервис. Одним из первопроходцев в этом был Facebook.

Слайд 10. Facebook

Hash(salt, password)
[Web service] ---------------------> [Crypto service] <--------------------- ^ HMAC(key, hash) | [key]

Есть бэкенд, есть удаленный сервис. Как это работает? На бэкенд заходит человек, вводит свой пароль. На этом сервисе есть какой-то секретный ключ. Сервис берет свой секретный ключ, вычисляет функцию hmac и отправляет это все обратно. Этот пароль смешивается с солью, которая лежит в базе, прогоняется через хеш и отправляется на сервис. На бэкенде оно кладется в базу.

Слайд 11. Facebook

плюсы
— Защита от перебора

минусы
— Один ключ навсегда

Если у Facebook сопрут базу пользователей, то перебирать пароли в ней смысла никакого нет, потому что у них нет удаленного секретного ключа. Что это дает? Они не смогут ничего с этим сделать, потому что используют хеши, используют hmac. Но проблема подхода Facebook в том, если что-то случится с их удаленным секретным ключом, то они окажутся в большой беде. У них нет способов как-то эту ситуацию разрулить так, что бы пользователи ничего не заметили и они этим загнали себя собственно в угол.

Sphinx

А можно лучше? Слайд 12.

Им идея использования удаленных сервисов понравилась и они решили подумать: можно ли сделать еще лучше? Криптографы на все это дело посмотрели. Можно ли сделать похожую систему, но без минусов, которыми ее наделил Facebook?

Слайд 13. Пароль — число?

p a s s w 0 r d
112 97 115 115 119 48 114 100

Число — 8 097 880 544 746 959 460

Если у нас есть слово passw0rd, оно состоит из 8-ми байт. И решили подойти следующим образом к этой проблеме: что если пароль или хеш от пароля представить представить в виде числа? в принципе это одно и то же. Во всех почти языках программирования есть целочисленные типы восьми байтовые, т.е. 8 байт, слово passw0rd и мы можем представить его в виде обычного десятичного числа. Т.е. Это нам дает совершенно иную свободу действий. Что это нам дает? Мы можем выполнять с ними настоящие серьезные математические операции. Мы можем пароли или хеши от них складывать, умножать, превращать в какие-то другие числа.

Sphinx — "менеджер" паролей Слайд 14.

Она появилась пару лет назад. Одна из первых систем которая использовала эту технологию это Sphinx. Есть много разных программ типа keepass, где у вас есть master-пароль и для каждого сайта он генерирует случайный. Это детерминированный менеджер паролей. Но понятно, если этот мастер пароль куда-то уйдет, то все пароли от ваших сайтов будут навсегда скомпрометированы. Но так же есть детерминированные такие вещи, где вы вводите свой мастер-пароль, сайт, на который хотите зайти и он там что-то вычисляет и выдает уникальный пароль для каждого сайта.

Слайд 15. Sphinx — «менеджер» паролей

[ домен ] | \ /
[ мастер-пароль ] -> [ хеш ] -> [ число a ]

Он берет мастер пароль, он берет домен, на который вы хотите зайти, прогоняет все это дело через хеш и превращает в число. Как подошел к этой проблеме Sphinx? Он превращает это в число (назовем его a) и что же он делает дальше? А на самом деле там используется эллиптическая криптография, для простоты я буду все это объяснять на обычных числах с обычной математикой.

Слайд 16. Sphinx — «менеджер» паролей

Маскировка!

[ a ^ (r*1/r) = a ] r - большое случайное
число

Если возведем число a в степень r, а когда-то потом возведем это число в степень обратную числу r, то мы получим обратно это же число a, да? Совершенно замечательная вещь, мы каждый раз можем генерировать большое случайное число r. мы можем с начала замаскировать что-то, а потом демаскировать. Т.е.

Слайд 17. Sphinx — «менеджер» паролей

[] PRIVATE KEY (b) | a^r \ /
USER ----------------------------------------> SPHINX SERVICE | <---------------------------------------- \ / a^(r*b)
a ^ (r * b * 1 / r) = a^b -------------------> Jyiw19O2b5gXJi

Опять же есть пользователь, есть удаленный сервис. И что делает сфинкс? На удаленном сервисе и есть приватный ключ b. На этот удаленный сервис отправляется замаскированное число. Он присланное число a^r домножает на свой секретный ключ b и отправляет обратно. Что он делает? По скольку число r каждый раз разное, то удаленный сервис ничего не может сказать о том, какой пароль и домен были замаскированы, т.е. (Примечание автора конспекта: на слайде присланное число не домножается на приватный ключ, а возводится в степень приватного ключа, но тут главное суть). И он домножает просто на свой приватный ключ b и отправляет обратно. он каждый раз видит какие-то разные случайные числа. Получается секретный ключ сервера он не знает, сервер не знает то, что ему прислал пользователь, но в итоге у него получается тоже какое-то детерминированное число. Пользователь демаскирует то, что прислал ему сервер и у него получается число — его мастер пароль с доменом умноженный на секретный ключ сервера a^b. Каждый раз выполняя этот протокол маскировка будет разная, но результат будет всегда одинаковый и этот результат можно будет потом превратить обратно в какой-то пароль и использовать для входа на различные сайты.

Слайд 18. Sphinx — «менеджер» паролей

плюсы
— Защита от перебора
— Пароли не зависимы друг от друга
— Кража мастер-пароля ничего не дает
— Скорость

минусы
— Сервер не знает, кто к нему обращается
— Клиент не знает, кто ему отвечает
— Секретный ключ все еще статический

Во первых можно генерировать большие пароли, т.е. По истине замечательная технология. Во вторых если хакер получит доступ к нескольким паролям, он ничего не сможет сказать об остальных, т.к. она защищает от перебора. В третьих, если у пользователя уплывет куда-то его мастер пароль, то это тоже ничего не даст, потому что у хакеров не будет секретного ключа. они генерируются независимо друг от друга. здесь не нужно никаких итеративных больших хеширований, т.е. В четвертых это работает очень быстро, т.к. выполняется буквально 2-3 умножения и все работает мгновенно.

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

Pythia

1. Слайд 19. А можно лучше?

А можно лучше?

2. Слайд 19. END-TO-END!

Т.е. На эту систему посмотрели криптографы и подумали, а можно ли систему еще усовершенствовать и дополнить ее свойствами, которые бы позволили сказать о том что она соответствует принципам end-to-end? клиент может общаться с сервером, но при этом он так же может его аутентифицировать и может ему в какой-то степени доверять.

Pythia Слайд 20.

И придумали такой протокол, который называется Pythia.

Слайд 21. Pythia

Adam Everspaugh et al.

Сервис знает, кто «вводит пароль»

Может доказать, что это — он

Чем он уникален? Его сделал замечательный человек Adam Everspaugh со своими коллегами. на сервер по мимо пароля передается идентификатор пользователя. Во первых сервис знает, кто вводит пароль, т.е. Не важно. Это может быть какая-то случайная id-шка, которая лежит рядом с ним, или просто user name. Но мало этого сервер не просто знает, он может строго математически доказать, что он это он. Но сервис об этом знает.

Слайд 22. Pythia

[] Public key [] Private key (k) | | \ / UserID, a^r \ / [BACKEND] ----------------------------> [PYTHIA SERVICE] | <---------------------------- | (UserID, a)^(r*k) + Proof \ /
(UserID, a)^(r*k*1/r) = (UserID, a)^k = y ------------------> [ DATABASE ]

Есть бэкенд (какой-то веб сервис, сайт) и есть сервис Pythia. Как это работает? На сервисе есть приватный ключ k, но на бэкенд он так же передает свой публичный ключ. Что делает бэкенд и что делает сервис? Сервис домножает идентификатор пользователя и пароль на свой секретный ключ и результат (UserID, a)^(r*k) отправляет бэкенду. Бэкенд на сервис отправляет не только замаскированное число a^r, как в протоколе Sphinx, но так же отправляет какой-то идентификатор пользователя (UserID). Затем происходит демаскировка и число y которое получается в итоге кладется в БД. Так же он отправляет в ответ некий Proof, который может использоваться бэкендом для проверки сервера, что его не взломали, что он отвечает так как должен. В базе данных у нас лежит не просто какой-то хеш, а лежит число, точка эллиптической кривой.

Слайд 23. Pythia

(UserID, a) — билинейная операция e(a^x, b^y) = e(a, b)^(x*y)

Schnoorr NIZK proof w/ Fiat-Shamir transformation.
Доказывает, что DL(g^x) == DL((UserID, a)^x)
g^x — Публичный ключ

Schnorr protocol

Здесь есть несколько интересных моментов:

  • Возможность для сервера комбинировать пользовательский идентификатор и пароль в одно число. Называется это билинейная операция или билинейное спаривание. Это сравнительно новая математика, которую не так давно начали использовать. У нее есть все свойства новых математик в том что не прошло еще 30и лет для того, что бы все убедились в том что все с этим нормально.
  • Зато Proof, который отправляет сервис — это довольно старая технология. Это называется протокол Шнорра. Генерация публичного ключа — это умножение базовой точки на какой-то секретный ключ. Протокол Шнорра доказывает, что тот секретный ключ, который использовался для генерации публичного ключа, вот он же и использовался для того что бы умножить пароль пользователя тоже на это же самое число. Этот протокол уже давным давно есть, он используется много где и он позволяет доказать. Это называется доказательство с нулевым разглашением — сервер свой публичный ключ не показывает, но при этом говорит, что ту операцию которую я выполнил, она была произведена именно тем приватным ключом, о котором мы изначально договаривались.

Слайд 24. Плюсы Pythia

— Не нагружает бэкенд
— Защита от перебора
— Сервис может блокировать попытки перебора (UserID)
— Сервис ничего не знает о пароле (blinding)
— Клиент уверен, что ему ответил конкретный сервис (ZKP)
— Бесшовная миграция с существующих решений

А их у нее не много. Какие у этой системы есть плюсы?

  • Система не нагружает бэкенд. Потому что бэкенд все что делает — это превращает пароль в число, маскирует его, отправляет, потом демаскирует так же результат.
  • Если базу с такими числами у вас украдут, то перебирать пароли тоже смысла никакого нет без приватного ключа.
  • Сервис Pythia может блокировать попытки перебора, а значит бэкенду этим в принципе не надо заниматься. Если он видит, что под одним и тем же идентификатором пользователя пытаются выполнить эту операцию трансформации несколько раз, он может просто по rate лимиту это все отсечь и заблокировать.
  • Благодаря маскировке сервис ничего не знает о пароле. Каждый раз ему присылается новое какое-то случайное число. Константой остается только идентификатор пользователя.
  • Благодаря ZKP (Zero-knowledge proof) бэкенд всегда знает, что ему ответил именно тот самый сервис, к которому он когда-то изначально обратился.
  • Если у вас есть база с хешами и с солью например, то вы можете мигрировать на такое решение бесшовно для пользователей. Они даже могут ничего не заметить. Вы вместо пароля пользователя берете его хеш, загоняете его в Pythia и в дальнейшем просто используете этот протокол, получаете число y, кладете опять его в свою базу. Хеш после этого можно удалить. Каждый раз когда пользователь будет заходить в вашу систему, будет выполняться этот протокол, будет получаться в результате какое-то число, которое вы сравните с тем, что в базе. Собственно система аутентификации останется неизменной, т.к. пользователи будут как логинились раньше, так и логиниться, с теми же самыми паролями, даже слабыми. При этом система будет гораздо более защищенной.

Слайд 25. Это ещё не всё

— Можно менять секретный ключ!
— Старый ключ — число k, новый k'
— Update token Δ = k' * 1 / k
— Для каждой записи y' = y * Δ

— Защита от кражи как базы, так и секретного ключа!
— Бесшовное обновление данных в БД
— Мгновенная инвалидация данных базы паролей

Одной из главных фич является то, что даже если взломают сам сервис Pythia, то можно сгенерировать новый приватный ключ. Но это не все плюшки. Если мы представим старый ключ как число k, а новый как число k', то мы можем вычислить число, которое называется Update token. У нас же в базе хранится число, а не хеш. И вот этим вот update токеном можно пройтись по базе по каждому пользователю и умножить это число y на update token. Для этого мы умножаем новое число на число обратное старому. Это все происходит мгновенно. После того, как вы это сделали, у вас система продолжает работать уже с новым приватным ключом на удаленном сервисе. Вы просто потихонечку у себя проходитесь в фоновом режиме по всем записям, обновляете их и у вас они работают с новым секретным ключом. Если случилась беда, у вас украли вашу базу данных с паролями, вы по щелчку пальца выпускаете update token и то, что украли у вас хакеры, становится мгновенно бесполезным. Т.е. Пользователи вообще даже ничего не замечают. бесшовное обновление и мгновенная инвалидация базы паролей, это вот одни из ключевых инновационных функций этой системы.

Слайд 26. Бонус

[BrainKey]Y можно использовать для генерации ключа!
— Цифровая подпись
— Восстановление аккаунта
— Бэкапы
— etc.

Число, которое лежит в базе, большое y, оно в принципе большое и выглядит довольно псевдослучайно, т.е. Но и это еще не все. Если мы вот тот функционал, который у нас есть на бэкенде, перенесем, например, на клиентские устройства, на телефоны, то мы можем использовать вот этот y для генерации ключей. его так просто не подобрать. Значит, пользователь вводит пароль у себя где-то на телефоне, так же его маскирует, отправляет на удаленный сервис. Мы называли эту штуку BrainKey. Таким образом пользователь из своего пароля может получить ключевую пару. Сервис возвращает ему какое-то число y и можно потом этот y использовать для генерации уже каких-то асимметричных ключей. Это когда вы вводите пароль и получаете сгенерированный для него биткоин кошелек. Это используется во всяких BrainWallet-ах. везде, где используется асимметричная криптография, где нужны асимметричные ключи. Но не только криптовалютами ограничивается это применение, это и цифровая подпись, и какие-то бэкапы, и восстановление аккаунта, т.е. Значит они все будут зависеть от пароля пользователя, и это очень удобно. Все это можно использовать, но при этом ключевая пара, а их, в зависимости от необходимости, можно генерировать сколько угодно.

Слайд 27. Минусы?

— Новая математика (BLS12-381, ZCASH)
— Мало библиотек
— Скорость не совсем highload

VirgilSecurity.com
Зато уже в Production!
Pythia.

И особенности этой технологии в том, что она очень новая. В бочке меда как бы не без ложечки дегтя. Сама математика уже существует некоторое время, но вот эта конкретно кривая, которая используется в частности в нашей имплементации, она кроме нас используется только в ZCash-е. В ней используется эллиптическая кривая, которая для билинейных операций. Что бы вывести это в production состояние, нужно потратить какое-то кол-во времени и сил. Соответственно библиотек, которые используют эту новую математику можно пересчитать по пальцам одной руки. Как следствие первых двух свойств, скорость этих билинейных операций не очень соответствует той современной математике, эллиптической в частности, которую мы сейчас все используем, когда используем протокол TLS, когда используем какие-то сайты. Но тем не менее индустрия не стоит на месте и все эти минусы временные. На самом деле нас это не остановило и мы весной заимплементировали этот протокол, выпустили его в production и перевели все наши записи, защитили их с помощью этого протокола. Это где-то несколько сотен операций на сервисе на одно ядро. Нас в принципе устраивает для наших текущих задач производительность, если будет нужно, мы поднимем еще одну ноду с сервисом Pythia и в принципе со всем этим уже можно поиграть.

PHE

А можно еще лучше? Слайд 28.

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

Слайд 29. Simple Password-Hardened Encryption Services (PHE)

. . . / [ ][ ][ ] [] _
Russell Lai et al. Nist P-256 / Июль 2018 Скорость ~10x Pythia

Это Russell Lai, ученый из Европы. И буквально в июле этого года ученые выпустили новый протокол, который называется Simple Password-Hardened Encryption Services или сокращенно PHE.

Во первых он использует стандартную кривую P-256, которая используется везде, во всех браузерах, продуктах, везде кривая по-умолчанию, которой уже много лет. В чем преимущество этого сервиса? Её как бы сложно, но можно имплементировать собственными руками, не используя какие-то библиотеки непонятные. Во вторых эта штука работает примерно раз в 10 быстрее чем Pythia и использует стандартные примитивы. Можно использовать OpenSSL, или Bouncy Castle, что угодно.

Слайд 30. Simple Password-Hardened Encryption Services (PHE)

[] PUBLIC KEY Enroll? [] PRIVATE KEY (y)
[ [] ] -------------------------> [ [] ] [ BACKEND ] <------------------------- [ PHE SERVICE ] [] PRIVATE KEY (x) sNonce, C0, C1, Proof C0, C1 - точки С0 = y * (sNonce, "0") C1 = y * (sNonce, "1") HC0 = x * (cNonce, password, "0") T0 = C0 + HC0 [ DATABASE: ] HC1 = x * (cNonce, password, "1") T1 = C1 + HC1 + MC [ T0, T1, sNonce, cNonce ] M = random, MC = x * M

Опять же есть бэкенд, есть сервис PHE. Но работает она немножко по другому. В отличии от Pythia, процесс регистрации и процесс проверки пароля проходит немножко по-разному. На бэкенде есть публичный ключ, на сервисе есть приватный ключ y. С начала он спрашивает у PHE-сервиса дай мне пожалуйста некоторые данные, которые я могу использовать для регистрации, какую-то Enrollment-запись. Когда на сервис приходит новый пользователь и хочет зарегистрироваться, что делает бэкенд? Он генерирует некую случайную 32-х байтную соль (sNonce). Сервис говорит OK и отвечает бэкенду следующими штуками. Так же он генерирует доказательства (Proof) того что эти два числа или там 2 точки были сгенерированы именно с использованием его приватного ключа y, используя протокол Шнорра (как в предыдущих протоколах). На основе этой соли и своего приватного ключа y он генерирует два числа, назовем их C0 и C1. Пароля здесь пока еще нет. Бэкенд проверяет Proof. У него со своей стороны тоже есть свой личный клиентский приватный ключ x и он, получив пароль от пользователя, делает примерно те же самое что делал сервис, только добавляет туда еще пароль. Что делает бэкенд? Зачем 2? Он берет случайный cNonce (случайную клиентскую соль), пароль и генерирует опять 2 числа HC0 и HC1. Число M размером тоже 32 байта и в последствии может использоваться для шифрования пользовательских данных (у нас же Encryption Services) (примечание автора конспекта: ключ шифрования в данном случае будет MC). Потому что первое HC0 используется для аутентификации, а во второе число HC1 у нас подмешивается еще некое случайное число M домноженное на приватный ключ x (MC). Получается на этапе регистрации вы можете сгенерировать не только запись для авторизации, но и ключ шифрования, уникальный для каждого пользователя, которым можно зашифровать его профиль, какие-то данные, еще что-то. Число MC будет доступно в качестве ключа только после того, как пользователь ввел правильный пароль. В первом случае складывает две (C0 + HC0), а во втором три (C1 + HC1 + MC). Затем бэкенд просто складывает то что прислал сервис и то что сделал он — складывает эти точки и получает T0 и T1. И кладет в базу 2 соли (sNonce, cNonce), с помощью которых были получены эти числа и 2 числа (T0 и T1), которые получились в результате суммы.

Слайд 31. PHE Login

C0, sNonce [] PRIVATE KEY (y)
[ [] ] -------------------------> [ [] ] [ BACKEND ] <------------------------- [ PHE SERVICE ] [] PRIVATE KEY (x) C1, Proof
HC0 = x * (cNonce, password, "0") С0 == y * (sNonce, "0")?
C0 = T0 - HC0 HC1 = x * (cNonce, password, "1")
MC = T1 - C1 - HC1 [ MC - ключ шифрования! ]

Пользователь вводит свой пароль на бэкенде. Соответственно процесс аутентификации пользователя происходит в обратном порядке. Сервис, зная серверную соль, вычисляет у себя эту же самую точку и смотрит, она совпадает с тем что прислал бэкенд или нет, если она совпадает, то значит пароль верный и можно ответить ему вторым числом C1, которое он вычтет вместе с HC1 из числа T1 и получит ключ шифрования. Бэкенд вычисляет HC0 и из того, что у него лежит в базе, вычитает HC0 из T0 и отправляет получившееся C0 на сервис вместе с серверной солью. Он даже не покидает бэкенд. Таким образом пароль на сервис PHE даже не уходит. Он даже не существует как таковой, но при этом удаленный сервис может сделать строгий вывод о том корректный или нет этот пароль и доказать еще по мимо этого то, что он все вычисления провел с помощью своего приватного ключа y. Он в виде каких-то точек умноженных на приватный ключ бэкенда.

Слайд 32. Особенности PHE

  • Пароль не покидает бэкенд!
  • Нужен приватный ключ на клиенте
  • Все основные функции Pythia:
    • Защита от перебора
    • Сервис PHE ничего не знает о пароле
    • Строгие доказательства правильности / неправильности пароля
    • Возможность обновлять базу и ключи

Пароль как я уже говорил не покидает бэкенд. Какие у этой системы есть особенности? Ну нужен и нужен, сохраним куда-нибудь. Но в отличии от Pythia нужен приватный ключ на бэкенде. PHE обладает всеми основными функциями Pythia:

  • можно так же выпустить update token если у вас что-то случилось с приватным ключом;
  • можно так же пройтись по всей базе, обновить и все будет как и было;
  • защита от перебора;
  • сервис ничего не знает о пароле;
  • строгие доказательства (Pythia вот, кстати, не знает, пароль правильный не правильный, а PHE знает);
  • возможность обновлять базу и ключи.

Представляем Слайд 33.

И нам так понравилась эта штука...

Слайд 34. passw0rd.io

[] [] [] Бесплатный CLI для основных Open-source
сервис PHE операций SDK

Буквально вот ребята ночью его доделывали. … что мы взяли и запилили сервис. Во первых слово password с ноликом, это вот самый 18-й по популярности пароль в мире среди всех паролей, во вторых нолик символизирует, то что это zero trust, т.е. Называется он passw0rd.io с ноликом. Так же это бесплатный сервис, абсолютно, т.е. сервису можно не доверять. Можно прийти, зарегистрироваться и пользоваться. как Let's encrypt. Мы на сегодняшний день успели выпустить 2 SDK, это GO и . У него есть CLI для основных операций для регистрации, для создания приложений. Net, которые работают с этим сервисом.

Слайд 35. PASSWORDS are like UNDERWEAR

1. Change them regularly
2. Don't leave them on your desk
3. Don't loan them to anyone

Ну и напоследок хочется сказать что пароли это как нижнее белье:

  1. Стоит их регулярно менять.
  2. Не стоит их оставлять на столе.
  3. Не надо их никому отдавать.

На этом у меня все, я благодарю вас за внимание и спасибо за то что пришли на доклад.

ВОПРОСЫ?

ВОПРОСЫ? Слайд 37.

Возможно у вас есть вопросы.

Такой небольшой вопрос. Q: Здравствуйте, большое спасибо за доклад! Потому что мы не будем знать какой private key он использовал. Если у нас есть злоумышленник, который получил доступ к сервису Pythia и используя те данные выпустит свой update token, то у нас не потеряются абсолютно все пароли? Или нет?
A: Да, update token-ы можно обновлять сколько угодно раз.
Q: Тогда собственно другой вопрос. Сможем ли мы их восстановить используя еще один update token? И если это сделает злоумышленник, т.е. Если этот злоумышленник остается с каким-то снифером в нашей сети и слушает новые update token-ы, то он может бесконечно обновлять свой Private key и мы никогда не сможем защитить от него базу?
A: Нет, ну процесс выпуска update token-ов, он как бы не автоматический, если что-то случается, происходит нотификация всех, нас взломали, мы будем выпускать update token. тут есть возможность ручного управления. разошлет всем почту.
Q: Нет, спасибо, если он не автоматически, то все понятно.
A: Т.е.

Т.е. Q: Здравствуйте, у меня вопрос, там вы говорили бесшовно мигрировать, если у вас используется какой-то хеш в Pythia и что-то я не очень понимаю, если у нас есть миллион сессий активных, соответственно бэкенд не знает пароли, мы можем бесшовно?
A: Да конечно.
Q: Мы заставим их заново вводить пароли?
A: Нет, мы просто вместо паролей в Pythia будем передавать хеш. вы оставляете у себя соль, но когда пользователь логинится вы вычисляете опять хеш.
Q: (Не разборчиво) Так bcrypt все равно придется вычислять на бэкенде?
A: Хеш, который был у вас в базе, его придется вычислять, ну это не абы какая сложность.

Какой пароль самый популярный все таки? Q: Доброе утро, у меня фанские вопросы. Огонь! Раз тот, который…
A: password без нуля
Q: password без нуля? И вот минусы Pythia были отмечены, минусы PHE я не увидел.
A: А мы не нашли, мы собственно по этому как бы и закончили на этом доклад.
Q: Понятно. Вообще.
A: 123456 еще вот тоже, там в зависимости от года они там 12345, 123456.
Q: Хорошо. Вот сейчас кроме вас кто вообще использует такие штуки? И третий вопрос. А! В production для своих сервисов?
A: Никто пока. Яндекс использует Pythia.
Q: Яндекс использует Pythia, а он для чего, известно?
A: Для паролей.
Q: В каких сервисах, во всех?
A: Понятия не имею.
Q: Ок, понятно, спасибо!
A: Но они не выпустили SDK, и не показали это никому.

там настраивается какое-то количество попыток, после которого замедляется подбор паролей? Q: Здравствуйте, вот скажите, вы говорили, что исключается возможность подбора пароля, т.е. Перестает отвечать или как?
A: Нет, ну это настраивается же, в зависимости от потребности, т.е. И сервис что делает? Главное преимущество в том, что вы можете регулировать это. сейчас у нас например на сервисе PHE, который мы недавно подняли, там то ли 5 паролей в 2 секунды, то ли 2 пароля в 5 секунд можно. вы помимо этого еще используете какие-то метрики, что бы словить алерты и какие-то действия предпринимать? Можно например для PHE (он знает, что пароль ввели неправильно), если ввели неправильный пароль, то сделать блок на 10 секунд, или там на минуту.
Q: Т.е. Сейчас пока сделан просто rate limiting, а в принципе, в дальнейшем мы внедрим туда политики и вы сами сможете настраивать как реагировать на эти события.
Q: Т.е. Подразумевается ли такое?
A: Это можно сделать. момент подбора пароля к разным аккаунтам или к одному будет обнаружен таким образом, да?
A: Да.

Подскажите, т.е. Q: Здравствуйте. Подобрать?
A: Да, но проблема в том, что это надо сделать одновременно.
Q: До того, как выйдет update на вашу базу?
A: Да, если мы рассматриваем Pythia как сервис, который не стоит у вас же в вашей инфраструктуре, а какой-то другой удаленный сервис в какой-то другой компании, например у нас, то нужно будет взломать одновременно вас и нас, ну это как бы удачи) в итоге если украдут ключ с Pythia и украдут вашу базу паролей (хешей), то пароли я так понимаю все равно можно будет забрутфорсить, да?

Спасибо всем большое! A: Все? У нас еще есть квест, кстати, на тему PHE, можно побрутфорсить хеши, приходите. Надеюсь вам понравилось.

Выводы

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

Тем не менее плюсы все же выглядят довольно вкусно:

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

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

Спасибо Алексею Ермишкину и компании Virgil Security за то, что исследуете эту тему, делитесь информацией и публикуете исходные коды!

А как вы защищаете пароли (если не секрет)?


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Киберпреступники пять месяцев контролировали ASUS Live Update

Злоумышленники разместили на сервере вредоносный файл с бэкдором, подписанный валидным сертификатом ASUS. Как сообщает «Лаборатория Касперского», хакеры из APT-группировки ShadowHammer 5 месяцев контролировали сервис обновлений ASUS Live Update и заразили более полумиллиона компьютеров по всему миру.Исследователи из «Лаборатории Касперского» обнаружили, ...

Kubernetes 1.14: обзор основных новшеств

14. Этой ночью состоится очередной релиз Kubernetes — 1. По сложившейся для нашего блога традиции, рассказываем о ключевых изменениях в новой версии этого замечательного Open Source-продукта. 14 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP). Информация, использованная для подготовки ...