 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / November 2004How to get WSE to authenticate a token using custom hashing algori
Hi all, Here's the problem: Our database contains usernames/hashed passwords and I need to get WSE to authenticate against it. But the issue is, that the hashes that are stored have been created using a custom hashing algorithm that does not match the algorithm defined in WS-Trust... My plan is to use SSL to access the secure webservices, and to send username and password in plaintext. I would then like to recompute the hash according to our custom hashing algorithm (on the server side) and compare with the hash stored in the DB. I have created a new CustomAuthenticator that extends UsernameTokenManager, and overridden AuthenticateToken to return the DB hashed value - but this is no good for me, as the value returned will not equal the plaintext password that was submitted. Thus, I believe I need to hook in somewhere else in WSE to overide the algorithm that is used to compare the stored password (our custom hash) with the submitted password (plaintext). I've looked a VerifyPlainTextPassword - but I've no idea what the is supposed to do (the documentation is a little lacking...). I've seen references to a ComputePasswordDigest method, but cannot find it. Any pointers would be great... Sincerely Pete Peter, Does this help ? http://www.softwaremaker.net/blog/PermaLink,guid,43d85031-3e0b-48a7-bdd7-1f49932 db40a.aspx What I did was sent a plaintext password in the usernametoken via WSE. However, I encrypted the entire usernametoken before sending it over. After the service rec'd that token 1) Uses the pipelines of WSE to decrypt the usernametoken 2) Retrieve the plaintext password 3) Hash it with your own custom hash algorithm 4) Compare against the database 5) If correct, just return the correct password or token.Password as the return string of the AuthenticateToken function. This worked for me fairly well in my implementation which has the same scenarios as yours.  SignatureThank you. Regards, Softwaremaker ================================== > Hi all, > Here's the problem: Our database contains usernames/hashed passwords and I [quoted text clipped - 25 lines] > > Pete Thanks Softwaremaker, Baring in mind that I am happy to use SSL to access the secure webservices, I wanted to avoid encrypting the SOAP body again. I actually found the following thread useful: http://groups.google.ie/groups?hl=en&lr=&threadm=F3C2A151-B100-46D5-948D-3609C46 F29C9%40microsoft.com&rnum=3&prev=/groups%3Fq%3Dwse%2520custom%2520hash%26hl%3De n%26lr%3D%26sa%3DN%26tab%3Dwg But in the end, I used a _slightly_ different scheme to the one described (I overrode VerifyToken,: since it is the only thing that calls AuthenticateToken, my version just doesn't call it... ) Thanks for the tip thoug Pete Hi Peter, Please see comments inline. SignatureThank you. Regards, Softwaremaker ================================== > Thanks Softwaremaker, > > Baring in mind that I am happy to use SSL to access the secure webservices, > I wanted to avoid encrypting the SOAP body again. I actually found the > following thread useful: [Softwaremaker] Encrypting the usernameToken itself alone does not encrypt the entire SOAP Body. In fact, implementing SSL encrypts the entire SOAP Envelope++. Your message payload and latency increases with SSL. http://groups.google.ie/groups?hl=en&lr=&threadm=F3C2A151-B100-46D5-948D-3609C46 F29C9%40microsoft.com&rnum=3&prev=/groups%3Fq%3Dwse%2520custom%2520hash%26hl%3De n%26lr%3D%26sa%3DN%26tab%3Dwg > But in the end, I used a _slightly_ different scheme to the one described (I > overrode VerifyToken,: since it is the only thing that calls > AuthenticateToken, my version just doesn't call it... ) [Softwaremaker] I am curious why your version doesnt call it. Did you 1) Inherit UsernameTokenManager in your custom usernameToken class ? 2) Override Function AuthenticateToken ? 3) Set your *.config file to read your custom usernameToken class as such ? <securityTokenManager type="UsernameTokenEG.CustomUsernameTokenManager, UsernameTokenEG" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri ty-secext-1.0.xsd" qname="wsse:UsernameToken" /> > Thanks for the tip thoug > > Pete My comments in line too... > [Softwaremaker] Encrypting the usernameToken itself alone does not encrypt > the entire SOAP Body. In fact, implementing SSL encrypts the entire SOAP > Envelope++. Your message payload and latency increases with SSL. Point taken - but I will be using SSL to encrypt everything in anycase: the contents of the Body will be sensitive. I want to avoid using WSE encryption, as we have SSL hardware accelerators in the Firewall, and there is little point encrypting twice. > [Softwaremaker] I am curious why your version doesnt call it. Did you > 1) Inherit UsernameTokenManager in your custom usernameToken class ? Yes - well no: I extended UserNameTokenManager in my custom TokenManager class (I think you may have mistyped) > 2) Override Function AuthenticateToken ? Yes - but it just throws NotImplmentedException (for safety - I want to know if anything else other than VerifyToken calls AuthenticateToken). The WSE documentation indicates that the VerifyToken method calls AuthenticateToken - I thus overrode VerifyToken and made my version NOT call AuthenticateToken. > 3) Set your *.config file to read your custom usernameToken class as such ? > <securityTokenManager type="UsernameTokenEG.CustomUsernameTokenManager, > UsernameTokenEG" > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri > ty-secext-1.0.xsd" qname="wsse:UsernameToken" /> Yup - did this too. HTH Pete I have "solved" this in the following manner: In my CustomAuthenticator, I have overridden VerifyToken. Within THAT method, I calculate the custom hash of the incoming password (VerifyToken takes a SecurityToken, so I upcast to a UserNametoken within the method), and compare it against the stored DB hash. If they don't compare, I throw a SecurityFormatException To be safe (in case other methods call AuthenticateException), I still override AuthenticateToken and it's body is to throw a NotImplementedException. Hi Peter, you could also send the hashed password to the server instead of sending it into plain text. Then you can compare the hash values in the same way that you compare plain text password i.e. treat the hash as a plain text password. Regards, Martin Martin and Peter, I have to say I dont agree with this method. If the client hashes the password with the same algorithm that the server uses and then sends the hash to the server, and the server compares this hash with the one in the database, then the hash in fact becomes the password. If a hacker steals the hash from the 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. SignatureThank you. Regards, Softwaremaker ========================================= > Hi Peter, > you could also send the hashed password to the server instead of sending it into plain text. Then you can compare the hash values in the same way that you compare plain text password i.e. treat the hash as a plain text password. > Regards, > Martin Hi Softwaremaker, You are absolutly right. However I do not think that using the hash scheme in WSE will prevent a fraund at all. The only thing it does is to prevent replay attacks. The hash that is transferred is calculated based on message id, timestamp, and username token all that are send in plain text along with the has. So if I am a hacker what prevents me to create another message id, new timestap and use the same username token to create a new hash and craft a new message that I can send to the server. IMHO using the UsernameToken still does not give any real level of security. That's why it does not make any difference if you send the hash of the password or use the hash scheme in WSE. At least in the former way the real password can not be sniffed as the UsernameToken will not have plain text password. It still has to be improved and we are all waiting to see the resolution in SP2. Best, Martin Kulov www.codeattest.com I agree here too - but the main problem with Martin's suggestion is that I have to ask clients to perform the custom hash _on the client side_ which is hardly standards compatible and there may be interoperability issues, I'd rather have the password sent in plaintext over SSL and adhere to standards than to have to use a custom client hashing scheme. Pete Well, After all MD5 and SHA1 are standards in hash algorithms. If you use the built-in hashing scheme in WSE you will have again hashing on the client side. After all I think that there are implementations for both algo's for every existing platform. Regards, Martin Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.