|
Re^2: Please Review First Program: Random Password Generator
by hakkum (Acolyte) on Feb 03, 2011 at 23:28 UTC
|
Thanks ikegami. If I understand you correctly, you mean to place each included character randomly in the character pool list first, then randomly select a position from that list (per iteration). That makes a lot of sense. I will implement that.
-- hakkum
...never forget the hakkum bakkum,
the hakkum bakkum never forgets...
| [reply] |
|
|
use List::Util qw( shuffle );
my @passwd;
push @passwd, $letters[ rand(@letters) ] for 1..$num_letters;
push @passwd, $digits[ rand(@digits ) ] for 1..$num_digits;
push @passwd, $symbols[ rand(@symbols) ] for 1..$num_symbols;
push @passwd, $chars[ rand(@chars) ] for 1..($length-$num_letters-
+$num_digits-$num_symbols);
my $passwd = join '', shuffle @passwd;
| [reply]
[d/l] |
Re^2: Please Review First Program: Random Password Generator
by educated_foo (Vicar) on Feb 05, 2011 at 03:20 UTC
|
If you want a truly random password, each symbol should be chosen uniformly from the set of legal symbols. Otherwise, a cracking program can instantly eliminate all-letter passwords. Passwords work best when every possible password string is equally likely. | [reply] |
|
|
If you want a truly random password
Why would you want that? "password" is a perfectly valid password in that world.
You assume that the cracker knows and cares that your password is truly random. That's a bad assumption to make.
Otherwise, a cracking program can instantly eliminate all-letter passwords.
That's exactly what my suggestion defends against. Before my change, someone who has the hashes of all alphabetic passwords could crack some of the generated passwords instantly. With my change, if configured correctly (probably x=1,y=1,z=1, but least one for each), no such fluke is possible.
| [reply] |
|
|
I do see what you're getting at. I agree to some extent. It is assumed that if the user does not use the -L -N or -S options, he/she would like the generated password to include at least one character from each. Thus separating each group and ensuring that one from each is generated prior to randomly selecting the remaining characters is optimal. But I think it should end there. IE if the user wants a nine character password, three of each letters, numbers, and symbols is not needed; rather one of each and the rest given an equal opportunity (Shuffling the results).
I did not intend for this to have any production value, but continually modifying the code with that goal in mind can only strengthen my education. Thanks again for the comments to all.
-- hakkum
...never forget the hakkum bakkum,
the hakkum bakkum never forgets...
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
Re^2: Please Review First Program: Random Password Generator
by zwon (Abbot) on Feb 05, 2011 at 03:01 UTC
|
I'd force the inclusion of a certain amount from each set.
This will decrease the number of possible password combinations, and actually make password weaker. What password is stronger? The one which includes 8 characters from the [A-Z0-9] set, or one which includes 6 characters from the [A-Z] and 2 from [0-9]?
| [reply]
[d/l]
[select] |
|
|
This will decrease the number of possible password combinations,
Yes.
and actually make password weaker
No.
In general, the second does not necessarily follow from the first. Blacklisting password "password" decreases the number of possible combinations, for example.
In this particular case, it also makes the password stronger since the hashes of all alphabetic passwords of length 14 or less are known. (I don't remember for which hashing algorithm.)
What password is stronger? The one which includes 8 characters from the [A-Z0-9] set, or one which includes 6 characters from the [A-Z] and 2 from [0-9]?
The one that includes 1 from [A-Z], 1 from [0-9] and 6 from [A-Z0-9].
| [reply] |
|
|
since the hashes of all alphabetic passwords of length 14 or less are known. (I don't remember for which hashing algorithm.)
Are you seriously suggesting that the blackhats can call on a database/lookup table of 26^14 * 14+16 = 1.5 Zetabytes of storage for cracking passwords?
For reference, the best figure I can find for Google's storage total is 220 TB, which means that these blackhats would need 7 million times the infrastructure as Google to store this table. Even if 10:1 compression was possible, that's still 700.000 Googles hiding away on the internet somewhere.
Even if they compressed the data and held it on tape, they'd still need 1000+ of these all fully populated to hold it. And each of those 1000 systems would cost 7 digits to buy.
Yes, I've heard of rainbow tables, but they don't address the fundamental problem much.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
In general, the second does not necessarily follow from the first. Blacklisting password "password" decreases the number of possible combinations, for example.
Using digits not necessarily mean that generated p@ssw0rd wi11 be more resistant against dictionary attacks. In fact 0, 1, 4, 5, 7 may be used as replacements for often used characters, so I won't be surprised if probability that random password matches some dictionary word higher for alphanumeric passwords than for just alphabetic.
| [reply] |
|
|
hashes of all alphabetic passwords of length 14 or less are known. (I don't remember for which hashing algorithm.)
I suspect you talking about Ophcrack tables for LM hash. First, they are not alphabetic, they include also digits and other characters. Second, 14 character LMhash is practically consist of two 7 character passwords
| [reply] |