Notifications
Clear all

Password Strength  

Page 1 / 3
  RSS
Cults14
(@cults14)
Active Member

Was wondering what the experience out there is on what qualifies as a strong password.

Scenario is that we're trying to put together internal guidance on when to use passwords to protect data files and how complex a password needs to be to defeat all but the most determined attacker.

I appreciate this is more of an InfoSec Policy thing, assuming attempted unauthorised access though, I thought this forum was as good a place as any to get feedback on the quality of advice we might give out on password strength.

Seems to me that mnemonics, with some internalised rules about where to place uppercase, lowercase, special characters and numbers might be the best way forward.

For example, "mHa!l4liFw$wa82s" is the first two lines of "Mary had a Little Lamb" with placing I'll remember of uppercase, special characters and numbers to conform with guidelines I've read up on. So for any individual, the initial letters of favourite songs or verses (or any sequence of easily-remembered words - family member names in descending sequence for example?) combined with other components of a complex password, could work well?

I'm still struggling with the concept of how to safely transmit/store passwords in cases where authorised access by others is or may in future be required.

Any thoughts out there?

Quote
Posted : 06/06/2013 5:48 pm
jaclaz
(@jaclaz)
Community Legend

Any thoughts out there?

This topic was (slightly) touched here
http//www.forensicfocus.com/Forums/viewtopic/t=10572/

The "correcthorsebatterystaple" seems still to me the most sensible approach.

You might want to make it L337, with something like
http//www.brenz.net/services/l337Maker.asp

