Re: Password Blacklist

[Per Thorsheim <per () thorsheim net>]

On Wed, 2012-08-15 at 01:48 -0700, Reed Black wrote:
> On Tue, Aug 14, 2012 at 11:33 PM, Per Thorsheim <per () thorsheim net> wrote:
> > Personally I would advice you not to implement a specific wordlist.
> > Instead you should look into stuff like the Dropbox zxcvbn password
> > meter (tech.dropbox.com/?p=165) to guide your users into choosing
> > good passwords.
>
> There's no instead here. This is in addition to some measures that
> require more than a short, consistent case alphabet string. However,
> some very common passwords like "p4ssw0rd" still make it through these
> systems. This is why I'd like to add the blacklist.

This years "CrackMeIfYouCan" contest at Defcon had passwords with an
average length of 21 characters, which essentially makes it a passphrase
cracking competition. Guess what? Lots of them got cracked. ;-) More
info and writeups from the competing teams here:
http://contest-2012.korelogic.com/

> > You should have a decent password policy. I have no idea what you
> > have to protect, but in almost any case on the Internet a decent policy
> > would be minimum length 8 (maximum length should be 128+, to
> > allow even the craziest of passphrases), 3 out of 4 character groups.
>
> This isn't totally germane to the topic, but it may be useful to others:
>
> In this case, it is a consumer entertainment site. This adds
> complications. Our A/B testing showed that aggressive password
> strength requirements cause significant registration dropoff.

Ah. Been there, tough choices to be made. Well, you could offer "social
login", allow users to login to your service through their personal
facebook/google/twitter account? Bonus for you: additional info
available about your users. (Some people will probably flame me for even
suggesting this one...)

> If I had sufficient dev resources available, I'd let people in the
> door with a medium quality password, but flag the account for a
> mandatory password change after enough usage that they weren't a
> flight risk, or after they had been converted to a paying customer.
> Then, I'd have better password strength requirements on the password
> change page than I had on the signup page.

That would be inconsistent and perhaps confusing to users. Better be
very helpful displaying ALL password requirements on registration &
password change, and provide extra links/info on WHY having a strong
password is a good idea. Bonus: info on HOW you transmit & store their
passwords (don't end up like Linkedin, UKTesco and many others, claiming
to be secure when they're not)

> > You MUST (this is not "should") store your passwords properly! That
> > is; no plain MD5 without salting or similar. PBKDF2, Bcrypt or Scrypt
> > with number of iterations set to values that gives acceptable server
> > load vs # of users vs # security.
>
> My favorite writeup on the topic:
>
> http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
>
> As the author says, "If [any of][ this is news to you, you shouldn’t
> be designing password systems."

And Thomas Ptacek is absolutely right. One of my favorite writeups as
well, with many more to add as well.

> > You should implement proper rate-limiting to your login system. Allowing
> > 1 IP to try out tens - hundreds - of attempts per second per username:
> > not good. Slowing down the time between each attempt to an account
> > after the first 2-3-4 attempts is usually fully acceptable to the user, but
> > makes online brute force attacks way much harder to do. There is much
> > more logic to be applied into such rate-limiting algorithms, go search and
> > you shall find.

> More often, I see brute force attacks against a large number of
> accounts, rather than a large number of attacks against a single
> account. I rate limit attempts from individual IPs regardless of the
> account, as well as a lower threshold for IP-account pairs. I return
> the same message when the throttle is hit as when the wrong password
> is entered, and I've watched attackers waste upward of a month running
> with their face against a wall while I study their list of accounts.
> It's a joy!

My favorite attack vector without doubt; 2-3 attempts per account, test
X^x # of accounts. You WILL get access, but again; proper rate limiting
will reduce the number of compromised accounts greatly.

Mohammad Damavandi also said in a reply to my post here that you could
do password history as well. I'll at least partially object to that.
Here's why:

I've researched passwords for at least 12+ years now, focusing on
corporate Windows environments. It doesn't take much effort to see that
+1 becomes a very common pattern when implementing forced password
change frequencies. If you don't, as I usually recommend in exchange of
long passphrases, you still face a problem with password history:

ANY change to a password (+1) is a completely new password, but very
easy to break if you have any clue about previous passwords. If you get
compromised and you ask all users to change their passwords, what do you
think will happen? +1. Although I can't really say yet how many will do
it, but many people will. Lessons learned: don't get hacked in the first
place, as getting back in again will be easy. If the hacker in addition
gets hold of the password history information (previous hashed
passwords)... Well... apply some Levenshtein edit-distance metrics if
you like. :-)

> I previously had an overall throttle per account name as well, in
> consideration of an attacker in control of a large number of IP
> addresses. While I never saw an attacker with more than a couple dozen
> IPs however, I did see people use the throttle to DoS specific users.
> Here again, this may only be a consideration for some types of sites.
> I expect this type of abuse would be less of a concern on a shopping
> site than on a social media site, for example.

Well, usually I like to tell people that I, as an "attacker", really do
not take much interest in your services. I'm interested in usernames,
e-mail addresses and passwords (hashes) for your users, since as many
as 67%
(http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html) may
be reusing their password at more interesting sites.

-- 
Best regards, 
Per Thorsheim 
CISA, CISM, CISSP-ISSAP
securitynirvana.blogspot.com

Attachment: signature.asc
Description: This is a digitally signed message part