RE: [wss] Current user-name password construction requires plain textpassw ord at server

[Hal Lockhart <hlockhar@bea.com>]

> Preventing ws clients from sending plain text passwords is
> something, which definitely needs to be addressed by WSS, but
> I'm not sure if the approach of rehashing (i.e.
> password_digest= SHA1[nonce + created + SHA1[password]]) will
> lead to a interoperable solution. When rehashing, different choices
> will be needed:
> a choice of:
>  - hash algorithms (md5, SHA1)
>  - system specific salts and other (i.e. user specific)
> constants that may be included in the hashed value
> These will probably produce a huge set of interoperability
> problems. To prevent these, we should limit the
> username/password to the simple digest case.

The main problem with a salt is that it requires an extra message of some
sort, as the salt for that partucilar user will not be know to the node
collecting the password.
>
> When the password is not available in plain text, the
> password should be encrypted using a public key of the
> (ultimate) receiver. This could either be done using XML
> encryption, or we could extend the UsernameToken to directly
> support this. Specifying which public key should be used for
> encrypting
> needs to be part of WS SecurityPolicy.

Hold on a second here. The whole reason for the hashed MAC scheme is in the
(common) case where we do not have a PKI available to us. When we do, we
should use it directly. In this case, generate a PK signature over the
message and don't use a password at all.

Hal