Comments 5
Проблема начинается тогда, когда передается не сам пароль (что можно делать только по SSL), а его хеш.
Обычным сценарием является следующий:
1. Получить от пользователя пароль при регистрации.
2. Посолить (Add salt), взять хеш и положить хеш вместе с солью в базу.
3. Получить от пользователя пароль при аутентификации.
4. Посолить, взять хеш, отправить на сервер и сравнить полученные значения.
Сценарий зарекомендовал себя вполне и вполне.
С вашей идеей он не сочетается вообще.
Обычным сценарием является следующий:
1. Получить от пользователя пароль при регистрации.
2. Посолить (Add salt), взять хеш и положить хеш вместе с солью в базу.
3. Получить от пользователя пароль при аутентификации.
4. Посолить, взять хеш, отправить на сервер и сравнить полученные значения.
Сценарий зарекомендовал себя вполне и вполне.
С вашей идеей он не сочетается вообще.
Короче, виртуальная клавиатура все равно забарывает.
Можно и там и там, смотря где удобнее
Salt нужен для того, чтобы избежать возможности подобрать пароль по хешу через методом прямого сравнения. Ведь если у двух юзеров одинаковые пароли — то их хеши тоже будут одинаковые.
Можно делать хеш на клиенте, затем на сервере солить и снова делать хеш — полученную конструкцию уже проверять на предмет совпадений. Мне этот подход больше всего нравится.
Salt нужен для того, чтобы избежать возможности подобрать пароль по хешу через методом прямого сравнения. Ведь если у двух юзеров одинаковые пароли — то их хеши тоже будут одинаковые.
Можно делать хеш на клиенте, затем на сервере солить и снова делать хеш — полученную конструкцию уже проверять на предмет совпадений. Мне этот подход больше всего нравится.
Теперь можете перенести сами в тематический блог.
Sign up to leave a comment.
О защите паролей от кейлоггеров — более гуманная идея