Исправление swwwfactory, (текущая версия) :
зачем применять кривые велосипеды, если есть хороший, годный танк?
не спорю, всякий транспорт хорош для своей местности и решаемых задач - происхождение велосипеда связано со специфической задачей разумеется
передавать хеш — тоже самое, только с лишними сложностями. Какая разница что снифать?
это работает в идеале, когда сервер знает пароль - он солит, криптует у себя и результат запоминает, отсылая клиенту соль (специи по вкусу).
Клиент, зная пароль вычисляет результат и отсылает на сервер его.
Сервер (тоже зная пароль) сверяет результат и осуществляет допуск, если ок.
Враг тоже так хочет, но не может т.к. не знает параметров вычисления хэша (вернее может знать по MITM, но у него мало времени на подбор хэша и нет возможности заснифить ввод пароля у клиента) и пароль он не знает разумеется - в целом ему надо снова инициировать запрос на вычисление. Соль динамическая - валидна например 10 сек.
Тут все хорошо, но надо серверу знать пароль. Варианты возможны более сложные - несколько паролей, криптоконтейнер, encode на клиенте. Их цель свести к минимуму присутствие пароля на сервере.
ну дык что его не юзать во все поля? Если ресурс «только для своих», то хороший метод — сделать самоподписанный сертификат. А для публичного — пусть будет обычный, ну например я не против, если АНБ/КГБ узнает мой пароль к ЛОРу.
self-signed имеет место, да SSL спасает в основном. Публичный? Да пофиг, если нечего скрывать, а если например это приватная информация или доступная только с по личному разрешению, да мало ли для чего?
Исходная версия swwwfactory, :
зачем применять кривые велосипеды, если есть хороший, годный танк?
не спорю, всякий транспорт хорош для своей местности и решаемых задач - происхождение велосипеда связано со специфической задачей разумеется
передавать хеш — тоже самое, только с лишними сложностями. Какая разница что снифать?
это работает в идеале, когда сервер знает пароль - он солит, криптует у себя и результат запоминает, отсылая клиенту соль (специи по вкусу).
Клиент, зная пароль вычисляет результат и отсылает на сервер его.
Сервер (тоже зная пароль) сверяет результат и осуществляет допуск, если ок.
Враг тоже так хочет, но не может т.к. не знает параметров вычисления хэша (вернее может знать по MITM, но у него мало времени на подбор хэша и нет возможности заснифить ввод пароля у клиента) - в целом ему надо снова инициировать запрос на вычисление. Соль динамическая - валидна например 10 сек.
Тут все хорошо, но надо серверу знать пароль. Варианты возможны более сложные - несколько паролей, криптоконтейнер, encode на клиенте. Их цель свести к минимуму присутствие пароля на сервере.
ну дык что его не юзать во все поля? Если ресурс «только для своих», то хороший метод — сделать самоподписанный сертификат. А для публичного — пусть будет обычный, ну например я не против, если АНБ/КГБ узнает мой пароль к ЛОРу.
self-signed имеет место, да SSL спасает в основном. Публичный? Да пофиг, если нечего скрывать, а если например это приватная информация или доступная только с по личному разрешению, да мало ли для чего?