OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]