Is RC4 a problem for password-based authentication?

Question

This is a follow-up question to Does TLS use RC4-drop[n]?.

As mentioned in section 6 of RFC4345, there are weak distinguishers for RC4 keystreams available that even work for keystreams that originate from different keys, and regardless of the distance from the start of the keystream. Doesn't that make an attack on schemes that send user passwords in RC4 protected connections?

I'm thinking about protocols that always send the password at a well known offset, e.g. TLS protected IMAP and SMTP.

Theoretically, it should even be possible with an HTML authentication form, but the position of the password in the response might not be as obvious in that case.

Has anybody ever tried to recover a password from a number of RC4 protected IMAP or (authenticated) SMTP connections? Because of the BEAST attack, many mail services now default to RC4 for encrypting user connections (which always include the credentials at a fixed offset), and depending on the mail client used, authentication might happen frequently (especially IMAP clients often keep a number of IMAP connections open, which might be forced to reconnect even more frequently by an active attacker).

Answer 1

By George, you're on to something.

To answer the question you asked, I don't know of anyone actually attempting to recover a password this way, or it even being discussed. However, it does appear to be feasible, given enough encrypted streams.

How many are enough? Well, I've started running a few simulations; preliminary results indicate that with perhaps 2 billion encrypted streams that encode the same password, the attacker may be able to deduce enough information to narrow possible passwords to a reasonably small set.

I'll update this answer as I get more precise information on the number of streams needed; however, I've seen enough to be fairly confident that this attack can work.

UPDATE

I have experimentally verified the fact that you can decrypt RC4 if you get the same message encrypted enough times, albeit with somewhat more than I suggested above. In particular, I encrypted a 16 character password using RC4/DROP-512. With 8 billion encrypted messages (with the RC4 key for each message being chosen randomly and independently), I was able to successfully recover the exact password by analyzing the statistics for the streams.

I'll be writing up an eprint article detailing my observations.

Answer 2

I don't know of any practical attacks along these lines that pose a realistic threat in practice, on any current protocol.

Let me explain. There are two standard kinds of distinguishing attacks on RC4:

• The first two bytes. Mantin and Shamir showed that the second byte of output from RC4 is biased. If the password was always encrypted at the very start of the connection, and if you observed hundreds of connections all using the same password, this attack might allow an eavesdropper to recover the second character of the password.

  However, I do not know of any protocol that sends the password right at the very beginning of the connection (usually there are some headers and set-up stuff that gets encrypted first). Also, the requirement to eavesdrop on hundreds of connections might also make this less practical. Therefore, I don't know of any practical attack on real-world systems that exploits this kind of distinguisher.

• Arbitrary locations in the stream. Others have shown distinguishers that can work at an arbitrary offset in the output stream. These might be applicable, if the password is always sent at a known offset from the start, and if the user makes many connections all with the same password.

  However, all such known attacks would require observing billions of connections before you start to learn anything about the password. It seems hard to imagine a user typing in the same password billions of times. Or, even if we postulate a system that automatically retries the connection and sends the user's password automatically, still this seems like a rather far-fetched attack. The eavesdropper would need to capture a lot of traffic. For these reasons, I don't know of any practical attack of this sort on a real-world protocol.

That said, you have a good point. These attacks show that RC4's security is fragile: it is not as robust as we would like. With improvements in technology (e.g., faster machines making many more connections), or with bad luck in how a protocol happens to be designed, it is not implausible that such an attack might be possible someday on some future protocol. This is a good reason to avoid use of RC4 in new systems. (There are other good reasons to avoid RC4 in new designs, too.)