User Names and Passwords

The <wsse:UsernameToken> element is introduced in SOAP Message Security documents as a way of providing a user name.

Within a <wsse:UsernameToken> element, a <wsse:Password> element can be specified. Passwords of type PasswordText and PasswordDigest are not limited to actual passwords, although this is a common case. Any password equivalent such as a derived password or S/KEY (one‑time password) can be used. Having a type of PasswordText merely implies that the information held in the password is "in the clear", as opposed to holding a "digest" of the information. For example, if a server does not have access to the clear text of a password but it does have the hash, the hash is considered a password equivalent and can be used anywhere where a password is indicated in this specification.

Passwords of type PasswordDigest are defined as being the Base64‑encoded, SHA‑1 hash value, of the UTF8‑encoded password (or equivalent). However, unless this digested password is sent on a secured channel or the token is encrypted, the digest offers no real additional security over use of wsse:PasswordText.

Two optional elements are introduced in the <wsse:UsernameToken> element to provide a counter‑measure for replay attacks: <wsse:Nonce> and <wsu:Created>. A nonce is a random value that the sender creates to include in each UsernameToken that it sends. Although using a nonce is an effective counter‑measure against replay attacks, it requires a server to maintain a cache of used nonces, consuming server resources. Combining a nonce with a creation timestamp has the advantage of allowing a server to limit the cache of nonces to a "freshness" time period, establishing an upper bound on resource requirements. If either or both of <wsse:Nonce> and <wsu:Created> are present, they must be included in the digest value, as follows.

Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )

This concatenates the nonce, creation timestamp, and the password (or shared secret or password equivalent), digests the combination using the SHA‑1 hash algorithm, then includes the Base64 encoding of that result as the password (digest). This helps to obscure the password and offers a basis for preventing replay attacks.

For Web service providers to effectively thwart replay attacks, three counter measures are recommended. It is recommended that:

• Web service providers reject any UsernameToken not using both nonce and creation timestamps.

• Web service providers provide a timestamp "freshness" limitation, and that any UsernameToken with "stale" timestamps be rejected.

  As a guideline, a value of five minutes can be used as a minimum to detect, and thus reject, replays.

• Used nonces be cached for a period at least as long as the above timestamp freshness limitation period, and that UsernameTokens with nonces that have already been used (and are thus in the cache) be rejected.

Note that PasswordDigest can be used only if the plain text password (or password equivalent) is available to both the requestor and the recipient.