Again, I would send a plaintext password over HTTPS (my tutorial is using DIGEST for passwords, but it is an easy switch to plaintext)--it will be encrypted along with everything else in the soap:envelope that way, but with plaintext your web service provider will get the actual password and can use it to validate against the database, using whatever mechanism you database provides to authenticate (or you can use the same hash with the plaintext pwd that you already use to stored the hashed version in the database table.)
As shown in the WS-Security guide in the CXF documentation[1], you'll notice the password verification function is designed differently if you use a plaintext password instead of a password digest--as for how you can validate, take a look at the password verification function for plaintext passwords and I think that will answer your question. HTH, Glen [1] http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-UsernameTokenAuthentication Mark2008 wrote: > > Hi Glen, > > Thanks for your reply. > > Here is our situation: > > 1. We use HTTPS for encryption > 2. The password value in our database is hashed, NOT encrypted. So I can > not decrypt it back its original value and uses > WSPasswordCallback.setPassword. > > I guess the typicaly way will NOT work unless the client know what hashing > function we are using and then send the generated hashed value through the > web service. > > Is there anyway I can bypass the WSPasswordCallback.handleUserNameToken > (or other methods) that validate the INPUT-password against the supplied > hashed value from database? > > For example, If I can get the INPUT-password, I can hash it with the > algorithm at server side and then compare with the database value. This > should be very simple. > > Or is it possible I can modify/update the INPUT-password with its hashed > value at server side? > > Thanks for your help, > > Mark > > Mark2008 wrote: >> >> I am integrating the WS-Security UserNameToken approach to our existing >> application. The existing application stores the password in one-way >> hashing format with the following code snippet (plaintext is the plain >> password text and we use https) >> >> ------------------------------------------------------ >> MessageDigest md = MessageDigest.getInstance("SHA"); >> md.update(plaintext.getBytes("UTF-8")); >> byte raw[] = md.digest(); >> String hash = (new BASE64Encoder()).encode(raw); >> String newPassword = hash.substring(0,19); >> ------------------------------------------------------ >> >> I tried both PasswordDigest and PasswordText, but the security token can >> not be authenticated. >> WSSecurityException: The security token could not be authenticated or >> authorized at >> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:129) >> >> How do I specify the encrypt/hash algorithm? or should I hash the >> INPUT-password using the above code first and then set the database >> hashed password WSPasswordCallback.setPassword or just bypass the >> WSPasswordCallback.handleUserNameToken by comparing those two >> programmatically? >> >> Any idea? What's the best practice? >> >> Thanks, >> >> Mark >> >> > > -- View this message in context: http://www.nabble.com/WS-Security--UserNameToken--against-encrypted-database-password-tp20737774p20753211.html Sent from the cxf-user mailing list archive at Nabble.com.
