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.

Regards,
sebres.

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel