One-line password generator.
- Inicie sesión o regístrese para enviar comentarios
I have the following line in my Bash init file. I am sharing it with you in case you
find it useful:
“alias gen-password="head -c 16 /dev/urandom | base64 | head -c 22 && echo"”
This generates a password with just above 128 bits of entropy. I generate all of my web site passwords this way.
Some people do not recommend “memorable passwords” at all. The reasons are as explained next.
If the password is not important (for example, account of web forums) then you can use store it in a plain text file or a password manager. Firefox has a built-in password manager which works fine. Here memorability does not matter at all, as you just have to copy and paste, or let the password manager fill it automatically. Anyway, one could not memorize enough passwords for all the things that require one (esp. web sites).
If the password is important, then for a reasonable amount of entropy, a memorable password will be too long and VERY slow to input. I suggest the following approach:
Generate a 3-byte long password, for example:
mario@svetlana [0] [/home/mario] $ head -c 3 /dev/urandom | base64 w5eJ
Write it in a paper or leave it in the terminal. Invent a mnemonic for it or just memorize as is. In this case, I can think of “_
Sorry, the message was truncated and I can not modify it. Here is the rest:
mario@svetlana [0] [/home/mario] $ head -c 3 /dev/urandom | base64 w5eJ
Write it in a paper or leave it in the terminal. Invent a mnemonic for it or just memorize as is. In this case, I can think of “_W_ill has _5_ fingers in _e_ach _J_and (hand spelled wrong)”.
Several times through the day, try to remember the password and *then* look at the paper or terminal to check. Allow yourself 1 day to memorize it, then if you used a paper, either *eat it* or chew it until it is an homogeneous blob and then spit it. Repeat this for several days. Your password at the end is the *concatenation* of all these 4-character chunks in the order generated.
If at some point you get a chunk that is hard to memorize, you can discard it and try again. Discarding removes some entropy but I do not think it is significant (as a *rule of thumb*: You can choose the “best” of 4 tries for any block and lose only 2 bits of entropy; if you do this each block for 4 blocks, then you still have 88 bits of entropy). To assure that each chunk gives the maximum amount of entropy (24 bits) you must commit yourself to use whatever is generated, that is, without discarding. I recommend the “best of 4” approach: I.e.: Generate 4 chunks each day and memorize the one you prefer. The other 3 should be discarded.
Each chunk gives 24 bits of entropy. I recommend to use a 4-chunck long password, for 96 bits of entropy. In my opinion, there is no point in a longer password; the attacker would simply kidnap you and give you amobarbital instead of trying brute force. 5 chunks give 120 bits, which is IMO is enough for *any* password that can be trusted to a single person. For stronger security requirements, one should instead require N of M good passwords to unlock the ICBM and then distribute the individual passwords as appropriate.
Regards.
Passwords were discussed many times here. https://trisquel.info/forum/what-are-your-favorite-encryption-programs-or-methods probably is the last thread about it. Here is the solution I suggested, where "words" tunes the number of words in the password (here four) and "dic" is the hunspell dictionary (choose a language you know) the words are taken in:
$ words=4; dic=/usr/share/hunspell/en_US.dic; max=$(wc -l < $dic); for i in $(seq $words); do r=$(od -A n -N 4 -t u4 /dev/random); cut -d / -f 1 $dic | sed -n $(expr $r % $max + 1)p; done | tr '\n' ' '
I have just run it four times. Here are the passwords it output:
suckle tattler captivity pointblank
bootprints does jeweler turbinate
prohibitive revealingly Jenelle femoral
bedding Alexandre Ase pathogenesis
They are certainly *much* easier to remember (and probably faster to type) than "pvQx697b88nfDJKv8LQ4Mg" (password your first command can output) and much stronger than "w5eJ". It *does* make a difference: script kiddies that got a database dump of cryptographically hashed passwords (it frequently happens) crack "w5eJ" in a split second. Literally. Indeed your second command can only generate 64^4 = 16,777,216 different passwords and, according to Bruce Schneier in 2006:
Current commercial products can test tens -- even hundreds -- of millions of passwords per second. At the same time, there's a maximum complexity to the passwords average people are willing to memorize (.pdf). Those lines crossed years ago, and typical real-world passwords are now software-guessable. AccessData's Password Recovery Toolkit -- at 200,000 guesses per second -- would have been able to crack 23 percent of the MySpace passwords in 30 minutes, 55 percent in 8 hours.
Since /usr/share/hunspell/en_US.dic contains 62,155 different words, the command I gave above can output 62,155^4 = 15 billion billion (sic) different passwords. A tool that tries one billion passwords per second takes more than 236 years (in average, knowing the password is four words in /usr/share/hunspell/en_US.dic) to crack the password. Against more serious enemies (e.g., a state agency targeting you) "capable of one trillion guesses per second" (as Edward Snowden wrote to Laura Poitras, as shown in Citizenfour) that number decreases to 86 days.
Notice also that my solution uses /dev/random, not /dev/urandom. /dev/urandom providing only pseudo-randomness, there is a risk (although it should be OK) of a bug that would help the cracker. For instance, a classical (but bad) way to seed pseudo-random number generators is to use the C function "time". It returns the current number of seconds since January 1, 1970. Knowing the year the password was generated (and the pseudo-random number generator that was used), only 31 million passwords need to be tried because there are 31 million seconds in a year: back to a split-second crack (no matter how long the password).
I can see you replied with the attitude of “I am smarter than you”, but you just succeeded in showing your incompetence.
Your method gives at most 15.9 bits of entropy per word. 4 words give a lowly 63.6 bits.
DES, which has 56 bit keywords, was obsolete in 1998 because keys could be recovered easily with exhaustive search. The EFF a even built a machine to crack DES using brute-force search. Your passwords are just 7.6 bits above a system broken 2 decades ago. Maybe your method would have been a good recommendation in 1960.
This is a textbook example of why you should NOT try to implement a security-sensitive program (even a script is a program) when you have no idea of what you are doing.
>They are certainly *much* easier to remember (and probably faster to type) than "pvQx697b88nfDJKv8LQ4Mg" (password your first command can output) and much stronger than "w5eJ".
Your reading still is as poor as your cryptography knowledge. I never suggested using a 4-character key like “w5eJ”. I proposed this as a method to memorize a longer password incrementally, and I suggested 96 bit keys. There is a big difference.
>/dev/urandom providing only pseudo-randomness, there is a risk (although it should be OK) of a bug that would help the cracker.
No.
In Linux /dev/random (/drivers/char/random.c) the raw data from the entropy sources are passed through the same mixing algorithm used for /dev/urandom. Moreover, both devices use the same entropy sources.
>It returns the current number of seconds since January 1, 1970.
No, it doesn't, because of leap seconds.
I can see you replied with the attitude of “I am smarter than you”, but you just succeeded in showing your incompetence.
Lol.
DES, which has 56 bit keywords, was obsolete in 1998 because keys could be recovered easily with exhaustive search. The EFF a even built a machine to crack DES using brute-force search.
That is true: it cost US$ 250,000 and used 1,856 custom chips to crack one DES key in a little more than two days. Nowadays, the clusters in intelligence agencies can probably do it within tens of hours, still burning a lot of energy though.
Your passwords are just 7.6 bits above a system broken 2 decades ago.
Do you realize that means the effort (basically the time and energy) to crack the password by brute force is multiplied by 2^7.6 = 194?
The numbers of different passwords I gave are right (even though they do not look as "smart" as their base-2 logarithms, i.e., the related entropies): check them if you want. Now if you sincerely believe the NSA will waste months of their computing power to crack your password, here is a solution: use five words. At one trillion guesses per second, the NSA needs 6118 years to crack the password (in average, knowing the password is five words in /usr/share/hunspell/en_US.dic).
I proposed this as a method to memorize a longer password incrementally, and I suggested 96 bit keys.
Indeed. But your whole method ultimately is to make up and remember four sentences of four words each, actually more given your example (you need to remember the words that do not become letters in the password: "has", "fingers", "in"), plus what words are misspelled and how ("Jand"), plus what letters to capitalize ("will" with a small w, "Jand" with a capital J), not to mention the characters '+' and '/' ('base64' can output them and they are not easily put in a sentence) and the order of the four sentences.
But I am a nice guy. That is why my post above considered that the memorization efforts, remembering four characters in the password with your solution vs. remembering four properly spelled words, are the same in both cases, hence the entropy comparisons it made.
In Linux /dev/random (/drivers/char/random.c) the raw data from the entropy sources are passed through the same mixing algorithm used for /dev/urandom. Moreover, both devices use the same entropy sources.
I do understand that /dev/random and /dev/urandom do the exact same thing when there is enough noise in the entropy pool... so it only makes sense to discuss the choice between /dev/random and /dev/urandom when there is not sufficient entropy in this pool. Here is an excerpt from 'man urandom', which makes my point:
A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.
No, it doesn't, because of leap seconds.
Sure. But there are still 31 million seconds in a year (don't you point out the approximation I make here?, leap years?, etc.), my point.
I am a translator!
>use five words. At one trillion guesses per second
>needs 6118 years to crack the password
Always 5 random words user account psswd ;)
>That is true: it cost US$ 250,000 and used 1,856 custom chips to crack one DES key in a little more than two days.
This is grossly misleading. It is like saying “It cost 10,000,000 USD to build your CPU”, conflating the cost of the equipment (semiconductor plant) with a single unit of output (the CPU). 250,000 USD is the cost to build the equipment. The cost to crack a key is much cheaper and is basically only the cost of electricity and maintenance plus a tiny fraction of the cost of the equipment (it is amortized over many runs).
>At one trillion guesses per second, the NSA needs 6118 years to crack the password
Your emphasis on “billions” and “trillions” to make the wimpy entropy of your password generation scheme appear impressive merely adds to the humorist value of your message.
Your “trillion guesses per second” is an arbitrary number. You are deluding yourself you think that any serious attacker will be so limited. This is roughly the computing power of one Bitcoin miner with a cost of around 100 USD. Of course, Bitcoin miners are highly specialized and can not be used for password cracking. This is meant as an illustration of the cheap cost of computing equipment. And again, computing equipment can be reused, so the cost per run is even lower. You could argue than Bitcoin miners are cheap because there are economies of scale, but so there will be in any serious brute-force attack.
If the password hash is iterated, as most are, this adds just a couple orders of magnitude to the cost.
>Do you realize that means the effort (basically the time and energy) to crack the password by brute force is multiplied by 2^7.6 = 194?
It would, if we still were in 1998, but we are not. We are not stuck with 20-years-old technology. Today's digital electronics are much faster, cheaper and energy-efficient.
I am sorry if the number 194 sounds big in your mind. Factors like this are routinely ignored in cryptographic analysis. As a rough rule of thumb, computing power to cost ratio doubles every 1.5 years (this is not Moore law, but it is related). 19 years is thus an increase by a factor of 2^12.7≈6500. Your factor of 2^7.6 pales in comparison.
Conclusion: In 2017, your suggested scheme is more broken than DES in 1998.
>Here is an excerpt from 'man urandom', which makes my point:
No, it does not. You tried to change the argument without anybody noticing but your attempt failed. I quote you with emphasis added:
>Notice also that my solution uses /dev/random, not /dev/urandom. /dev/urandom providing only pseudo-randomness, there is a risk (although it should be OK) of a bug
Your original point was about bugs. The man page talks about cryptographic attacks.
Regarding the risk of cryptographicaly attacks on the CSPRNG, this only affects the conditional entropy of subsequent bytes when attacker knows part of the past output of /dev/urandom, which is not the case here. Moreover, the fact that the entropy pool is continuously mixed with new entropy makes any attack on the CSPRNG algorithm much more difficult.
Also, a cryptographic attack can always compromise the security of a practical cryptographic system, so saying “Don't use this because it is vulnerable to cryptographic attacks” is equivalent to saying “Do not use any modern cryptography”.
If you are so afraid of cryptographic breaks, free feel to use the one-time pad instead of GNU PG to encrypt your data.
-----
Enough of giving you free lessons about the cost of brute force attacks. I am sharing my knowledge altruistically, but I gain nothing, and I have other things to do, so I withdraw from this discussion. If you want to learn about brute force attacks, a good starting point would be the paper “Understanding brute force” by D. J. Bernstein.
> Your “trillion guesses per second” is an arbitrary number. You are deluding yourself you think that any serious attacker will be so limited.
What is the actual number, then?
> Of course, Bitcoin miners are highly specialized and can not be used for password cracking.
I would like to suggest suggest sticking to facts and evidence pertaining to password cracking. Bitcoin may be based in cryptography, but that doesn't necessarily mean you can apply rules to Bitcoin 1:1 onto passwords, as you kind of hint at here.
> Conclusion: In 2017, your suggested scheme is more broken than DES in 1998.
I didn't see the source of this conclusion in the paragraphs that preceded it. It seems to me you were just claiming that computer power grows by a certain amount in 19 years (why 19 years? Why not 10, or 50?) to an extent greater than the figure Magic Banana supplied.
But what your conclusion here states suggests that the scheme itself is fundamentally broken. If that is the case, then why is it not possible to simply increase the number of words to achieve an acceptable strength, thus increasing the number of possibilities even further?
Or alternatively, if the scheme is fine given a sufficient number of words, why don't you simply provide a calculation for what that number of words actually is? I think this would be much more constructive than just saying multiple times that what was provided doesn't work. At the same time, it would be worth comparing that to a string of characters (which is what you appear to be advocating), particularly looking at how long the string of characters needs to be to match the string of words. That way, we could compare the relative lengths and strengths of both methods directly.
> Your original point was about bugs. The man page talks about cryptographic attacks.
This seems like a bit of a semantic argument, no? I took what Magic Banana wrote to mean that /dev/random is safer than /dev/urandom, which you seem to implicitly admit here, and therefore /dev/random ought to be used. Considering the only trade-off is having to wait a little longer, I can't see I can think of any fundamental flaw in this reasoning.
How about this: what is the reason you recommend /dev/urandom when /dev/random would (as you appear to agree) be safer? You could argue forever about how much safer it is, but why take the chance?
Or alternatively, if the scheme is fine given a sufficient number of words, why don't you simply provide a calculation for what that number of words actually is? I think this would be much more constructive than just saying multiple times that what was provided doesn't work. At the same time, it would be worth comparing that to a string of characters (which is what you appear to be advocating), particularly looking at how long the string of characters needs to be to match the string of words.
I can do that. Knowing the way the password was generated and assuming the random number generation is not vulnerable, the password with n American words is as strong as the password with 2.7 x n 64-base characters (the exact coefficient is log(62155)/log(64)).
What number n is sufficiently large? It depends the cracker (the computing power at her disposal, the time she is willing to spend, the electricity bill she is willing to pay). Let us take an extreme case to be safe: the NSA trying to crack Laura Poitras' passwords. Edward Snowden, who better knows NSA's capabilities than us, advised Laura:
Assume your adversary is capable of one trillion guesses per second.
https://www.wired.com/2014/10/snowdens-first-emails-to-poitras/
With n = 4, the NSA would need to keep that guessing rate during 86 days in average (86 days being half of the time to enumerate all passwords that can be generated). I doubt the NSA considers many people are worth such a computing effort. For most people, the NSA probably has faster ways to get the information, through threats for instance. But Laura Poitras may be worth it. With n = 5, the NSA would need 6118 years in average. Starting today. Actually, to finish earlier, the NSA had better wait a few years (decades?), to get greater computing power, than start now.
Let us take both cases:
- n = 4 and 2.7 x 4 = 11:
$ words=4; dic=/usr/share/hunspell/en_US.dic; max=$(wc -l < $dic); for i in $(seq $words); do r=$(od -A n -N 4 -t u4 /dev/random); cut -d / -f 1 $dic | sed -n $(expr $r % $max + 1)p; done | tr '\n' ' '
ingoing jar Emmet nemeses
$ head -c 8 /dev/urandom | base64 | head -c 11 && echo
b+B59UXulCA - n = 5 and 2.7 x 5 = 13:
$ words=5; dic=/usr/share/hunspell/en_US.dic; max=$(wc -l < $dic); for i in $(seq $words); do r=$(od -A n -N 4 -t u4 /dev/random); cut -d / -f 1 $dic | sed -n $(expr $r % $max + 1)p; done | tr '\n' ' '
stimuli poet parasite Caresa tinfoil
$ head -c 9 /dev/urandom | base64 | head -c 13 && echo
sI2L5LOkCPkoJ
(NB: the 11-character password actually is a little stronger than the four-word password; the 13-character password is a little weaker than the five-word password: I have to round...)
Now the subjective question: do you prefer to use (in particular remember and type) "ingoing jar Emmet nemeses" or "b+B59UXulCA"? "stimuli poet parasite Caresa tinfoil" or "sI2L5LOkCPkoJ"? To answer the question, you can refer to the mnemonic marioxcc described (making up the first sentence to remember "b+B5", etc.).
The fact that you shared this script made me feel like there is some kindness in your heart. And that you like to help others.
I hope you stop attacking others here. Magic Banana didn't insult you. Just shared a different way of doing things.
He disagreed with you but was respectful.
Learn to be nice to others. Stop insulting people without reason.
- Inicie sesión o regístrese para enviar comentarios