Yes, of course, but all (cryptographic) hash functions are "vulnerable" to brute force attacks. It's just a question of effort/time.
The salt used in mod_log_iphash is 128 characters long. So we have 64^128 + 2^32 (for the concatenated IPv4 address) possibilities. If you want you can increase SALT_SIZE. The salt is not exposed. But it can be read in memory though. On 06.10.2010 00:51, Ted Dunning wrote: > If you really want security, you should note that exhaustive search will > crack this kind of hashing pretty quickly. > > Changing the salt and making sure that nobody knows what the salt is helps a > little bit. > > On Tue, Oct 5, 2010 at 3:49 PM, Franz Schwartau <fr...@electromail.org>wrote: > >> Hi! >> >> I wrote a small module to fulfil a privacy policy where logging of the >> ip address is not allowed. It adds a new directive to LogFormat which >> generates a MD5 hash of a "salted" ip address. It makes it look like a >> IPv6 address. Thus statistics tools like AWstats have a chance to work. >> >> Unfortunately writing a module isn't documented well. So some issues are >> still open. The source code is available on github: >> >> http://github.com/franzs/mod_log_iphash >> >> How should the module react to a failed initialization of seed_rand() in >> iphash_create_server_config() (line 90)? Returning NULL in >> iphash_create_server_config() doesn't seem to help. I'd like to disable >> the module somehow if the random generator could be initialized properly. >> >> No other module checks if the return value of apr_palloc() or >> apr_pcalloc() is NULL. Does it mean memory allocation via apr_palloc() >> will never fail and memory size is indefinitely? ;-) >> >> If you find other issues in mod_log_iphash please let me know. This is >> my first module so please be gentle... :-) >> >> Best regards >> Franz
