Aaron mentioned a gripe I have with UserNameToken. The approach recommended by the UserNameToken profile, namely the one-time hash that is designed to counter replay attacks,
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
requires that the server store the client's cleartext password if simple passwords are being used - note that the profile also supports password being a one-time key or other secret such as that generated by a SecurID token. But the implementations and frameworks being built today (namely WSE) are taking this quite literally and using cleartext passwords for password by default.
My main gripe with this simple implementation is that if an attack on the server leads to cleartext passwords being recovered, this is catastrophic! Passwords are generally used when humans are involved, and humans generally use the same password wherever they go. It's not a good practice, but it's one that the vast majority of people use today. No security-concious developer wants to be storing secrets on his machine. Especially secrets that in real life will often have a scope beyond her own application!
Given that password in the above function need not be a real cleartext password according to the profile, I see no reason why we cannot simply identify a scope over which a given password will be valid and identify a unique string or URI for that scope (this could be done through policy, perhaps). Then, we can start with
Password_Digest = Base64 ( SHA-1 ( nonce + created + validator ) )
and we can then calculate
validator as
validator = Base64 ( SHA-1 ( scopeURI + cleartextPassword ) )
which means the server would only need to store validator, as opposed to the cleartext password itself. If an attack on the server leads to these validators being compromised, the user's cleartext password is still safe. It's a simple idea, and I'd love for someone to explain why this isn't in the profile or implemented in WSE. Perhaps Aaron could comment on whether this notion of a scopeURI would be feasible - I'm sure he knows much more about policy than I do.
Posted
Jul 03 2004, 11:14 AM
by
keith-brown