Does digested passwords send over a non encrypted channel offers additional security over plain text passwords?

Question

I am learning about WS-Security and trying to compare different options offered by UsernameToken as described in this document.

AFAIK, a digested password is a hash of the plain text password along with a nonce and a date. This prevent replay attacks and the need to send the plaintext password :

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

According to the document what will be send is something like this :

<wsse:Security>
    <wsse:UsernameToken>
        <wsse:Username>NNK</wsse:Username>
        <wsse:Password Type="#PasswordDigest">weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>
        <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
        <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
    </wsse:UsernameToken>
</wsse:Security>

What I don't understand is this part (page 6) :

Passwords of type PasswordDigest are defined as being the Base64 [XML-Schema] 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.

AFAIK If some attacker is able to catch the password digest the only thing he can do to find the password is to brute force it (to try all possibilities until it match the hash). To me it seems much secure than sending the plain text password. I must be missing something.

Answer 1

Brute-forcing a single round of SHA1 is extremely fast. An individual high-end graphics card can compute billions of such hashes per second; by parallelizing it even further (using multiple cards, cloud services, or custom hardware) the rate can be driven to even greater orders of magnitude. While the nonce and timestamp prevent building a rainbow table, modern hash cracking is so fast that it scarcely matters anymore. The slowest part, by far, of creating a rainbow table or any other persistent hash lookup table is simply the time to write it to storage.

Digest auth can hide your password, but doesn't protect the data itself. Without encryption, an attacker can read all data passing in both directions. Without integrity checks, an attacker can tamper with the messages, even to the extent of completely replacing your requests or the server's responses. Additionally, if you haven't authenticated the server in some way (typically, this is done during a TLS handshake by the server providing a trusted certificate and proving it has the corresponding private key, but it could also be done using a password of some sort) then you don't even know if you're communicating with the server you think you are; an attacker might have spoofed your DNS or ARP, or compromised some node along your path, etc.

This scheme means the server must store the passwords in plain text or under reversible encryption, because it cannot apply further hashing to the password part alone (in order to match the hashing used before storing in the database). Client-side hashing like this can protect the password itself from a network attacker, but only be exposing every password in the system if the server / its auth database gets compromised.

If sites A and B both use this protocol, and the attacker wants to get into your account on A but A uses a secure channel (such as HTTPS) and B does not, then the attacker can attempt the following:

1. Obtain a man-in-the-middle position between you and B.
2. Attempt to access A (via its secure channel), receiving an auth challenge with a nonce in it.
3. Spoofing your communication with B to present the nonce that the attacker got from A.
4. Your client hashes your password using this nonce (which is actually for A, not B), and the attacker intercepts your UsernameToken.
5. Attacker replays your token to A, along with the request that the attacker wants to make in your name. Because the token was constructed using the nonce for A, A accepts it. Because the token contains no information about what service its intended for use with, neither the server nor the victim realize that the they crafted a token for a different site (although the victim might think something's up when B rejects the token... but the attacker can suppress any awkward response messages.)

This type of attack - passing the hash intended for one server to a different one, and thus accessing the other server using the victim's account - is a very common way to compromise any system that relies on client-side hashing (even with a server-supplied salt/nonce) when the same password is used in multiple places.