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

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,
individual attributes. I don't know if its possible to encrypt
attributes but all the examples in our drafts have been of whole

With regards to replay attacks, a UserNameToken can contain a timestamp
if the whole element is encrypted as I'm assuming then the timestamp
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
>token with an encrypted password in it. I have been thinking about this
>bit recently.
>I would like to start by proposing a guiding principle. I believe that
>scenarios will be noted by many people and it is likely they will be
>as guidelines for applying the constructs found in our specifications,
>some cases by those with no involvement in this TC. Therefore I
>While some of the interop tests may be purely intended to exercise
>of the specification, while providing little real world utility, we
>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
>password. Unfortunately, the only user attribute we have in hand it the
>Username. Why not encrypt that? That even has a plausible usecase: a
>who wishes to remain anonymous to third parties.
>Assuming some will still wish to encrypt a password, in the spirit of
>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
>backend system, such as a database or mainframe, that does not
>the encryption. However, this case has less utility in practice than
>be thought. For performance reasons, a connection pool is typically
used to
>access a backend system. These connections would all be logged in to
>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
>Assuming the key remains in use for some time, it might be thought that
>encrypted form of the password would be the same each time. However,
>specifies the use of CBC mode for either AES or 3DES. (This is not the
>logical possibility in this case, as the typical password is shorter
>the 16 octet AES block size.) It further specifies that a different,
>Initialization Vector (IV) must be used each time.
>However, this is not sufficient to prevent replay unless we actually
>to see if the IV is a duplicate. If we don't wish to save every IV we
>receive, it is necessary to include a timestamp. It might also be
>to duplicate the IV into a Nonce element, just to make it easier to
>Of course, the timestamp is not worth much unless it is signed. If we
>doing signing, it would make just as much sense to drop the timestamp
>sign over the password and message body. This would leave it up to the
>application to either detect duplicates or implement idempotent
>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]