How does Nginx look-up cached resource?

Sergey Brester serg.brester at
Mon Sep 7 21:22:25 UTC 2015

On 07.09.2015 21:29, Gena Makhomed wrote:

> Using MurmurHash is not good idea, because attacker
> can easy make collisions and invalidate popular entries
> from cache, and this technology can be used for DDoS attacks.
> (even in case if only one site exists on server with nginx cache)
> Using secure hash function for nginx cache is strong requirement,
> even in case then full proxy_cache_key value check will be added.

It's not correct, because something like that will be called "security 
through obscurity"!

Hash value should be used only for fast searching of hash key. Not to 
identify the cached resources!
If your entry should be secure, the key (not it hash) should contain 
part of security token, authentication, salt etc.

So again: hash bears no security function, and if the whole key would be 
always compared - it would be at all not important which hash function 
will be used, and how secure it is. And to "crack" resp. return the 
cache entry you should always "crack" it completely key, not it hash.

As I already said, the hash value - is only the way to fast searching 
resp. even direct access to entry with the hashed key.

I know systems, where the hash values are 32 bits and uses simplest 
algorithm like Ci << 3 + Ci+1. But as already said, hereafter the whole 
keys will be compared and it's very safe.
So for example if you should cache the pages per user, give the 
authenticated user-name in the cache key (value given with 
proxy_cache_key). Then the attacker should crack the nginx 
authentication also.

Everything else would be as already stated - security through obscurity.


More information about the nginx-devel mailing list