William Stacy has a new blog in MSN Spaces and he blogged about a topic that has spurned from recent activities in the WSE newsgroups.

It is about the security and the use of username tokens in the real world, specifically when it relates to passwords being stored as hash in the user database.

William proposes a method here to solve the issue of how to authenticate username tokens embedded in _WS-Security Specs_ security headers.

In my own opinion, his case represents a very major common representation of how passwords are stored in the database. They are mostly and SHOULD be hased. To add another realm of security, SALT is used. However, I dont really agree that his method may prove to more secure. In fact, I think it gives a somewhat false sense of security (and William, please correct me if I am wrong anywhere).

1)   By using your verifier as a matching mechanism to gain authentication, then this verifier (SALT Hash and all) effectively becomes a password. If Mallet steals the hash from the user database, nothing prevents him/her from writing a client that sends the hash and thus he would authenticate successfully. This is exactly what the hash scheme is trying to avoid in the first place.

If used this way, the hash is no safer than storing the passwords in clear text in the database...which ultimately means that the weakest link is still the security of the Username Database which must be protected at all costs.

In other words, this must be made known clearly so that it doesnt preach a false sense of security that people think that this scheme NOT only protects their cleartext password BUT also their SOAP calls as well.

This post here explains real well on my thoughts as well.

2)   SALT should be a completely random value and should be algorithmically introduced to further obfuscate the one-way hash. In your approach, it seems that the SALT is tied very much to your username (am I wrong ?). This doesnt help much because I dont need to guess your publicly-available username, there are only a handful of hashing algorithms out there and you are NOT passing any SALT into your PasswordDeriveBytes constructor. In fact, the only saving grace is the iteration count which basically sets the number of iterations for the operation. Is that enough ? I believe it may serve well for some smaller-scale simpler systems BUT I dont know how it sits well with some of the security policies of bigger enterprises.

IMHO, I think the current username tokens as defined by WS-Security doesnt fit very well into most EXISTING user databases which store passwords as hashes which may or may not be SALTED. I dont think there is a clean way to do this in WSE without using or representing the hashes as passwords. However, I am still thinking about this issue and will blog more about it later if (not when) I reach enlightenment.

Your approach, however, does allow passwords to remain as they are in the EXISTING user databases. The only obstacle you require is a change in the schema of that table, which requires management approval and buy-in and usually triggers off many other related procedures, and that in my experience, is sometimes harder than finding the password from a hash.

[Author Note]: This topic has got nothing to do with the security of username tokens as I have blogged about earlier here. This is all about the authentication of username tokens with the stored credentials in the user databases.