RE: Password Blacklist

Another suggestion: use the length and complexity of the user-entered
password to determine its maximum lifetime. Really weak passwords must be
changed within a couple of weeks; really strong passwords will last for
years before they have to be changed.


-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Reed Black
Sent: 15 August 2012 09:48
To: [email protected]
Subject: Re: Password Blacklist

On Tue, Aug 14, 2012 at 11:33 PM, Per Thorsheim <[email protected]> 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
--------------------------------------




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