Где нужно начинать шифровать пароль?

Question

[Ilya Pavlov]

При регистрации/авторизации пользователь вводит пароль. Далее этот пароль отправляется на сервер для проверки/сохранения. Как будет разумнее : зашифровать пароль перед отправкой на сервер или уже там на сервере принимать его "как есть" и затем md5'ить(например)?

Comments

[PO6OT]

делайте как все, отправляйте обычный незашифрованный пароль по шифрованному https соединению
нет https - зачем вам тогда вообще эти попытки что-то обезопасить

Answer 1

[Владимир Мартьянов]

Разумнее https.

Answer 2

[Андрей Саныч]

Естественно, шифровать на сервере + https. Иначе злоумышленник спокойно посмотрит алгоритм шифрования на JS.

Answer 3

[Ivanq]

Как Вам уже сказал Владимир Мартьянов , лучше https. Если уж совсем никак, объясню, почему нельзя ни так, ни так.

Предположим, шифруем на сервере:

_______                 ______             _________
  |     |                /      \            |       |
  |     |               /  #  #  \           | # # # |
  |_____|     ------->  |  ____  |  -------> | # # # |
  /     \    password:  \ /    \ /           | # # # |
 /_______\ "mypassword"  \______/            |_______|
   Client               Ugly hacker           Server

Если на клиенте:

______                _________            ______
 /      \               |       |           /      \
/  #  #  \              | # # # |          /  #  #  \
|  ____  |   ------->   | # # # | -------> |        |
\ /    \ /   password:  | # # # |  login   \ \____/ /
 \______/    "hismd5"   |_______| success!  \______/
Ugly hacker              Server          Smiling hacker

Answer 4

[eri]

Интересно почему не используются в вебе технологии *CHAP . Это накладывает ограничение на сервер, что на нем будут храниться пароли с обратимым шифрованием, но при этом защищает от прослушки.

Даже Https не панацея - вспомните аваст, который подменяет корневой сертификат защищаемой системы, если это может делать антивирус, то скомпроментировать https на клиенте может любой троян.

Очень хотелось бы увидеть реализацию, в которой на клиенте пароль шифровался одним способом, передавался на сервер, там шифровался с солью сервера и в базе хранился бы хеш этого пароля. При авторизации клиент делает первый хэш, солит его солью полученной от сервера, передает на сервер. сервер солит второй солью пароль в базе, а первой солью полученный хеш авторизации. Сравнивает хеши. При таком подходе открытый пароль будет только в хтмл форме и сть ограничение на выбор хеш функций. но при довольно сложном алгоритме шифрования на сервере подобрать пароль и повторно использовать хеш становится сложнее.

Остается добавить к этому метод позволяющий не хранить пароль в поле ввода по мере набора...