[ https://issues.apache.org/jira/browse/WSS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Utter updated WSS-239: -------------------------- Description: Per the oasis spec, the UsernamePassword is summarized by the algorithm: base64(sha-1(nonce+created+password)) But, in some scenarios you don't store cleartext passwords - only the sha-1 hash of them. The oasis spec allows this via what they claim as "..password equivalent". The problem I'm running into is that the password equivalent is sha-1(password) or ultimately this equivalent: base64(sha-1(nonce+created+sha-1(password))) When the applicability of this approach was questioned to the oasis list, they confirmed it: http://lists.oasis-open.org/archives/wss-dev/201006/msg00003.html But, when using the wss4j WSPasswordCallback mechanism, the call expects the password to be a string but the binary output of the digest if converted to a string, then back to the bytes (by UsernameToken.doPasswordDigest()) does not result in the original byte array - causing any digest calculations to fail. This was originally posted in the mailing list below where Colm suggested I provide a patch: http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/201006.mbox/%3caanlktilndi8ijophc6lgv3mkp5_i_utrcfendkdk1...@mail.gmail.com%3e was: Per the oasis spec, the UsernamePassword is summarized by the algorithm: base64(sha-1(nonce+created+password)) But, in some scenarios you don't store cleartext passwords - only the sha-1 hash of them. The oasis spec allows this via what they claim as "..password equivalent". The problem I'm running into is that the password equivalent is sha-1(password) or ultimately this equivalent: base64(sha-1(nonce+created+sha-1(password))) When the applicability of this approach was questioned to the oasis list, they confirmed it: http://lists.oasis-open.org/archives/wss-dev/201006/msg00003.html But, when using the wss4j WSPasswordCallback mechanism, the call expects the password to be a string but the binary output of the digest if converted to a string, then back to the bytes (by UsernameToken.doPasswordDigest()) does not result in the original byte array - causing any digest calculations to fail. > Need ability to handle password "equivalent" between WSPasswordCallback and > UsernameToken when it's binary data > --------------------------------------------------------------------------------------------------------------- > > Key: WSS-239 > URL: https://issues.apache.org/jira/browse/WSS-239 > Project: WSS4J > Issue Type: Improvement > Components: WSS4J Core > Affects Versions: 1.5.8 > Reporter: Jim Utter > Assignee: Ruchith Udayanga Fernando > Attachments: WSS-239-1_5_x-fixes.patch > > > Per the oasis spec, the UsernamePassword is summarized by the algorithm: > base64(sha-1(nonce+created+password)) > But, in some scenarios you don't store cleartext passwords - only the sha-1 > hash > of them. The oasis spec allows this via what they claim as "..password > equivalent". The problem I'm running into is that the password equivalent > is sha-1(password) or ultimately this equivalent: > base64(sha-1(nonce+created+sha-1(password))) > When the applicability of this approach was questioned to the oasis list, > they confirmed it: > http://lists.oasis-open.org/archives/wss-dev/201006/msg00003.html > But, when using the wss4j WSPasswordCallback mechanism, the call expects the > password to be a string but the binary output of the digest if converted to > a string, then back to the bytes (by UsernameToken.doPasswordDigest()) does > not result in the original byte array - causing any digest calculations to > fail. > This was originally posted in the mailing list below where Colm suggested I > provide a patch: > http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/201006.mbox/%3caanlktilndi8ijophc6lgv3mkp5_i_utrcfendkdk1...@mail.gmail.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org For additional commands, e-mail: wss4j-dev-h...@ws.apache.org