[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Encrypting a password
I believe so. It was decided at the last meeting not to bother with SSL/TLS for the interop demo. Personally, I would expect that if someone is sending just a username or username/password, and they have the X.509 of the server, that they would just used SSL as it offers better protection. -----Original Message----- From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] Sent: Tuesday, March 25, 2003 3:36 AM To: Web Services Security Subject: Re: [wss] Encrypting a password The draft states that the password is optional. And only when the password is present are the optional nonce and time stamp present. So there seems to be a case in which only the login name is present. Would this be encrypted? The draft also mentions the use of a secure channel, and one example shows the UsernameToken including a password "sent as clear text" "over a confidential channel". Thinking just now of how I access the WSS member pages, I use a simple login and password. Will WSS support this quite common mechanism of secure access? Phil Chris Kaler wrote: >My assumption too was that we would be encrypting the <UsernameToken> >element. To prevent dictionary and replay attacks, the token contains >both a <Nonce> and a <Created> timestamp. All of this is encrypted. > >-----Original Message----- >From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com] >Sent: Wednesday, March 19, 2003 9:27 AM >To: Hal Lockhart; Web Services Security >Subject: Re: [wss] Encrypting a password > > >I have been assuming that the whole UserNameToken would be encrypted, >not >individual attributes. I don't know if its possible to encrypt >individual >attributes but all the examples in our drafts have been of whole >elements. > >With regards to replay attacks, a UserNameToken can contain a timestamp >and >if the whole element is encrypted as I'm assuming then the timestamp >will >be as secure as the decryption key so I do't understand what a separate >signature of the timestamp would add. Although a signature of the >UserNameToken combined with other parts of the message might protect >against attacks in which the encrypted UserNameToken is copied into a >different message. > > > >At 03:15 PM 3/18/2003, Hal Lockhart wrote: > > >>One of the test scenarios proposed for the interop is to pass a >> >> >username > > >>token with an encrypted password in it. I have been thinking about this >> >> >a > > >>bit recently. >> >>I would like to start by proposing a guiding principle. I believe that >> >> >these > > >>scenarios will be noted by many people and it is likely they will be >> >> >taken > > >>as guidelines for applying the constructs found in our specifications, >> >> >in > > >>some cases by those with no involvement in this TC. Therefore I >> >> >propose: > > >>While some of the interop tests may be purely intended to exercise >> >> >features > > >>of the specification, while providing little real world utility, we >> >> >should > > >>not propose any usage which is inherently insecure or represents poor >>security practice. >> >>With this in mind, I have been thinking about encrypting a password. My >>first observation is that if our goal is merely to test encryption and >>decryption code for interoperability, we could easily avoid the >>complications that follow by encrypting some user attribute instead of >> >> >the > > >>password. Unfortunately, the only user attribute we have in hand it the >>Username. Why not encrypt that? That even has a plausible usecase: a >> >> >user > > >>who wishes to remain anonymous to third parties. >> >>Assuming some will still wish to encrypt a password, in the spirit of >> >> >my > > >>principle, I will now examine the security implications of doing so. >> >>First let us get clear on the motivating usecase. As Peter Dapkus has >>pointed out, if the sender and receiver have the ability to exchange >>encrypted data, they already have available a more secure mans of >>Authentication than presentation of a password. >> >>Therefore, it only makes sense when the password is to be presented to >> >> >a > > >>backend system, such as a database or mainframe, that does not >> >> >understand > > >>the encryption. However, this case has less utility in practice than >> >> >might > > >>be thought. For performance reasons, a connection pool is typically >> >> >used to > > >>access a backend system. These connections would all be logged in to >> >> >the > > >>backend using some privileged account. Therefore the original user's >>password (and identity) will not be propagated to the backend system. >> >>When using an encrypted password, the obvious threat is a replay >> >> >attack. > > >>Assuming the key remains in use for some time, it might be thought that >> >> >the > > >>encrypted form of the password would be the same each time. However, >> >> >XML-ENC > > >>specifies the use of CBC mode for either AES or 3DES. (This is not the >> >> >only > > >>logical possibility in this case, as the typical password is shorter >> >> >than > > >>the 16 octet AES block size.) It further specifies that a different, >> >> >random > > >>Initialization Vector (IV) must be used each time. >> >>However, this is not sufficient to prevent replay unless we actually >> >> >check > > >>to see if the IV is a duplicate. If we don't wish to save every IV we >> >> >ever > > >>receive, it is necessary to include a timestamp. It might also be >> >> >desirable > > >>to duplicate the IV into a Nonce element, just to make it easier to >> >> >parse. > > >>Of course, the timestamp is not worth much unless it is signed. If we >> >> >are > > >>doing signing, it would make just as much sense to drop the timestamp >> >> >and > > >>sign over the password and message body. This would leave it up to the >>application to either detect duplicates or implement idempotent >> >> >semantics. > > >>The more I think about it the more I like encrypting the Username. >> >>Hal >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]