Re: Password Blacklist

[Reed Black <reed () unsafeword org>]

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.


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

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.


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


> 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!

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.



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------