SRP-6: аутентификация без передачи пароля

[Zaharov]

Спасибо за статью!
Как раз подумываю применить SRP в одном проекте. Как думаете, возможна ли такая схема работы:
Веб-приложение общается с сервером практически целиком через JSON, т.к. после аутентификации у сервера и клиента будет общий ключ K, то мы будем его использовать для шифрования JSON'а, чем обеспечим и аутентификацию и безопасность обмена данными.
Или это уже извращение?

[datacompboy]

А зачем нужно? Это фактически замена SSL с ключами на SSL с паролем :) Может, стоит на ключи таки поглядет?

[Zaharov]

В основном просто интересно. :)
Плюс к тому же раз уж у нас при применении SRP всё равно получается ключик, то почему бы его не использовать? Да и с сертификатами возиться не хочется…

[datacompboy]

Единственная проблема — скорость шифрования.
Ради интересу советую на JS закодировать/раскодировать простенький запрос на 15-20К текста…

[Zaharov]

Наверно вы правы.
Но тогда получается если мы будем HTTPS использовать для всего, то разумно и регистрацию через него же проводить, а значит SRP можно и не применять.

[datacompboy]

SRP имеет смысл оставить для защиты от утечки паролей при взломе бд.

[Zaharov]

Любой уважающий себя проект уже давно не хранит пароли в открытом виде, на мой взгляд это самая банальная и первичная мера безопасности.
Забудем на минутку о Sony. :)

[datacompboy]

Хранение просто хеша от пароля тоже не радостный вариант, разве что солёный.
Я лично не раз использовал md5(pass) из чужой бд для получения pass :)

И еще один момент — SRP позволят аутентифицировать пользователя безопасно и просто, в то время как SSL требует для этого сертификаты (во всяком случае, пока OpenSSL+SRP не используются браузерами).

То есть я за выбор SRP+SSL с Fallback до простой формы логина (поверх всё того же SSL) если требуется.

[akalend]

даже имея хеш пароля — легко залогинится
(имея косвенный доступ к исходникам)

в данном случае, гарантией является сессионный ключ

[datacompboy]

SSL, реализованный в сильно оптимизированном C коде меньше нагрузит сервер, чем ручное кодирование на скриптовом языке.

[nekt]

В теории при использовании простой key-value базы на серере и толстого клиента на стороне пользователя, на сервер можно засылать шифрованные данные и не париться на сервере с их расшифровкой.

[datacompboy]

Это мы рассматриваем клинический случай, когда от сервера осталась только база, да еще и по которой не требуется даже поиска делать?

[nekt]

Именно так :)

[TiGR]

SRP JavaScript Demo, как кажется отрабатывает практически мгновенно, даже при выборе 1024 бит. Я ожидал больших тормозов. Или там какое-то не полноценное демо?

И да, спасибо, что опубликовали этот материал.

[datacompboy]

Сильно ускорились JS движки + поддержка Binary в последних версиях, без которых всё было очень и очень тоскливо.

[datacompboy]

И да, еще сильно зависит от хеш-функции. SHA-512 работает ощутимо медленнее чем SHA1

[JLarky]

А мне вот не удалось проверить. Оказывается в Google Chrome есть клёвая бага, которой уже почти 3 года.
code.google.com/p/chromium/issues/detail?id=580

[TiGR]

А при чём тут Java? Там же первый пример без явы, только на js.

[JLarky]

я говорю про srp.stanford.edu/demo/demo.html там ничего не работает под предлогом этого бага.

[tzlom]

так вот зачем нужен Native Client

[datacompboy]

NC нужен за любой сложной логикой на стороне клиента. JS всё-таки убоговат всё еще по скорости.

[tzlom]

хм, я бы не был столь категоричен
bellard.org/jslinux/

[datacompboy]

Я видел это, потому и говорю «убоговат» а не «совсем убог» :) Всё-таки, это еще не совсем «оно». По сравнению с нативным кодом отстаёт на несколько десятичных порядков.

[akalend]

Спасибо за информацию, нашел ее очень полезной
хотелось бы протестировать поближе к практике:
на реальных цифрах, чтоб JS не тормозил

что посоветуете?

[datacompboy]

Судя по всему, сейчас оно не так сильно и тормозит, всё-таки компы шустрее стали и js движки тоже.
Стоит просто взять и попробовать. Оптимальным будет килобит и SHA256.
Если будут тормоза — тогда уже посмотреть на полкилобита и SHA224.
Опускаться ниже полукилобита не имеет смысла из соображений безопасности.

[Holms]

Спасибо за статью, как раз искал что-то в этом роде.
Вроде всё понятно кроме одного момента, правильно ли я понимаю что N генериться один раз, и пишется куда-то как константа, и потом используется при регистрации и аутентикации пользователей?

Если генерить N при каждой новой регистрации и потом для каждой новой аутентикации то у меня никак не получается получить тот-же K но обеих сторонах.

Поясните пожалуйста что делать с N.
Спасибо

[datacompboy]

g и N выбираются и используются в течение всей коммуникации — это выбор поля, на котором работаем.