7 ms·
Two wrongs don't make a right. The fact that "a".hash == "\0a" hash is an issue with the hash function. nothing else. Seeding the hash function so it is unique
by b7kich 14y ago
Two wrongs don't make a right. The fact that "a".hash == "\0a" hash is an issue with the hash function. nothing else. Seeding the hash function so it is unique for each process does not solve the issue.
- 0x0 14y agoIt solves the issue where an attacker can easily prepare a chain of collisions for a DOS-type attack, doesn't it?
- b7kich 14y agoHow in the world would does the described issue with hash codes on distributed systems fix the issue of hash collisions in a request? Usually the attacker would send multiple parameters for "a","\0a","\00a" in a single request anyhow.
- 0x0 14y agoSorry, I think I misunderstood your first post then. By "the issue", I thought you were referring to the issue that the randomized-hash set out to solve (DOS attacks/pathological performance due to predictable hashes)
- martinkl 14y agoRecent versions of Ruby also use a much better hash function. Java's hash function on strings has a slightly less trivial process for generating collisions, but it's still very easy to generate enough of them to pose a DoS risk. Edit: actually, Java's String.hashCode() has exactly the same problem — prepending null chars doesn't change the hash code. And because the hash function is actually part of the Java standard library docs, it will probably never be changed (unlike Ruby's).
- spullara 14y agoThey have already announced that the hash function will be changed for Java 8 and you can enabled the change in the current version of Java 7 (u6). http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010238.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-Ma...