Comments 15
Secure Remote Password) — протокол парольной аутентификации, который позволяет пользователю вообще не отправлять пароль на сервер
Не мог понять зачем для этого такой сыр-бор городить. Аутентификация это подтверждение что клиент есть тот за кого он себя выдает, здесь - что он знает пароль. Это можно сделать проще, много вариантов challenge response protocol, не открывающих пароля. Да хоть просто случайный challenge и ответ содержащий крипто-хеш от (challenge+пароль).
Сходив в Вики, понял что это не аутентификация, а аутентифицированный паролем обмен ключом, что всё объясняет.
А чем им стандартный RSP не подошёл, что они свой вариант стали городить?
Вы правы, SRP относится к семейству Challenge Response Protocol.
В стандарте SRP (RFC 5054, который датирован 2007 годом) предусмотрено, например, использование устаревшей SHA1.
Специалисты Proton, по всей вероятности решили сделать свою реализацию более безопасной. Они используют современную SHA-512 и алгоритм Bcrypt, чтобы усложнить подбор.
Вот здесь подробнее об их подходе к реализации протокола.
Что касается варианта со случайным challenge — если я правильно вас понимаю, чтобы сличить хеш ответа, сервер все же должен хранить пароль или хеш.
SRP позволяет ни на каком этапе не показывать пароль серверу, ни во время регистрации, ни дальше. Это отличает его от простых Challenge Response протоколов.
Заметил интересные моменты в алгоритме, может не прав.
2. Сервер в ответ направляет клиенту «закреплённые» за ним параметры:
— модуль
— генератор
— соль
В этот момент Ева (Man-in-the-Middle) может подсунуть клиенту более слабые параметры.
3. Клиентское приложение генерирует приватный ключ a из допустимого диапазона 2, …, N-2 и вычисляет публичный ключ
(A не равно нулю) и отправляет его на сервер.
Тут клиент выполняет вычисления с новым слабым приватным ключом и со слабыми параметрами. Результат отправляет Еве, которая может восстановить этот слабый приватный ключ и пока просто сохранить его.
5. Чтобы убедиться, что ни одну из сторон не подменили в процессе, клиент и сервер обмениваются проверочными значениями.
Сама проверка происходит на пятом шаге. Но если посмотреть внимательнее на все вычисления, то клиент просто проводит всякие хеширования уже со своим паролем и с параметрами, которые установила или знает Ева. Потом результат снова отправляется Еве.
Вроде не критично, т.к. это не сам пароль, а обычный хеш от него, но все равно как-то не очень все выглядит.
Если клиент получит неверное значение N, на шаге сверки проверочных сообщений значения (M и M1) не сойдутся, и сессия оборвется.
В каждом сеансе связи клиент создает новый приватный ключ, поэтому параметр u — а за ним S и M будут каждый раз новые. Сохранять что-то для следующего сеанса нет смысла.
Хеш от пароля не передается. Но даже если бы Ева его получила, восстановить пароль по хешу практически невозможно — Proton использует надежную хеш функцию.
При желании клиент может записать значения N и s, которые использовались при регистрации, и сравнивать их при получении этих данных на 1-2 шагах. Но, видимо, создатели протокола посчитали это избыточным.
Чтобы сократить возможности для атак на сетевом уровне ProtonMail использует SSL Pinning.
Приватный ключ нам нужен только для следующего шага. Попробую объяснить свои мысли на грубом примере:
Ева пропускает через себя весь трафик и ждет идентификатор жертвы.
Если дождалась нужного клиента, отправляет ему, например, N=5 (можно отправлять не такое очевидное число). Т.к. клиент заходит с нового браузера, то не может проверить какие числа были при регистрации. Например, для случая N=5 у клиента небольшой выбор, это выбрать в качестве приватного ключа a=2 или a=3.
Клиент выбрал и отправил Еве публичный ключ, по нему Ева однозначно понимает какой приватный ключ выбрала жертва для текущего сеанса, т.к. остальные параметры для вычисления тоже отправляла ему Ева.
Теперь клиент хочет убедится, что этот сеанс у него с сервером. А Ева ему прислала в ответ еще один слабый параметр B (может быть тоже не таким очевидным).
Клиент вычисляет хеш М1, используя все что получал только от Евы и свой пароль. Потом отправляет этот хеш Еве.
Ева таким образом получила известный хеш от пароля жертвы даже не взламывая БД и вообще не общаясь с сервером ProtonMail.
Теперь Ева ничего не отвечая клиенту, просто разрешает ему начать новую сессию с сервером напрямую и уже не вмешивается.
Сама в это время запускает параллельные переборы на кластере.
Ладно, концовку я нафантазировал, но на самом деле, если есть ресурсы и жертва важна, журналист там или информатор ничего не заметят. Просто куча лишних действий, если твое положение дошло до того, что ты не доверяешь обычному https и хешам в базе, то такая схема тебя тоже не спасет.
Спасибо за пояснение.
Такая атака действительно возможна, и от неё есть защита: сообщение сервера с параметром N подписано долговременным приватным ключом сервера. Клиент проверяет подпись с помощью публичного ключа, который зашит в код клиента. У Евы нет к нему доступа. Это защита от подмены сообщения.
Таким образом пароль защищён даже от теоретической возможности компрометации.
А в чём преимущество над стандартным TLS?
защита от MitM? Кажется, что эта схема не может быть лучше.
защита от слива базы? Эта схема позволяет имея только «серверные» данные узнать, является ли тот или иной пароль правильным. Ну а дальше делается обычный брутфорс, не вижу особенных преимуществ над обычными хорошо солеными хешами.
защита от недоверенного сервера? TLS гарантирует аутентичность, а дальше если хоть какие данные в нешифрованном виде вдруг бывают на недоверенном сервере, то можно их смело считать раскрытыми. Тут только всё шифрование на клиенте выполнять — но про это как раз в конце сказали.
Разве что здесь строго доказано, что брутфорс нельзя облегчить какой-нибудь уязвимостью в алгоритме хеширования. Но стоит ли оно того? Если вдруг злоумышленник получил доступ к базе с паролями, то имеет смысл считать, что все менее защищенные данные уже скомпрометированы. Тут остается только попытаться защитить сам пароль пользователя, но если он вдруг использует один на нескольких сервисах, то надёжность этого пароля определяется надёжностью самого уязвимого сервиса.
TLS и SRP все же не взаимозаменяемые протоколы. Задача TLS обеспечить безопасное соединение, но он не гарантирует, что пересылаемые данные не опасны сами по себе. SRP позволяет клиенту не пересылать опасные данные.
Если присмотреться к спецификации SRP, можно увидеть, что он не призван заменить TLS. Наоборот, его дополняет и усиливает, заменяя собой устаревшие протоколы аутентификации. Собственно ProtonMail использует TLS автоматически при подключении через https.
Прелесть SRP в том, что пароль никогда не попадает на сервер и все вычисления выполняются на клиенте. Обычная парольная аутентификакция предполагает, что хеш не только хранится, но и вычисляется на сервере — то есть в момент регистрации сервер видит пароль. Ни один протокол не защищает от всех видов атак. Конечно, если у злоумышленников есть база с паролями, украденная с менее защищенного сервера, то их задача на этом этапе решена. Тут вы правы.
Но SRP значительно повышает уровень доверия к серверу. Вот, что пишет ProtonMail на эту тему (в вольном переводе):
«Наша основная гипотеза состоит в том, что все серверы могут быть скомпрометированы. Рано или поздно ProtonMail также будет скомпрометирован. Такие инциденты не единичны и постепенно станут нормой в течение следующего десятилетия. Это фундаментальная философия нашей архитектуры с нулевым разглашением. Даже если ProtonMail скомпрометирован и действует злонамеренно, информация, эквивалентная паролю, никогда не раскрывается. Таким образом, с SRP безопасность Proton Mail значительно усилена против MITM-атак».
Таким образом, в конечной группе с умножением обратная операция представляет собой «сложную вычислительную задачу», которую можно решить только самым неэффективным способом — полным перебором всех возможных вариантов n.
Для полей вычетов по простому модулю расширенный алгоритм Эвклида быстро считает обратные значения. Вот, прям только вчера в одной комбинаторной ACM задачке использовал (в комбинаторных ACM задачах часто итоговый ответ надо выразить по модулю простого числа - а тогда деление приходится заменить на умножение на обратное). Для других групп и умножений зачастую тоже есть способы быстрее полного перебора и/или нет доказательства, что таких алгоритмов нет.
Вы правы, для многих задач есть более эффективные способы решения, нежели полный перебор. Для решения задачи дискретного логарифмирования, факторизации и других есть алгоритмы с экспоненциальной и субэкспоненциальной сложностью. Но мы в начале предупредили, что статья не для специалистов, и будут упрощения. Хотелось объяснить основные принципы на простых примерах и сохранить объем статьи в разумных пределах.
Принципиальное решение возможно в децентрализованной архитектуре, где факт владения приватным ключом и есть аутентификация. Никакие параметры не привязаны к профилю в базе данных — ни профиля, ни базы, ни сервера не существует.
если сервера нет, где тогда хранятся письма?
Eppie — работает в одноранговой p2p сети. То есть все подключенные устройства участвуют в хранении и пересылке писем.
Письмо шифруется, разбирается на фрагменты, и отправляется в сеть. Зашифрованные фрагменты хранятся на случайных узлах сети (в том числе на устройствах пользователях). Самый известный пример такой архитектуры — торренты. Но есть и другие технологии, работающие по этому принципу, например IPFS (https://ipfs.tech/).
Дальше получатель письма с помощью своего приватного ключа может скачать фрагменты из сети, восстановить письмо и расшифровать его.
В идеале вся нагрузка по передаче и хранению распределяется между устройствами пользователей. Они и есть инфраструктура. Но на практике, например, мобильные устройства не могут участвовать в этом процессе на равных с десктопами. Поэтому, чтобы компенсировать недостающий для функционирования сети объём хранилища, мы будем запускать служебные ноды (в том числе IPFS) на арендованной инфраструктуре. C технической точки зрения это будут такие же клиенты сети, как любой живой пользователь.
Доказательство с нулевым разглашением на примере реализации SRP в ProtonMail