Don’t Use GUIDs As Passwords
This is a really bad idea. GUIDs are designed for uniqueness, not for security.
For example, we saw that substrings of GUIDs are not unique. For example, in the classic v1 algorithm, the first part of the GUID is a timestamp. Timestamps are a great technique for helping to build uniqueness, but they are horrifically insecure because, well, duh, the current time is hardly a secret!
2 Comments RSS · Twitter
Important clarification comes in the comments:
[The scenario under consideration (which I failed to communicate clearly) is that there is one machine that is responsible for generating new accounts and their temporary passwords. Therefore, once you get one temporary password, you have the MAC address of the password generator machine, and that leaves only the timestamp as a source of variability, and timestamps can be guessed. -Raymond]
Saying that GUIDs make for bad passwords as long as they are v1 GUIDs is a bit like saying that vaguely pronounceable strings make for bad passwords as long as they are pet names.
Generate a v4 GUID and you're already got tons of entropy, minus the fixed bits. Generate a random 128 bit number and format it in the form of a GUID and it's got more entropy. Add non-alphanumerical characters and you're laughing. (And for the finale, Ascii85 that sucker...)
What Raymond is saying is basically: a substring of anything with uniqueness guarantees, like a GUID or a hash, does not maintain those guarantees. I would have hoped that was obvious. I also would have hoped that people still generating v1 GUIDs (other than for purposes of mostly guaranteed namespaced non-collision per the steal-a-MAC, destroy the card, then generate a v1 GUID method) shouldn't be trusted around secure code to begin with, at least not in 2015.
