Timeline for Would multiple exposed bcrypt hashes of the same UUID v4 with random generated salt be too insecure?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 13:14 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Nov 26, 2016 at 17:56 | comment | added | Joshua | The inherent weakness is UUIDs aren't guaranteed to be generated by a crypto-RNG but a (strong) ordinary RNG. There's a story they were once generated by hashing V1 UUIDs. Whether or not the story is true it illustrates the point. UUID != CRNG. | |
| Oct 15, 2013 at 14:01 | vote | accept | Jordan | ||
| Oct 15, 2013 at 14:01 | comment | added | Jordan | Thanks makes sense, this is exactly what I'm looking for. I had an inkling that I was over-engineering and/or underestimating UUIDs, but I wanted to be on the safe side. The only thing I would dispute is the not salting part. One of the requirements is that users could be anonymous in certain parts of the application, and by not salting the UUID for hashing it would result in a hash that could be identifiable between JSON objects. Granted, it probably would be difficult and time consuming for an attacker to do this but the hashes would still be traceable without salts. | |
| Oct 11, 2013 at 20:52 | history | answered | Tom Leek | CC BY-SA 3.0 |