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?