(0RR3(7|-|0R53B4773R'/574PL3

or
http//www.robertecker.com/hp/research/leet-converter.php?lang=en

c0rr3c7h0r53b4773ry574pl3

or
http//ratfactor.com/leet-speak-translator

Original correcthorsebatterystaple
Level I Leet c0rr3cth0rz3batt3rystapl3
Level II Super-Leet c0rr3c+h0rz3b4++3ry5+4p13
Level III Mega-L33T!!1 (0rr3(+}{0rz3b4++3r'/5+4p13

Basically a "long enough", "plain text only" password, passed through a simple letter -> unusual character substitution (which anyone can remember as long as ALL occurrences of a given letter are replaced by "the same" character or sequence of characters and have some "visual feedback" like in the examples) would IMHO do, providing a "good enough" password while avoiding to have the final user actually *need* to jolt it down on a Post It on the PC screen or inside the first drawer (the one on the left wink ).

About transmitting/storing it, that is an unresolved issue, unless you also use some code (from the good ol'times cryptography was invented, i.e. simple enough to be unencrypted with just a piece of paper and a pencil, along an algorithm that is pre-shared and thus known), but still it is sub-optimal.

jaclaz

ReplyQuote
Posted : 06/06/2013 6:56 pm
adri
 adri
(@adri)
New Member

Make it long and simple (but not dictionary-attack simple of course). )

ReplyQuote
Posted : 06/06/2013 7:02 pm
Cults14
(@cults14)
Active Member

Thanks guys

I will see what else crops up here and will at some point run some ideas past some users, just in case we as people with a vested interest in this area think these types of passwords are easier to remember than they actually are!

Cheers

ReplyQuote
Posted : 06/06/2013 7:13 pm
athulin
(@athulin)
Community Legend

Was wondering what the experience out there is on what qualifies as a strong password.

A rather impractical one the strength of a password is inversely proprotional to its likelihood of being guessed. 'Summer-2013' is a password that fulfills many password guidelines (uc, lc, special character, digit), and a length > 10. Still, it's an extremely weak password.

Scenario is that we're trying to put together internal guidance on when to use passwords to protect data files and how complex a password needs to be to defeat all but the most determined attacker.

The easiest way to think about this is, I believe, is to put yourself in the attacker's position. Say you have found a login form (web application, ssh, telnet, …) and you want to attack it.

First of all, how many guesses per second can the attacker make? That includes multiple sessions.

Then, how long until the attacker is discovered? Some systems lock you out after 20 failures. In other cases, it's not discovered until the sysadms returns from his vacation and learns that the log file of failed logins now occupies 99% of available log disk space.

One you know those parameters, you can form a conclusion you want a password that won't be guessed over that time, with that rate of guesses per second. And then you want to up that quite a bit – say a factor 10 or so.

However … if the password protects a file, there will be no discovery, so that time element is gone. And the other parameter (guesses per second) is not really under your control. All you can do is make guesses about probable resources, and then try to make the attack difficult for someone with those resources only. These days, that includes resources like the Amazon EC2 compute cloud and GPU assist …

That is, you don't want to have that kind of situation you don't want files protected by password, unless you are part of authentication process. Otherwise, detection becomes impossible.

A reasonably good way of producing password guesses, is to use the John the Ripper password cracker. You can get it to output its password guesses to file – and that can be used as one way to decide if a password is weak – does it appear in the first N passwords that JtR produces? (N is chosen based on your own authentication situation.)

Seems to me that mnemonics, with some internalised rules about where to place uppercase, lowercase, special characters and numbers might be the best way forward.

The best way forward is to avoid passwords. If you for some reason is stuck with passwords (in which I include passphrases), the best way forward is to make them random. Any rules you apply reduce the search space.

Same thing with those rules of 'at least one uppercase, one lowercase, one special, and one digit' they reduce the search space, and must be matched with a corresponding increase in the minimum length of the password.

Any thoughts out there?

Don't go there on your own. Get in touch with an authentication / information secuirty specialist, who can look at your problem from all sides, including those you haven't mentioned or even thought of. And who can make a recommendation based on that.

If you must do it yourself, at least read the book 'Authentication' by Richard Smith first.

ReplyQuote
Posted : 06/06/2013 9:18 pm
Cults14
(@cults14)
Active Member

Athulin - wow.

To put some perspective on it, we need to find some kind of compromise between security(random passwords are good), utility (random passwords are hard to remember), and cost (we won't spend any money on additional hardware/software to manage file-level passwords).

And although it will be a compromise, (a) password-protection on files is better than no protection when it comes to the merely curious unauthorised person who happens to get access to a file, and (b) a strong password will deter all but the most determined attacker.

We have a system which issues random passwords for Domain Admins which are valid for 24 hours, but that's a different issue.

Will try a variety of passwords on various files though, and feedback if I can

Cheers

ReplyQuote
Posted : 06/06/2013 9:38 pm
Xennith
(@xennith)
Active Member

Correcthorsebatterystaple type passwords are great against bruteforce but less wonderful against dictionary hybrid attacks with a rule along the lines of %w%w%w%w. This kind of hybridised attack is gaining popularity and it really does perform very well against a wide spectrum of password types.

I'd avoid random strings that you need to write down, if you're mandating these you might as well start handing out postit notes.

The "pick a song and permute the first letters of each word" type passphrases are a personal favorite, if you mandate them at over 12 chars in length with upper, lower, and either number or symbol I think you're doing pretty well. Basically as long as your password doesn't appear in JTR's little dictionary you're already ahead of the curve. You could even move to a post password world and use certificates and tokens.

Oh, and it wouldn't kill you to do an audit from time to time, anything you break in a week is too weak.

As far as the question of key exchange, this is a problem as old as cryptography. The rule of thumb is that the key and the data must be sent over two seperate channels. Emailing someone the data and then phoning them with the password for example.

ReplyQuote
Posted : 06/06/2013 10:27 pm
Bulldawg
(@bulldawg)
Active Member

This article is written based on a worst case scenario–unsalted single round of MD5 and the attacker has the list of hashes for offline processing. Passwords like "qeadzcwrsfxv1331" were recovered.

http//arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

As others have mentioned, this largely depends on your scenario. If there is a technological limit on the number of tries before lockout, then weaker passwords are acceptable, but if there is a possiblity of unlimited guesses or an offline attack, then a strong password is a must.
-Do not use common substitutions ([email protected], T=7, E=3) as the attacker will also know those substitutions. It's easy to be compliant by adding a ! at the end of your password, but attackers know about this too, so use a symbol in the middle of a word. Like "ho!rse." Even better, use a completely random string of letters, numbers, and symbols. Use a password manager for this.
-Avoid all words. Also, do not think of "words" as things that appear in a printed dictionary. Words are words in a password dictionary. Things like "[email protected]" "correcthorsebatterystaple" "fido" are all words that appear in password dictionaries.
-More important than password policies is educating your users. No matter what your policy is "Meetme@730" is likely to satisfy all the requirements of the policy, but that is a horrible password. Uneducated users think it's great and then an attacker

ReplyQuote
Posted : 07/06/2013 1:06 am
TuckerHST
(@tuckerhst)
Active Member

Correcthorsebatterystaple type passwords are great against bruteforce but less wonderful against dictionary hybrid attacks with a rule along the lines of %w%w%w%w. This kind of hybridised attack is gaining popularity and it really does perform very well against a wide spectrum of password types.

It's nice to see another contrarian. While xkcd is often funny, in this case, I also disagree with his assertion – that 4 dictionary words comprise sufficient entropy. (I would love to know how that was calculated.)

In order of importance
- Length (12+ characters; more is better)
- Large keyspace (upper/lower, numbers, specials)
- Minimize predictability (no dictionary words, not even leetspeak)

ReplyQuote
Posted : 07/06/2013 5:17 am
jaclaz
(@jaclaz)
Community Legend

Well, to defend xkcd, entropy of a password is one thing, difficulty in "getting it" with a multiple word dictionary attach is another.

Entropy is a measure ONLY suitable to brute force attack
http//en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength
And that would be H=L*Log2(N), but only for "random-generated" passwords.

Non-random-generated passwords have a much smaller entropy.

Check this wink
https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/
https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html
Source is available
https://github.com/lowe/zxcvbn

Of course L337speak was only an example, an intentional one to show how three different L337speak translators provided threee different results.

If you test in the above
correcthorsebatterystaple = 45
(0RR3(7|-|0R53B4773R'/574PL3= 85
c0rr3c7h0r53b4773ry574pl3 = 51
c0rr3c+h0rz3b4++3ry5+4p13 = 67
(0rr3(+}{0rz3b4++3r'/5+4p13 = 87

So, not only character substitution counts (if it enlarges the number of symbols) but if the substitution is not a "conventional, common" one (and increases in itself the length of the password) does help in making things much more difficult.

Simple 1 letter shift
correct = 10
bnqqdbs= 32

The whole password
correcthorsebatterystaple = 45
bnqqdbsgnqrdazssdqxrszokd = 110

Only vowels 1 letter shift
correct = 10
cnrrdct=31
correcthorsebatterystaple = 45
cnrrdcthnrsdbzttdrystzpld = 111

And of course there is a "language factor", a (common 😯 ) Turkish word such as
http//en.wikipedia.org/wiki/Longest_words#Turkish
Muvaffakiyetsizleştiricileştiriveremeyebilecek = 194
but even it's English translation
Onewhoisnotabletomakeoneeasily = 55
is not that bad after all….

jaclaz

ReplyQuote
Posted : 07/06/2013 2:41 pm
mscotgrove
(@mscotgrove)
Senior Member

As a question, I have seen someone use a password along the lines of

JohnSmithJohnSmithJohnSmith

Easy to remember, but long.

Is this secure?

ReplyQuote
Posted : 08/06/2013 1:47 am
jaclaz
(@jaclaz)
Community Legend

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://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html

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

ReplyQuote
Posted : 08/06/2013 3:04 pm
mykulh
(@mykulh)
New Member

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.

ReplyQuote
Posted : 09/06/2013 1:26 am
athulin
(@athulin)
Community Legend

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'.

ReplyQuote
Posted : 09/06/2013 2:51 am
mykulh
(@mykulh)
New Member

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 )

ReplyQuote
Posted : 09/06/2013 12:49 pm
Page 1 / 3
Share: