 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / December 2004How Secure Are Username Token Encrypted Messages
How secure is it to encrypt the body of a message with a Username token? In the HOL it says that it is not very secure. It doesn't say why though. It's obviously not as secure as encrypting with a binary token, but I would like a more in depth reason as to what it makes it not very secure. Thanks! --------------------------------- Josh Pollard josh.glmotorsports.net/blog Hi Josh, Basically you need some kind of shared secret in order to make a secure transmission. When you are using UsernameToken to sign and encrypt body you are protecting the body, but to let the receiver decrypt the message the UsernameToken is transmitted in plain text. I.e. your password is not protected. A better solution is to use Secure Conversation as it is described in HOL. This way you will have your UsernameToken encrypted using the public key of X.509 certificate from the receiver. At the sender you will receive the shared secret encrypted and signed using UsernameToken sent. When you have exchanged the shared secret all following messages will you it for encryption and signing. HTH, Martin Kulov http://www.codeattest.com MCAD Charter Member MCSD.NET Early Achiever In this specific case though the Username Token is using PasswordOption.SendNone to sign the request. So in this case, even though the username token is being passed in plain text, only the username is displayed, not the password. This being the case, is it ok to use this method? For this particular project X.509 certificates aren't an option. In this specific case though the Username Token is using PasswordOption.SendNone to sign the request. So in this case, even though the username token is being passed in plain text, only the username is displayed, not the password. This being the case, is it ok to use this method? For this particular project X.509 certificates aren't an option > Hi Josh, > [quoted text clipped - 7 lines] > MCAD Charter Member > MCSD.NET Early Achiever Hi Josh, If your UsernameToken does not contain password you are leaving the token without any evidence about the sender. Everyone can authenticate just using the username that you send. Regards, Martin Kulov http://www.codeattest.com MCAD Charter Member MCSD.NET Early Achiever Hi Martin I was thinking that a signiture is sent with the request. this signature is the evidance that the password is right and must be known to the sender. (=the server gets the password and the username, probably also some kind of "session key" to verify the signature)... Cheers Harry Hi Harry, Not exactly, There is no session key established yet. Hence the signature is created using the UsernameToken and everyone can create this signature because the UsernameToken is known. The server does not know the password also in this case. Regards, Martin Kulov http://www.codeattest.com MCAD Charter Member MCSD.NET Early Achiever I do not believe this to be the case. When you sign a message with a Username token that has the PasswordOption.SendNone enabled then the service needs to use a custom UsernameTokenManager. In that case, the UsernameTokenManager handles the authentication (by looking up the password and returning it). So by using a signed message, with the PasswordOption.SendNone option enabled, you can send a message that must be authenticated, but doesn't require the password to go across the wire. Since the password is the mutually shared secret, and it doesn't go over the wire (but is still used) isn't this method of encryption every bit (if not more) as secure as the binary token? > Hi Josh, > [quoted text clipped - 7 lines] > MCAD Charter Member > MCSD.NET Early Achiever Hello Josh, When you use the send none option the password hash is sent accross along with a nonce and a created time. The server can use this to create the password. However its not required to create a Usernametoken manager for this unless you're not using the standard windows users. The custom username token manager is for authenticating with different datasources i.e. SQL Server, AD/AM etc http://benjaminm.net/PermaLink.aspx?guid=87fd974c-1f77-437f-8191-6e6fd92f831f that Might clarify your ideas. HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com > I do not believe this to be the case. When you sign a message with a > Username token that has the PasswordOption.SendNone enabled then the [quoted text clipped - 22 lines] >> MCAD Charter Member >> MCSD.NET Early Achiever > Hello Josh, > When you use the send none option the password hash is sent accross > along with a nonce and a created time. Wrong, the hash is not sent to the server with PasswordOption.SendNone. The hash is sent if you use PasswordOption.SendHashed. > The server can use this to create the password. A hash, even if it was sent, cannot be used to create the original password (except through a dictionary attack which is not exactly 'recreating' the password). Otherwise, I believe Josh is right: if you sign with a UsernameToken and send it with PasswordOption.SendNone, then the password will not be sent over. The server will verify the signature and by doing so also verifies the password - the signature will not match unless the client and the server use the same password. The reason why encrypting with a UsernameToken is less secure than using a X509 certificate is that the UsernameToken is as secure as the password - and those are usually not so secure. Regards, Sami >> Hello Josh, >> When you use the send none option the password hash is sent accross >> along with a nonce and a created time. > Wrong, the hash is not sent to the server with > PasswordOption.SendNone. The hash is sent if you use > PasswordOption.SendHashed. Meant to say digest :) >> The server can use this to create the password. >> > A hash, even if it was sent, cannot be used to create the original > password (except through a dictionary attack which is not exactly > 'recreating' the password). Meant recreate the digest using the nonce created date and the pwd retreived from the username token manager > Otherwise, I believe Josh is right: if you sign with a UsernameToken > and send it with PasswordOption.SendNone, then the password will not [quoted text clipped - 8 lines] > Regards, > Sami Hello Josh, >> In that case, the UsernameTokenManager handles the authentication (by looking up the password and returning it). If you are not sending the password then your UsernameTokenManager must always return empty string to succeed the authentication. I understand what you mean but you have got the wrong idea. If you are using SendNone option and sign the message no password is involved for creating the message signature. Please read this [1]. It may help you understand this better. [1] http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/htm l/wssecdrill.asp Regards, Martin Kulov http://www.codeattest.com MCAD Charter Member MCSD.NET Early Achiever Martin, Are you absolutely sure about this? Where does it explain this in the article you referred to? If sender signs with the UsernameToken (like Josh is suggesting), and sends the UsernameToken with PasswordOption.SendNone, then the server-side UsernameTokenManager will have to return the same password the client used for creating the signature. Otherwise the signature check will fail and the client receives "The signature or decryption was invalid". This is the way it works when I tested it (WSE 2.0 (no SP2 installed)). In other words, only the client who knows the correct password will be able to perform the call, as long as the server enforces the signature requirement. Check out the UsernameSigning quickstart sample. Also, this article confirms my understanding: http://msdn.microsoft.com/msdnmag/issues/04/10/ServiceStation/ (search for PasswordOption.SendNone). Regards, Sami > Hello Josh, > [quoted text clipped - 19 lines] > MCAD Charter Member > MCSD.NET Early Achiever Hi Sami, I am not absolutely sure for anything in the world :) So we sign the message with UsernameToken and send the token without the password. The receiver has custom username token manager and in the AuthenticateToken method it returns the password from the database for example. First - this password is never checked since we use SendNone option. Second – when the WSE checks the signature it fails, because our username token is not the same. I tried to set the password in the token with the one that I have extracted from the DB, but the password field is read only. I am not sure if this is the correct way of doing it and how Aaron did managed to do it. I do not either is this behavior different in WSE SP1. It is a good idea, but has one drawback. You can not authenticate to the domain with the username token manager, because you have to provide password. I will spend some more time on this idea however. It should be secure enough I think as Josh supposed. Thanks for the correction, Martin Kulov http://www.codeattest.com MCAD Charter Member MCSD.NET Early Achiever MCSD Hello Martin, Again its only as secure as the shared secret. So if the secret is compromised so is the security. Also want to add that no matter what password option you use, If you are signing a message using a username token, WSE uses a key derivation algorithm to generate a key and because its a shared secret the server can recreate the key. This key is used to signatures (on the client) and verification of signatures (on the server side). The only problem with using username tokens is that the key derivation algorithms are not standard accross various toolkits. Quoting from http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1 .0.pdf "When a UsernameToken is referenced from a <ds:KeyInfo> element, it can be used to derive a key for a message authentication algorithm using the password. This profile considers specific mechanisms for key derivation to be out of scope. Implementations should agree on a key derivation algorithm in order to be interoperable." Also refer Herveys blog http://www.dynamic-cast.com/mt-archives/000019.html HTH Regards, Dilip Krishnan MCAD, MCSD.net dkrishnan at geniant dot com > Hi Sami, > [quoted text clipped - 21 lines] > MCSD.NET Early Achiever > MCSD +1, Dilip See post on this. http://www.softwaremaker.net/blog/PermaLink,guid,20f8fcb0-a5eb-41b4-8ddf-217f4e3 38cf1.aspx > Hello Martin, > Again its only as secure as the shared secret. So if the secret is compromised [quoted text clipped - 48 lines] > > MCSD.NET Early Achiever > > MCSD UsernameTokens work based on a shared secret, so there is no need to transmit a password across the wire if you implement your own custom usernametoken manager. See post on this. http://www.softwaremaker.net/blog/PermaLink,guid,20f8fcb0-a5eb-41b4-8ddf-217f4e3 38cf1.aspx  SignatureThank you. Regards, Softwaremaker ================================== > Hi Sami, > > I am not absolutely sure for anything in the world :) > So we sign the message with UsernameToken and send the token without the password. The receiver has custom username token manager and in the AuthenticateToken method it returns the password from the database for example. First - this password is never checked since we use SendNone option. Second ? when the WSE checks the signature it fails, because our username token is not the same. I tried to set the password in the token with the one that I have extracted from the DB, but the password field is read only. I am not sure if this is the correct way of doing it and how Aaron did managed to do it. I do not either is this behavior different in WSE SP1. > It is a good idea, but has one drawback. You can not authenticate to the domain with the username token manager, because you have to provide password. I will spend some more time on this idea however. It should be secure enough I think as Josh supposed. > Thanks for the correction, > [quoted text clipped - 4 lines] > MCSD.NET Early Achiever > MCSD Martin, My question is Encrypting the username token using the public key of the server ensures that the password is encrypted in the request to the server. What happens when the response from the server is sent to the client ? I have looked at the the output tace at the client has no password in clear text. But the input trace on the client has a clear text password. Why ? Regards Jagdeep > Hi Josh, > [quoted text clipped - 7 lines] > MCAD Charter Member > MCSD.NET Early Achiever See if this will help ? http://www.softwaremaker.net/blog/PermaLink,guid,dd97ba6e-53a4-4b45-9a87-81447a0 b99e9.aspx SignatureThank you. Regards, Softwaremaker ================================== > Martin, > My question is Encrypting the username token using the public key of the [quoted text clipped - 10 lines] > > > > Basically you need some kind of shared secret in order to make a secure transmission. When you are using UsernameToken to sign and encrypt body you are protecting the body, but to let the receiver decrypt the message the UsernameToken is transmitted in plain text. I.e. your password is not protected. A better solution is to use Secure Conversation as it is described in HOL. This way you will have your UsernameToken encrypted using the public key of X.509 certificate from the receiver. At the sender you will receive the shared secret encrypted and signed using UsernameToken sent. When you have exchanged the shared secret all following messages will you it for encryption and signing. > > HTH, > > [quoted text clipped - 3 lines] > > MCAD Charter Member > > MCSD.NET Early Achiever Hi Josh, I hope you dont mind me chipping my 0.02 worth into this conversation. Usernametokens are as secure as your passwords. That means that if you have a good security policy on how your company treats passwords, ie... 1) Minimum length 2) Different characters 3) Password Change Frequency (in months instead of years ;-)) 4) Elimination of Weak Passwords such as using names and such 5) ... your Usernametokens can be fairly secure. If you dont treat your passwords with good companies' password policies, then you cannot expect Usernametokens to give your message as secure a protection as anyone would like. I doubt WS-I or OASIS would include Usernametokens inside the WS-Security specs if they doubt its security. Implemenation is the key. For the thread about PasswordOption.sendnone or sendhashed, the hash of the password plus other elements are used to produce the cipher. NO password is sent over using the SendNone option. In fact, imho, I would recommend this option best. Another thing to take note is one that relates to the real world. I believe Usernametokens have its place here. It is easiest to implement and common in any business environments. Therefore, it can be plugged into any existing IT systems with relatively lesser effort. Also, X509 digital certs are usually used to authenticate machines and / or companies, it would be more expensive to expect every user in an organization to have a digital cert and a private / public key pair. Usernametokens are more appt to authenticate the users themselves in the real world. However, if you are using authentication between machines, you may want to opt for X509s instead. Hope I have cleared some confusion. SignatureThank you. Regards, Softwaremaker http://www.softwaremaker.net/blog ========================================= > How secure is it to encrypt the body of a message with a Username token? In > the HOL it says that it is not very secure. It doesn't say why though. It's [quoted text clipped - 6 lines] > Josh Pollard > josh.glmotorsports.net/blog i add my 2cents also - this is not quite true - do you know that you need a 20 character - arbitrary - upper/lowercase/digits/punctuation password to get 128 bits of entropy to use..? does your password policy enforce that? in addition - the server must have acess to the clear text pwd to return it in your UsernameTokenManager. I wouldn't want to have a cleartext pwd database on my web server.... they are such secure that WSE2 SP2 will not allow to send unencrypted UsernameTokens anymore.... there are some workarounds - e.g. using a ScopeURI (google for that) that is used to hash the password on client before sending it to the server (makes it a little better) there is an upcoming keith brown article on msdn (in the next weeks) with an elaborate discussion how UsernameTokens should be used - and how not. Dominick Baier -- DevelopMentor www.leastprivilege.com nntp://news.microsoft.com/microsoft.public.dotnet.framework.webservices.enhancements/<eQXSEZY3EHA.1192@tk2msftngp13.phx.gbl> Hi Josh, I hope you dont mind me chipping my 0.02 worth into this conversation. Usernametokens are as secure as your passwords. That means that if you have a good security policy on how your company treats passwords, ie... 1) Minimum length 2) Different characters 3) Password Change Frequency (in months instead of years ;-)) 4) Elimination of Weak Passwords such as using names and such 5) ... your Usernametokens can be fairly secure. If you dont treat your passwords with good companies' password policies, then you cannot expect Usernametokens to give your message as secure a protection as anyone would like. I doubt WS-I or OASIS would include Usernametokens inside the WS-Security specs if they doubt its security. Implemenation is the key. For the thread about PasswordOption.sendnone or sendhashed, the hash of the password plus other elements are used to produce the cipher. NO password is sent over using the SendNone option. In fact, imho, I would recommend this option best. Another thing to take note is one that relates to the real world. I believe Usernametokens have its place here. It is easiest to implement and common in any business environments. Therefore, it can be plugged into any existing IT systems with relatively lesser effort. Also, X509 digital certs are usually used to authenticate machines and / or companies, it would be more expensive to expect every user in an organization to have a digital cert and a private / public key pair. Usernametokens are more appt to authenticate the users themselves in the real world. However, if you are using authentication between machines, you may want to opt for X509s instead. Hope I have cleared some confusion. -- Thank you. Regards, Softwaremaker http://www.softwaremaker.net/blog ========================================= > How secure is it to encrypt the body of a message with a Username token? In > the HOL it says that it is not very secure. It doesn't say why though. It's > obviously not as secure as encrypting with a binary token, but I would like a > more in depth reason as to what it makes it not very secure. > [quoted text clipped - 3 lines] > Josh Pollard > josh.glmotorsports.net/blog [microsoft.public.dotnet.framework.webservices.enhancements] 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.