Re: [wss] Encrypting a password

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

I've been assuming that only the password would be encrypted,
and not the entire message.

My goal, which I've stated earlier on this list and at the meeting
in Baltimore, is to try to convince WSS to add an optional XCBF
biometric parameter to the Username token. This would be used
to augment the current login/password capability.

An XCBF token component would itself be signed and encrypted,
but would be treated for the purposes of WSS as an opaque object
(much like an X.509 certificate), whose structural details were hidden
from WSS.

This optional parameter would not be decrypted by WSS. The XCBF
token would be handed off to some Biometric Service Provider for all
processing. So the details of this processing, both cryptographic and
biometric, would not need to be specified by WSS.

Phil Griffin


Jerry Schwarz wrote:

>
> 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
>
>
>