Great work, and an excellent analysis. Comments interspersed.
On Mar 29, 2007, at 8:23 PM, S. Robert James wrote:
Anyway, here's what we came up with:
1. Brute Force
SHA512 can be computed _very_ fast. On my Pentium Core Duo:
irb> z = 'z' * 100; puts Benchmark.measure { 1000.times
{ Digest::SHA512.hexdigest(z) }}
0.032000 0.000000 0.032000 ( 0.031000)
That's 0.03 ms/hash using simple Ruby code, not optimized C /
Assembly!
That means a simple brute force attack can go through the entire
dictionary in a few seconds. Even using multiple word phrases, and
inserting several digits, we can complete the attack in reasonable
time. We can even search brute force letter combinations, esp. if we
only generate pronouncable phoneme combinations.
2. Entropy
Related to #1: to resist brute force attacks, you really want 128
bits, and preferably 256 bits, of entropy. The source code suggests
"some secret phrase", which is unlikely to come even close. The way
to create a key is to use a PRNG seeded with true, system level
entropy.
Agreed that "some secret phrase" will not yield 256 or even 128 bits of entropy. But the Rails app generator uses a version of generate_unique_id, which uses just about all of the system-level entropy available to Ruby. Granted, it's an MD5 hash (thus an upper limit of 128 bits of entropy), not a cryptographic PRNG, but it is better than a user-entered phrase by far.
3. Rainbow Tables Since there will be standard data common among many apps (eg null sessions), and no salting is employed, we can use create Rainbow Tables, and afterwards find the secret very quickly.
The developer must set a session cookie name, and all of the examples given so far use "_appname_session". So there is a security advantage to choosing your own session key name and keeping it secret (otherwise an attacker can create a rainbow table specific to your application).
4. Precomputation Cookie session computes the hash by *appending* the secret to the data. This can be used to speed up the brute force, by precomputing the hash of the data, and starting the hash function on the candidate session. The correct way to use the key is to repeatedly XOR it to the data, not append it.
Excellent point.
5. Key Storage One of the most common crypto truisms developers know is "Don't store passwords in the clear". Backups are made, files are transferred, and the bad guys job is made too easy. In cookie_store, the app's key is stored directly in the clear. No ephemeral key is used. If an attacker see's this, it's equivalent to getting *everyone's* password. Even worse, since he can create arbitrary sessions. To make matters worse, the source code seems to suggest storing the key in the app's source code itself. So, every developer, every subversion check out, every code base back up, has the key.
I would assume they'd throw a YAML.load from a config file in there before pushing this to stable. But you're right, this is considerably different than a database password.
I'm not sure how an ephemeral key would work given that sessions may stick around arbitrarily long... were you suggesting that there is a solution, or were you only pointing out the problem?
6. Key Expiry There's no way to expire the current key without destroying all of the current sessions. Keys are intended to be (relatively) permanent and require manual actions to change. This makes all of the above attacks both easier and more dangerous. 7. Key / Session Revocation Likewise, should you suspect key compromise - to revoke the key, you need to destroy all of the current sessions. And there's also no way to revoke an individual session, should you get a call "uh, I logged in at the library yesterday and now someone's reading my mail". Some of the above can be corrected easily. Some are much more challenging. I think they all should demonstrate that creating a crypto system is quite formidable.
This has been very enlightening. Thanks for taking the time to write this up.
--be
smime.p7s
Description: S/MIME cryptographic signature
