determining password entropy

[Daniel Skinner]

I just finished reading http://www.cl.cam.ac.uk/~jcb82/doc/B12-SPW-statistical_password_strength_metrics.pdf and other source materials and was going to work on some implementations, but just curious if anyone is aware of some OSS related before I start out on my ignorant ways :)

[Klaus Post]

Hi!

I am not sure I see the point of this. Passwords like "aq!2wsde#" may seem like a mathematically sound password, but look at your keyboard why it may be a common password.

I have met a lot of (from a user point) stupid arbitrary password requirements, which forces me to NOT use a password I can memorize, so I am forced to:

a) Use an existing password I use elsewhere
b) Write down the password somewhere.

Both are IMO worse than what the algorithm considers a "bad" password for some arbitrary reason (password may not have the same character twice in a password - WTF!)

So instead of trying to be clever, for my site, I have 2 requirements,

1) 8 Characters or more.

2) It must not be present in the "CrackStation's Password Cracking Dictionary":

https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm

Since I store "bcrypt" passwords, I have adjusted the complexity of a password check to take approx 500ms (that equates to 11 iterations on my server). That means it would cost approx $500.000 to get a single 8 character password within a year, if you bought Amazon cloud computers to crack it.  The only way to "cheat" this is if the password is in a password list, which is why I test each password against that.

So, unless the user chooses a password we *know* an attacker will try as one of the first attempts, we don't try to "outsmart" the user with a clever algorithm.

FYI, my passwords on website are all 8 characters generated from a has of the website site domain and a "master password", which means that all my passwords are unique for each website, which is much better than most people can claim. So I am very annoyed whenever a website tries to be "smart" about what is a good password.

Sorry about the rant - just wanted to give you some perspective :)

Regards,

Klaus

[Henrik Johansson]

I use KeePassX for this and it is open source and can generate passwords. It has some entropy collection mechanism that is especially visible on Mac although not so much on Linux.

Might be worth looking at.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Skinner]

Hi, thanks, I'm actually on the same page with you on password requirements. This was more derived from a side conversation at work where the requirements were similar to what you listed but also had another, don't allow username in password.

The nature of that though is a username could consist of a single letter so ... :D

I'm not actually responsible for the system so I have the privilege of trying to be clever on my own time. After playing around a bit last night, I was thinking the entropy check would need to be near zero to fail and be practical since the point is to not annoy users while also not allowing stupid passwords.

Just checking entropy with Shannon implementation on the smaller crackstation db last night yielded values higher than what I use for my own passwords so it's certainly no indication of password strength b/c (a) those are known passwords as you mentioned (b) I'd like to think my passwords are secure :)

Right now I'm thinking that finding non overlapping occurrences of the largest words from a predefined dictionary supplemented by additional info gathered followed by letters, and then checking entropy like that.

If this resulted in a near zero value, then it may be an indication that the password may not be secure to human guessing.

--

[Tim Shannon]

You mention Shannon Entropy, which you're right isn't necessarily an indicator of actual entropy, just entropy with that subset of data, it can be useful as fixed point of comparison.  If anyone else is looking for a quick Shannon Entropy snippet (I was earlier in the year), here's an example I wrote up: http://play.golang.org/p/9ruy0YA34o

[Daniel Skinner]

Interesting, this is the one I wrote up

https://gist.github.com/dskinner/ee01bec5e25046fdc5c5

There's the Entropy func that just does the same but also the EntropyDict func which is a bit funky since it doesn't handle overlaps perfectly well but worked good enough to test what I was thinking.

It examines frequency of words and then left over runes and produces a value from that. So if a word from the provided dict, which contains the context of what a human might have in mind, is matched in the string, it lowers the value. I typically found <= 1.125 a decent indication that something might be human guessable but that assumption isn't very well tested and is also bound and subject to the contents of the dict which isn't totally practical either.

That part of the code is a bit messy, the Match type isn't necessary anymore, I was originally doing something a bit different there.