Защищенный MD5 / Зашифрованный логин для портала JBoss

Question

В настоящее время я создал регистрационную форму для сервера портала JBoss, и моя страница входа выглядит (обслуживается только по HTTPS):

<form action="j_security_check" method="post">
     Enter UserName: <input name="j_username" type="text" />

     Enter Password: <input name="j_password" type="password" />

     <input type="submit" value="Submit" /> <input type="reset" value="Reset" />
     </form>

Во время тестирования безопасности приложения было рекомендовано не отправлять пароль в виде обычного текста, а вместо этого иметь некоторое шифрование MD5 или другое, чтобы никто не мог извлечь пароль при перехвате запроса.

Как я могу реализовать это в форме входа в систему на портале JBoss?

Answer 1

Здесь вы получили несколько плохих советов.

Лучшей стандартной практикой является отправка самого пароля на сервер при условии, что ссылка защищена SSL / TLS.Ваше приложение должно получить этот пароль, хэшировать его (не используя MD5, а допустимый соленый хеш (или bcrypt, который является лучшим решением)), а затем сравнить его с сохраненным соленым хешем.Следовательно, ваше приложение никогда не хранит пароли пользователей, поэтому, если ваш файл / база паролей будет скомпрометирован, пароль не будет раскрыт, и, если вы используете алгоритм с сильным соленым хешем / bcrypt, никто не сможет перебрать хэш, чтобы восстановить действительный пароль.

Однако вам необходимо сделать это на стороне сервера, в вашем приложении.Ваше приложение должно взять пароль и сделать это хэширование.Если вы хешируете пароль на клиенте и отправляете в приложение реальный соленый хеш, вы открываете себя для другой атаки.Если кто-то украл ваш файл паролей / базу данных, он узнает хеш пароля пользователя.Если у вас есть клиент, отправляющий хеш на сервер, злоумышленник будет точно знать, какой хеш отправить, и сможет получить доступ к учетной записи любого пользователя!Вместо этого вы хотите, чтобы клиент сам отправил пароль и чтобы сервер генерировал хеш на его основе, чтобы злоумышленник не знал, что отправить, при попытке войти в систему как пользователь (поскольку вы не можете взять соленый хеш и восстановитьпароль от него, при условии сильной реализации хеша с солью).