How to implement WSS UsernameToken when password on the server is salted and hashed?

Question

I'm currently trying to write a web service for customer and requirement is to use WS Security. On their server side, they have passwords stored as SHA-1(salt+password).

According to WSS spec, security header will contain nonce, timestamp and password digest as SHA-1(nonce+timestamp+password_user_entered). Then on the server you do SHA-1(nonce_from_header+timestamp_from_header+password_from_database) and compare that to password digest from header. This kind of implies that passwords on the back end must be in clear text. I guess it would work if passwords on the back-end are just SHA-1(password) because you can instruct clients to construct digest as SHA-1(nonce+timestamp+SHA-1(password)) but I can't make it work with salted passwords.

In my case, since passwords on the back-end are hashed and salted, I won't be able to authenticate user since on the server I will be able to do only SHA-1(nonce_from_request+timestamp_from_request+hashed_salted_password_from_database) which will not match digest from request. So, it looks like salt somehow must find it's way to client in order for them to create password digest which is usable on the server.

It seems that one solution is to have a web service you call first and submit username and you get salt back for that user. Then you create password digest as SHA-1(nonce+timestamp+SHA-1(salt_from_server+password)) and use that in header for main web svc. Is this a good solution or there is a better industry standard way to deal with similar scenarios?

Thank you.

Answer 1

I am not sure which particular WS-Security spec you refer to. However, as far as I see, this spec (thanks to @logicalscope) only gives a suggestion as far as how to hash your password. In addition, the spec states that:

Note that PasswordDigest can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient.

So in your case, the password is NOT available to the recipient. Only the already-hashed password.

Another important point to note is this comment on the spec:

However, unless this digested password is sent on a secured channel or the token is encrypted, the digest offers no real additional security over use of wsse:PasswordText.

I would suggest using plaintext PasswordText but ensure the channel is, e.g. SSL protected (if you haven't done so anyway). This way you don't need to change the way your passwords are stored, you can hash them any way you want, and the password is still transported securely from the user to your app.