The cookie session store does not use a salt. On Apr 1, 2007, at 1:54 AM, PJ Hyett wrote:
This is all working under the assumption that you could determine the salt in a reasonable amount of time. -PJ http://errtheblog.com On 3/29/07, S. Robert James <[EMAIL PROTECTED]> wrote:Aside from the replay attacks discussed, there are some other attack vectors on the cookie_session store. I appreciate (and admire!) Jeremy's good humor on all of this:Planting the seed here led to quick ripening and plenty of pesticide.Thanks for the fish, all. jeremyAnyway, 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. 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. 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. 5. Key Storage One of the most common crypto truisms developers know is "Don't storepasswords in the clear". Backups are made, files are transferred, andthe 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. 6. Key ExpiryThere's no way to expire the current key without destroying all of thecurrent sessions. Keys are intended to be (relatively) permanent andrequire manual actions to change. This makes all of the above attacksboth 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. Below is a simple proof of concept code to demonstrate #1. It's simple Ruby: an optimized native version could be expected to be 100 times faster. # cookie_crumbler.rb include 'base64' include 'digest/sha2' cookie = ARGV[0] data, digest = cookie.split('--') # You can replace this with any object supporting #each, # such as a brute force generator wordlist = File.open('/usr/share/dict/words') wordlist.each do |line| secret = line.chomp if Digest::SHA512.hexdigest(data + secret) == digest puts "Secret found: #{secret.inspect}" end end--~--~---------~--~----~------------~-------~--~----~You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.To post to this group, send email to [email protected]To unsubscribe from this group, send email to rubyonrails-core- [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/ group/rubyonrails-core?hl=en-~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
