Комментарии 28
Спасибо за статью!
Как раз подумываю применить SRP в одном проекте. Как думаете, возможна ли такая схема работы:
Веб-приложение общается с сервером практически целиком через JSON, т.к. после аутентификации у сервера и клиента будет общий ключ K, то мы будем его использовать для шифрования JSON'а, чем обеспечим и аутентификацию и безопасность обмена данными.
Или это уже извращение?
Как раз подумываю применить SRP в одном проекте. Как думаете, возможна ли такая схема работы:
Веб-приложение общается с сервером практически целиком через JSON, т.к. после аутентификации у сервера и клиента будет общий ключ K, то мы будем его использовать для шифрования JSON'а, чем обеспечим и аутентификацию и безопасность обмена данными.
Или это уже извращение?
А зачем нужно? Это фактически замена SSL с ключами на SSL с паролем :) Может, стоит на ключи таки поглядет?
В основном просто интересно. :)
Плюс к тому же раз уж у нас при применении SRP всё равно получается ключик, то почему бы его не использовать? Да и с сертификатами возиться не хочется…
Плюс к тому же раз уж у нас при применении SRP всё равно получается ключик, то почему бы его не использовать? Да и с сертификатами возиться не хочется…
Единственная проблема — скорость шифрования.
Ради интересу советую на JS закодировать/раскодировать простенький запрос на 15-20К текста…
Ради интересу советую на JS закодировать/раскодировать простенький запрос на 15-20К текста…
Наверно вы правы.
Но тогда получается если мы будем HTTPS использовать для всего, то разумно и регистрацию через него же проводить, а значит SRP можно и не применять.
Но тогда получается если мы будем HTTPS использовать для всего, то разумно и регистрацию через него же проводить, а значит SRP можно и не применять.
SRP имеет смысл оставить для защиты от утечки паролей при взломе бд.
Любой уважающий себя проект уже давно не хранит пароли в открытом виде, на мой взгляд это самая банальная и первичная мера безопасности.
Забудем на минутку о Sony. :)
Забудем на минутку о Sony. :)
Хранение просто хеша от пароля тоже не радостный вариант, разве что солёный.
Я лично не раз использовал md5(pass) из чужой бд для получения pass :)
И еще один момент — SRP позволят аутентифицировать пользователя безопасно и просто, в то время как SSL требует для этого сертификаты (во всяком случае, пока OpenSSL+SRP не используются браузерами).
То есть я за выбор SRP+SSL с Fallback до простой формы логина (поверх всё того же SSL) если требуется.
Я лично не раз использовал md5(pass) из чужой бд для получения pass :)
И еще один момент — SRP позволят аутентифицировать пользователя безопасно и просто, в то время как SSL требует для этого сертификаты (во всяком случае, пока OpenSSL+SRP не используются браузерами).
То есть я за выбор SRP+SSL с Fallback до простой формы логина (поверх всё того же SSL) если требуется.
даже имея хеш пароля — легко залогинится
(имея косвенный доступ к исходникам)
в данном случае, гарантией является сессионный ключ
(имея косвенный доступ к исходникам)
в данном случае, гарантией является сессионный ключ
НЛО прилетело и опубликовало эту надпись здесь
SSL, реализованный в сильно оптимизированном C коде меньше нагрузит сервер, чем ручное кодирование на скриптовом языке.
SRP JavaScript Demo, как кажется отрабатывает практически мгновенно, даже при выборе 1024 бит. Я ожидал больших тормозов. Или там какое-то не полноценное демо?
И да, спасибо, что опубликовали этот материал.
И да, спасибо, что опубликовали этот материал.
Сильно ускорились JS движки + поддержка Binary в последних версиях, без которых всё было очень и очень тоскливо.
И да, еще сильно зависит от хеш-функции. SHA-512 работает ощутимо медленнее чем SHA1
А мне вот не удалось проверить. Оказывается в Google Chrome есть клёвая бага, которой уже почти 3 года.
code.google.com/p/chromium/issues/detail?id=580
code.google.com/p/chromium/issues/detail?id=580
А при чём тут Java? Там же первый пример без явы, только на js.
я говорю про srp.stanford.edu/demo/demo.html там ничего не работает под предлогом этого бага.
так вот зачем нужен Native Client
NC нужен за любой сложной логикой на стороне клиента. JS всё-таки убоговат всё еще по скорости.
хм, я бы не был столь категоричен
bellard.org/jslinux/
bellard.org/jslinux/
Спасибо за информацию, нашел ее очень полезной
хотелось бы протестировать поближе к практике:
на реальных цифрах, чтоб JS не тормозил
что посоветуете?
хотелось бы протестировать поближе к практике:
на реальных цифрах, чтоб JS не тормозил
что посоветуете?
Судя по всему, сейчас оно не так сильно и тормозит, всё-таки компы шустрее стали и js движки тоже.
Стоит просто взять и попробовать. Оптимальным будет килобит и SHA256.
Если будут тормоза — тогда уже посмотреть на полкилобита и SHA224.
Опускаться ниже полукилобита не имеет смысла из соображений безопасности.
Стоит просто взять и попробовать. Оптимальным будет килобит и SHA256.
Если будут тормоза — тогда уже посмотреть на полкилобита и SHA224.
Опускаться ниже полукилобита не имеет смысла из соображений безопасности.
Спасибо за статью, как раз искал что-то в этом роде.
Вроде всё понятно кроме одного момента, правильно ли я понимаю что N генериться один раз, и пишется куда-то как константа, и потом используется при регистрации и аутентикации пользователей?
Если генерить N при каждой новой регистрации и потом для каждой новой аутентикации то у меня никак не получается получить тот-же K но обеих сторонах.
Поясните пожалуйста что делать с N.
Спасибо
Вроде всё понятно кроме одного момента, правильно ли я понимаю что N генериться один раз, и пишется куда-то как константа, и потом используется при регистрации и аутентикации пользователей?
Если генерить N при каждой новой регистрации и потом для каждой новой аутентикации то у меня никак не получается получить тот-же K но обеих сторонах.
Поясните пожалуйста что делать с N.
Спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SRP-6: аутентификация без передачи пароля