4 ms·

Isn't it trivially easy to defend against by adding a secret character/number to all of your keys, eg.: "dog" becomes "dogu" and "julia" becomes "juliau"? In f

by ced 15y ago

Isn't it trivially easy to defend against by adding a secret character/number to all of your keys, eg.: "dog" becomes "dogu" and "julia" becomes "juliau"? In fact, why not do this at the language level? python could pick a random character at startup, and use it for the duration of the process.

mikeash 15y ago
A single character wouldn't be any good, since it would be trivial to discover which one was in use by brute force. A longer salt would probably work, but there may well be ways for an attacker to discover the salt in use, and longer salts mean more overhead.
- deleted 15y ago
  [deleted]
- obtu 15y ago
  A single pseudorandom byte chosen at container initialisation would work here, because url hashes are ephemeral. Persistent structures on the other hand are already DOS-prone, but need attacks more tailored to the application.
  - mikeash 15y ago
    Even with a random per-initialization byte, you could still brute force it. Pick a random byte on your side, generate colliding keys with it, and send the request. If it doesn't work, just try again until it does. You'd expect to only have to try this ~256 times before succeeding, still seems pretty practical. Of course, bump this up to 2-4 bytes and it no longer is.
    - oconnore 15y ago
      256 attempts is the upper bound. The expected value of attempts should be 128.
Groxx 15y ago
I believe this is similar to what Ruby 1.9.x does, and why it's not vulnerable - it uses a varying initialization value for the hashes, so you can't collide every time. When they initialize it (per process, per initialization?) and what exactly it does, I don't know, but yeah. Greater overhead, less predictability, greater complexity, though all of them are essentially minor. It's not the sort of thing that tends to make it into a library until there's demonstrated need.
reinhardt 15y ago
From the relevant Python-dev thread, it's probably a bad idea for more than one reasons to make this the default behavior for all dicts; a special dict subclass to be used when necessary makes more sense: http://mail.python.org/pipermail/python-dev/2011-December/115123.html http://mail.python.org/pipermail/python-dev/2011-December/11...

by ced 15y ago

mikeash 15y ago

A single character wouldn't be any good, since it would be trivial to discover which one was in use by brute force. A longer salt would probably work, but there may well be ways for an attacker to discover the salt in use, and longer salts mean more overhead.

deleted 15y ago
[deleted]
obtu 15y ago
A single pseudorandom byte chosen at container initialisation would work here, because url hashes are ephemeral. Persistent structures on the other hand are already DOS-prone, but need attacks more tailored to the application.
- mikeash 15y ago
  Even with a random per-initialization byte, you could still brute force it. Pick a random byte on your side, generate colliding keys with it, and send the request. If it doesn't work, just try again until it does. You'd expect to only have to try this ~256 times before succeeding, still seems pretty practical. Of course, bump this up to 2-4 bytes and it no longer is.
  - oconnore 15y ago
    256 attempts is the upper bound. The expected value of attempts should be 128.

Groxx 15y ago

I believe this is similar to what Ruby 1.9.x does, and why it's not vulnerable - it uses a varying initialization value for the hashes, so you can't collide every time. When they initialize it (per process, per initialization?) and what exactly it does, I don't know, but yeah. Greater overhead, less predictability, greater complexity, though all of them are essentially minor. It's not the sort of thing that tends to make it into a library until there's demonstrated need.

reinhardt 15y ago

From the relevant Python-dev thread, it's probably a bad idea for more than one reasons to make this the default behavior for all dicts; a special dict subclass to be used when necessary makes more sense: http://mail.python.org/pipermail/python-dev/2011-December/115123.html http://mail.python.org/pipermail/python-dev/2011-December/11...