История изменений
Исправление maxcom, (текущая версия) :
Насколько я понимаю в твоем случае сервер должен хранить plain text пароль пользователя, что само по себе является довольно сомнительной практикой. И в целом предложенный тобой алгоритм – это аналог CHAP, CRAM-MD5 и подобного.
Думаю можно попробовать изобразить какой-нибудь Encrypted Key Exchange на JS (например DH-EKE), который основе пароля выработает идентификатор сессии который далее будет использоваться в запросах. Только готовых реализаций что-то не находится, вероятно мало настоящих параноиков которые готовы доверять javascript’у.
Наверное причина тут в том, что MITM может не только пассивно слушать, но и подселить свой код который утянет пароль прямо из формы. Так что единственное что можно сделать это надеяться на TLS, потому как если его сломали то пароль уже не спасти (средствами JS).
Реально работающая защита – использовать одноразовые пароли, но тут уже возникает вопрос useability vs security.
Исправление maxcom, :
Насколько я понимаю в твоем случае сервер должен хранить plain text пароль пользователя, что само по себе является довольно сомнительной практикой. И в целом предложенный тобой алгоритм – это аналог CHAP, CRAM-MD5 и подобного.
Думаю можно попробовать изобразить какой-нибудь Encrypted Key Exchange на JS (например DH-EKE), который основе пароля выработает идентификатор сессии который далее будет использоваться в запросах. Только готовых реализаций что-то не находится, вероятно мало настоящих параноиков которые готовы доверять javascript’у.
Наверное причина тут в том, что MITM может не только пассивно слушать, но и подселить свой код который утянет пароль прямо из формы. Так что единственное что можно сделать это надеяться на TLS, потому как если его сломали то пароль уже не спасти (средствами JS).
Исправление maxcom, :
Насколько я понимаю в твоем случае сервер должен хранить plain text пароль пользователя, что само по себе является довольно сомнительной практикой. И в целом предложенный тобой алгоритм – это аналог CHAP, CRAM-MD5 и подобного.
Думаю можно попробовать изобразить какой-нибудь Encrypted Key Exchange на JS (например DH-EKE), который основе пароля выработает идентификатор сессии который далее будет использоваться в запросах. Только готовых реализаций что-то не находится, вероятно мало настоящих параноиков которые готовы доверять javascript’у.
Исходная версия maxcom, :
Насколько я понимаю в твоем случае сервер должен хранить plain text пароль пользователя, что само по себе является довольно сомнительной практикой. И в целом предложенный тобой алгоритм – это аналог CHAP, CRAM-MD5 и подобного.
Думаю можно попробовать изобразить какой-нибудь Encrypted Key Exchange на JS (например DH-EKE), который основе пароля выработает идентификатор сессии который далее будет использоваться в запросах.