Аутентификация на основе каучукового дайджеста с CustomAuthenticator, кто-то, пожалуйста, просветите меня - PullRequest
Новая
       37

Аутентификация на основе каучукового дайджеста с CustomAuthenticator, кто-то, пожалуйста, просветите меня

0 голосов
/ 14 февраля 2012

Ладно, немного поэкспериментировав, я обнаружил, что смола вызывала мой метод AbstractAuthenticator «authenticate», который принимает объект HttpDigestCredentials вместо DigestCredentials (до сих пор не знаю, когда вызывается каждый из них), проблема в том, что HttpDigestCredentialsне имеет метода getDigest (), вместо этого у него есть метод getResponse (), который не возвращает хэш или, по крайней мере, не сравнимый.

После создания собственного хеша [[user: realmassword] [nonce] [method: uri]] хеш сильно отличается, на самом деле я думаю, что getResponse () не возвращает дайджест, но, возможно, ответ серверав браузер?

В любом случае это мой журнал отладки: 

USER:user:PASSWORD:password:REALM:resin:METHOD:GET:URI/appe/appe.html:NONCE:HsJzN+j+GQD:CNONCE:b1ad4fa1ba857cac88c202e64528bc0c:CLIENTDIGEST:[B@5dcd8bf7:SERVERDIGEST:I4DkRCh21YG2Mk14iTe+hg==

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

Пожалуйста, кто-нибудь делал это раньше?чего-то не хватает в HttpDigestCredentials?Я знаю, что дайджест почти не используется.

Пожалуйста, я знаю о SSL, но пока не могу получить сертификат SSL, поэтому не говорите мне «Почему вы не используете SSL».;)

Обновление:

Не уверен, что было правильно, но, как я читал ранее, Ресин использует формат base64 для хэшей, поэтому я использовал apache commons-codec-1.6 для использования encodeBase64String () и теперь хэши выглядят одинаково, но они не совпадают.

Я пробовал оба passwordDigest.getPasswordDigest(a1+':'+nonce+':'+a2); passwordDigest.getPasswordDigest(a1+':'+nonce+':'+ncount+':'+cnonce+':'+qop+':'+a2);

, и ни один из них не дает такой же хеш, как у HttpDigestCredentials.

1 Ответ

0 голосов
/ 16 февраля 2012

Хорошо, я наконец сделал это.Странная тема Ха, только два представления?

Во-первых, дайджест-аутентификация использует пользователя, пароль, область, nonce, client_nonce, nonce_count, method, qop и uri.В основном он использует полную спецификацию дайджеста.Таким образом, чтобы вычислить хэш, нужно вычислить его со всеми свистками.Это просто вопрос вызова метода get для каждой из переменных из HttpDigestCredentials, кроме имени пользователя и пароля.Пользователь придет в форме Принципала и пароль, который вы должны найти самостоятельно в своей БД (в моем случае это база данных DB4O).

Затем необходимо создать объект PasswordDigest, который позаботится о создании хэша с помощью метода getPasswordDigest (), но сначала необходимо установить формат в шестнадцатеричный код с помощью passwordDigestObject.setFormat ("hex").

Существует один для HA1 getPasswordDigest (пользователь, пароль, область), и есть другой метод getPasswordDigest (), который принимает только одну строку, и его можно использовать для генерации остальных хешей, как HA2, так и с предыдущимхэшировал HA1 окончательный хеш, конечно, с nonce nonce_count client_nonce и qop, конечно, каждый из которых отделяется точкой с запятой.

Затем идет сложная часть, хотя смола работает с кодировкой base64 для дайджеста, когда вы вызываетеМетод getResponse () из HttpDigestCredentials возвращает массив байтов (что странно), поэтому для сравнения его с вашим хешем я использовал метод Hex.encodeHexString () из org.apache.commons.codec.binary.Hex ипередать возвращаемое значение HttpCredentialsDigest getResponse (), и это будетЯ даю хорошую шестнадцатеричную строку для сравнения.

Я делал это наоборот, я использовал хеш Base64 из PasswordDigest и преобразовывал хеш HttpDigestCredentials в Base64, и получающаяся строка никогда не была одинаковой.

...