Are GUIDs good passwords? [closed]

问题:

Pros:

1. I can't remember "good" passwords anyway so remembering them is not an issue.
2. they don't look like passwords
3. they are darn near impossible to guess (128 bits of entropy)
4. easy to generate (offloads the "good PRNG" problem)

Cons:

1. ???

In particular; what about for passwords that computers enter like for databases logins on some setups.

回答1:

One major con is that you don't necessarily have "128 bits of entropy" as stated in the original question.

Many GUID Algorithms have information embedded in them in predictable patterns, for example the MAC address of the computer, the date/time, or an incrementing sequence. Cryptanalysis of the WinAPI GUID has shown given the initial state one can predict up to next 250,000 GUIDs returned by the function UuidCreate

For example, I have about a 50% chance of guessing the first digit in the first position of the third group of digits since it will be either 1 (for V1 guids) or 4 (for V4 guids)

Source: http://en.wikipedia.org/wiki/Globally_Unique_Identifier

回答2:

Cons:

1. You will write them down somewhere.
2. You will probably email them, or write them down again if you need to tell anyone else.
3. They may be too long for certain systems.
4. They're practically impossible to memorize, so you might change them more frequently then desired.

So unless they're system passwords which change rarely, I doubt they are good passwords.

回答3:

Con:

It would be nearly impossible to remember a 32-byte alpha numeric string.

回答4:

If you really want a secure password, consider a passphrase instead. A long passphrase is easily remembered, and very difficult to brute force.

回答5:

Con:

• Some systems have limits on the maximum length of passwords. If you're only using hex digits this can limit your entropy to perhaps as little as 32 bits.

回答6:

Does anyone ever need to enter it as a password? Or do you want to use it as a one-time thing? Because seriously, no one wants to enter a GUID in a passwordfield. People have trouble enough as it is, entering WEP/WPA2 wifi network keys. And most of the time, those are one-timers.

@Miyagi: that's the most obvious con ofcourse. They'll have to write it down.

回答7:

Technically they would be good passwords In real life, they would be horrible passwords

You would end up having to write down the passwords, use a password manager, or some other form to actually use the password... in a way moving the failure point from the password to another aspect.

Consider using passphrases. Sentences with substitutions for certain letters or other characters, and for numbers, typing them with the SHIFT, converting easy to remember numbers in to well defined character sequences.

For example bcs19850101bcs would be bcs!(*%)!)!bcs

回答8:

Cons:

1. Password fields are not always long enough.
2. More difficult to enter - you'd probably store the password in a program, not in your head. That's a bit of a security problem...

... pros:

1. Nobody will be able to force your password out of you.

Big-random-number passwords have been done before. They're called OTPs, and are much more secure than what you're suggesting because they change over time, and tend to be generated by secure devices. Of course this is only relevant if you are designing a password system.

回答9:

If you want a secure password that you wish to leave to a password manager on a UNIX-like system, you're much better just pulling one from /dev/random and encoding it into something readable. for 128 bits of entropy you can use something simple like

head -c 16 /dev/random | openssl enc -a -e

which gives a password like 5eqIviKu4pFTqSPnYosVKg==

not unreasonably long, secure, random, suicide to try to remember.

Edit: added benefits of this method over UUID include extra security in the PRNG (/dev/random) and shorter passwords, similar shortfalls

回答10:

I recently wrote code to convert the first 64 bits of a checksum into a sequence of four English words. This makes a good checksum (much easier to remember than a hex mess), but I'm not sure I'd trust it as a password. If you're protecting something secure, you should use a strong password that you memorize and don't write down. If not, then any old password will do.

回答11:

I think what you actually want is a cryptographically-random number, not a GUID. GUIDs and UUIDs are not random -- as JohnFx said, they tend to incorporate discoverable values like the MAC address or current timestamp, in order to guarantee uniqueness.

Instead, you should look at whatever crypto API is available to you and find a source of high-entropy random numbers. Make sure the documentation promises the output is suitable for cryptography, not just a regular PRNG. For example, /dev/random on Unix systems is a good source. Then just unroll as many random bytes as you want.

Personally this seems a bit too hardcore. I'd rather generate strings that contain a bit less entropy per character, but are easier to type and remember. For example, there are several algorithms that combine random syllables to create pronounceable nonsense words; intersperse some digits and punctuation, and you've got a good password.

回答12:

I like my passwords strong and pronouncable (try one of the sites listed here for an online demo, be sure to pick a "v2" site to get the pronounciation-guide).

回答13:

Con: You can't retype it, which means you will have to copy and paste. If you have your password management program on your system, not really a problem. But if you end up on a system where you don't, just retyping the thing will be very difficult.

And then after you try a couple of times you get locked out ....

Life could get very annoying.

Even if you write it down, a good password is something you can type consistently without errors.