You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/03/24 23:04:06 UTC
DO NOT REPLY [Bug 6402] -
JNDIRealm, LDAP and SHA passwords vs {SHA}Base64Coded= passwords
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6402>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6402
JNDIRealm, LDAP and SHA passwords vs {SHA}Base64Coded= passwords
j.g.holman@qmul.ac.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From j.g.holman@qmul.ac.uk 2002-03-24 22:04 -------
By default JNDIRealm now authenticates a user by binding to the directory using
the DN of the user's directory entry and the presented password. This removes
the need for the realm to know about anything about password digests at all,
let alone encoding schemes such as {SHA}, since the directory handles all
aspects of password hashing. For that reason I've marked the bug as resolved.
It is still possible to configure the realm to apply a digest algorithm to the
presented password, retrieve the stored password or password hash, and compare
the two explicitly. This of course won't currently work if an encoding prefix
like {SHA} is used or the digest itself is Base64 encoded. However, I believe
authentication by binding is always the better approach except when support for
HTTP digest authentication is required - in which case I think the plaintext
password must be stored anyway - so I see little point in having JNDIRealm
decode{SHA} and similar schemes.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>