As a question, I have seen someone use a password along the lines of
JohnSmithJohnSmithJohnSmith
Easy to remember, but long.
Is this secure?
As a question, I have seen someone use a password along the lines of
JohnSmithJohnSmithJohnSmith
Easy to remember, but long.
Is this secure?
No.
Meaning that it is as secure as any other password of same length only if ONLY brute force is used, it has NO security whatever if a dictionary or pattern detection engine is used.
In the mentioned calculator
https://
password JohnSmithJohnSmithJohnSmith
entropy 9
crack time (seconds) 0.026
crack time (display) instant
score from 0 to 4 0
calculation time (ms) 1
As a comparison, a snippet of Vogon's Poetry such as "Oh freddled gruntbuggly" wink produces
password Ohfreddledgruntbuggly
entropy 67.08
crack time (seconds) 7801971307994876
crack time (display) centuries
score from 0 to 4 4
calculation time (ms) 0
(of course if a Vogon dictionary is not included in the cracking engine 😯 ).
jaclaz
I am not sure how pattern detection would work if you are attacking a log on hash or some such.
As much as the words 'john" and "smith" are simply to get from any dictionary, if you have decided on an attack strategy of word, word, word, word word, word or even word, word, word, if you have johnsmith as one word in a custom dictionary, you still have to run through joining up all the other words in your dictionary to make up that combination, to me that would be where the time is lost, even when dealing with a single iteration hash.
The johnsmith password would also be strong against brute force just because of 27 chars, myself I would upper case the middle johnsmith, making johnsmithJOHNSMITHjohnsmith just to make it necessary to need an upper case charset.
In my mind that was the point of the xkcd cartoon, you leet a password it is easy to forget the exact structure but cat at least four plain words together you get a phrase easy to remember but tough to brute force or plan a decent strategy against.
The johnsmith password would also be strong against brute force just because of 27 chars, myself I would upper case the middle johnsmith, making johnsmithJOHNSMITHjohnsmith just to make it necessary to need an upper case charset.
In off-line cracking scnearios anything that is based on patterns and word list components must be regarded as doubtful at the very least.
If I (as the attacker) have a full hash database, the only protection you have depends on whether I have added the password to the database or not. (And that's not under your control – you can only hope I haven't.) The simpler it is for me to do so, the more likely it is that it has already happened. And as storage costs are so comparatively low, there is much less of an economical problem to create a hash database by doubling or tripling base phrases. (Several years back I calculated that it would be possible to do a complete LM hash datase with something like 14 Tb of storage. At that time, that made it economically impossible for 'normal' attackers to do. Today, they probably have that amount of storage in their personal NAS solutions already. )
Passwords are dead – at least as protection in off-line cracking scenarios and with quickly computable password hashes. The only simple solution appears to be to increase complexity of computation to a level where a hash requires something like two seconds to compute, and is 'very hard' to bit-slice or otherwise split up in discrete chunks of computation. Then it should be OK for the next five-six years or so, as long as the passwords chosen aren't trivial. (An increase in hash length would also help keep storage requirements 'high'.)
In my mind that was the point of the xkcd cartoon, you leet a password it is easy to forget the exact structure but cat at least four plain words together you get a phrase easy to remember but tough to brute force or plan a decent strategy against.
In on-line situations, particularly when password locking is used, schemes like this can still be useful. And that's why attackers try to convert them to off-line attacks by stealing the hashes. Then they are in control/. That's why I think it may be important to make password schemes include an on-line component, say, a sequence such as 'compute hash locally, send to server, retrieve second hash, use in additional computation, store as hash'.
I understand that using dictionary words make it seem less secure but using a complex leet'd random characters is also going to fall to a full hash lookup database or rainbow table, so why not employ a very long password that is easy to remember?
In practical terms creating a NT (for example) hash database of up to 27 characters, even if just upper and lower case, is not going to be within the reach of most companies let alone people working alone.
And as you said this sort of attack is getting phased out with random iterations and salts, which puts the attack back to dictionary/combination/hybrid and so you are left with the chance that you have the password in your dictionary or you are willing to take the time out to run combination attacks using your dictionary and with a simple 100 million password dictionary combining that 3 or 6 times on each word to see if that works is going to take a long time, making the 27 char password, even though based on simple dictionary words, secure.
Of course like I imagine others have, I have added this password to my dictionary, the same as Tr0ub4dor&3 and correcthorsebatterystaple when the cartoon first came out so I would strongly advise against using it )
In practical terms creating a NT (for example) hash database of up to 27 characters, even if just upper and lower case, is not going to be within the reach of most companies let alone people working alone.
A complete one, no. But that was not really my point, either.
The point is that if you rely on rule-based ways of extending a simple password (JohnSmith) to a long one (JohnSmithJohnSmithJohnSmith), you must take into consideration that any attacker can do the same. If the rule is trivial (as in the JohnSmith case), you really should assume that it's already been done.
I'm no longer doing this kind of thing (I used to be part of a pen-test group, and I specialized in password cracking), but when I was, collecting first and last names and creating basic 'JohnSmith' pattern was one of the first things I did, along with all variations in upper and lower case, and all the standard extensions people do – digits at the end and at the head, special characters at the head, end and in-between, etc., as well as tacking a place-name at the end – e.g. JohnSmithCroydon.
Doing that for pattern-created passwords doesn't really add very much to password database space. Doing it for random passwords, covering the entire alphabet in every position, does, true, but the idea is that if people mainly use rules for creating their passwords, a password cracker should also ho by rules for cracking them, before resorting to complete brute-force. True randomness in password creation is an important factor– don't underestimate it.
And as you said this sort of attack is getting phased out with random iterations and salts, which puts the attack back to dictionary/combination/hybrid and so you are left with the chance that you have the password in your dictionary or you are willing to take the time out to run combination attacks using your dictionary and with a simple 100 million password dictionary combining that 3 or 6 times on each word to see if that works is going to take a long time, making the 27 char password, even though based on simple dictionary words, secure.
Quite right. But that only means that that's not the way to do the job. If you really do off-line cracking, you want to move time requirements from 'time-of-crack' to a time that you are in control of. (Building hash databases and rainbow tables are good examples of that.) With simple, unsalted password hashing (MD5, NTLM, DES), producing short hashes, storage space is the main limiting factor – time = compute power is not. Add hashing time complexity, and things change. Increase salt or hash lengths, and things change.
Of course like I imagine others have, I have added this password to my dictionary, the same as Tr0ub4dor&3 and correcthorsebatterystaple when the cartoon first came out so I would strongly advise against using it )
But the rules are still there, and can be exploited. The rule that one person 'invents' has to a very high degree of probability already been 'invented' and used by someone else. So basing password dictionaries on rules make very good sense.
The first rule one is a combination of dictionary word + capitalization + partial vowel encoding + 2-character random suffix. Anyone who is serious should consider all passwords based on that rule, and closely related ones, as bust.
The second just word1 + word2 + word3 + word4. Same thing here. Both can easily be added to a decent password dictionary, and it would probably take fairly little time to add the corresponding hashes to a hash database.
And trying to do better by the 'Mary had a little lamb' method … well, better choose your source very, very carefully. It's probably available on the net, which means that phrase extraction from classic work of literature is useful is dictionary preparation. And given how people think, using lines from Elvish poetry out of Tolkien, or from Klingon space manuals, or Hogwart wizardry books doesn't really do either.
That is, if you are serious about cracking passwords, you don't add single words to your password database. You dig out the rule behind it, and base your additions on that. And you look very attentively at leaks of passwords to figure out what 'rules' or thinking patterns the passwords follow. People are unoriginal. So passwords they create are very likely to be unoriginal in various ways, too.
For off-line cracking, rule-based passwords are not enough to protect anything. It's a question of time and resources to crack them, and neither is under your control. If the value of cracking the password is strictly limited in time (say, after two months it doesn't matter if the file is decrypted), I could imagine that might be used, but only if the time aspect was rigourously evaluated.
For some practical suggestions Look at the design of Bcrypt, used in OpenBSD, for example. Also check NIST Special Publication 800-132, which covers another approach. Make sure you also look at scrypt, which tries to cover an attack method that was not practical in 1999.
Over and out.
Though it is a VERY "bad" thing to say, in some cases you may "get with it" not because of your chosen password is "good", but because the majority of other ones are "poor".
That's what the arstechnica article is leading to, a common approach by real-world crackers is to "optimize" their efforts, spending the less time to get the more (easy) passwords.
It's nothing much different from the approach used in nature by swarms to confuse predators (and sacrifice a few) or in the old joke about the bear
http//
Here is a nice thing )
https://
http//
jaclaz
I sparked more of a response form JohnSmithJohnSmithJohnSmith than I thought I would - has made interesting reading, thank you.
If I understand correctly, the message is weak because it contains common words with no symbols, repeated. At the same time it is reasonably strong because it is long.
One strength of this password must be the length, but it would become very weak if an investigator were to find another password MaryJonesMaryJonesMaryJones and hence discover a style.
How common are 27 byte passwords - the top 10K list in another post showed most common passwords to be 6 to 10 characters. There is no way to know one is looking for 8 or 27 character password, which surely means one has to 9,10,11 etc lengths as well.
Would JohnSmithMaryJonesPeteBlogs be considered safe (assuming the names were not part of the e-mail contact list!) Obviously a + or - between the names would also make a large difference, JohnSmith+MaryJones-PeteBlogs
Would JohnSmithMaryJonesPeteBlogs be considered safe (assuming the names were not part of the e-mail contact list!) Obviously a + or - between the names would also make a large difference, JohnSmith+MaryJones-PeteBlogs
Why don't you test them?
https://
password JohnSmithMaryJonesPeteBlogs
entropy 36.005
crack time (seconds) 3448307.2
crack time (display) 3 months
score from 0 to 4 3
calculation time (ms) 2
password JohnSmith+MaryJones-PeteBlogs
entropy 48.824
crack time (seconds) 24914019520
crack time (display) centuries
score from 0 to 4 4
calculation time (ms) 2
But consider that the above is just one of the possible approaches and uses a limited set of patterns (thus the result is ONLY indicative).
If "by any chance" the rule "couple two names and separate them by either + or -" is found it instantly becomes minced meat.
Consider the (both insecure)
"rfvtgbyhn" and "rfvtbgtyhn", at first sight they both seem "random, but they are actually "qwerty"
password rfvtgbyhn
entropy 29.265
crack time (seconds) 32248.627
crack time (display) 10 hours
score from 0 to 4 2
calculation time (ms) 0
password rfvtbgtyhn
entropy 32.089
crack time (seconds) 228363.585
crack time (display) 4 days
score from 0 to 4 2
calculation time (ms) 0
but this second seemingly reassuring result happens only because that pattern is not "as good as it could be".
A "qazwsxedc" which has exactly the same complexity as the ones above is
password qazwsxedc
entropy 12.467
crack time (seconds) 0.283
crack time (display) instant
score from 0 to 4 0
calculation time (ms) 0
because it is already in "that" dictionary.
jaclaz
Great article on "password haystacks".
The basic premise is a fairly good password becomes great when you pad it with extra characters. Since cracker is either 100% right or wrong, padding length makes password harder to crack.
Ex- Which of the following two passwords is stronger,
more secure, and more difficult to crack?
D0g…………………
PrXyc.N(n4k77#L!eVdAfp9
"In fact, since it is one character longer and contains uppercase, lowercase, a number and special characters, that first password would take an attacker approximately 95 times longer to find by searching than the second impossible-to-remember-or-type password!"
It is still good to have a strong base with upper, lower, characters, etc, etc