RE: [wss] Encrypting a password

["Chris Kaler" <ckaler@microsoft.com>]

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