Encrypting a password

["Hal Lockhart" <hlockhar@bea.com>]

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