Это звучит достаточно безопасно? я
пробежал эту схему мимо моего друга,
и он сказал, что это было уязвимо для
гнусные системные администраторы.
Всегда немного опасно отправлять пароль напрямую. Даже если вы используете SSL. Если это то, что он имеет в виду, значит, он прав. Я бы не сказал, что это уязвимо, просто не самый безопасный подход.
- Сервер указывает уникальную соль каждый раз, когда обслуживается страница входа.
- Хешируйте пароль уникальной соли на клиенте через javascript
до подачи.
- Отправьте этот хеш для аутентификации, но не пароль.
- Сделайте какую-нибудь необычную ерунду, которую я не понимаю, чтобы подтвердить подлинность хэша.
Звучит так, будто он предлагает схему «вызов-ответ» в сочетании с SSL. Это хороший подход, но позвольте мне объяснить его шаг за шагом, чтобы прояснить ситуацию.
После регистрации пароль отправляется через ssl на сервер. Это должен быть единственный раз, когда пароль отправляется напрямую. Сервер генерирует соль и хранит следующий хеш:
hash = sha1(password + salt)
Сервер также должен хранить соль.
Когда клиент посещает страницу входа в систему, сервер должен сгенерировать запись в таблице с идентификатором и значением запроса. Затем сервер должен отправить клиенту идентификатор, сохраненную соль и значение запроса.
Когда клиент готов войти в систему, у вас должна быть функция javascript, генерирующая вызов, а также хеш-код:
hash = sha1(sha1(password + server_salt) + server_challenge + client_challenge)
Затем клиент должен передать значения hash, server_saltid и client_challenge. Затем сервер вычисляет хеш следующим образом:
hash = sha1(stored_hash + server_challenge + client_challenge)
Если хэши соответствуют аутентификации пользователя, в любом случае запись о вызове должна быть удалена.