Web Application Security
Password Blacklist Aug 14 2012 05:29PM
Reed Black (reed unsafeword org) (3 replies)
Re: Password Blacklist Aug 15 2012 07:24AM
Nick Galbreath (nickg client9 com)
Re: Password Blacklist Aug 15 2012 07:11AM
Andrew van der Stock (vanderaj greebo net)
Re: Password Blacklist Aug 15 2012 06:33AM
Per Thorsheim (per thorsheim net) (1 replies)
Re: Password Blacklist Aug 15 2012 08:48AM
Reed Black (reed unsafeword org) (2 replies)
Re: Password Blacklist Aug 15 2012 07:56PM
Per Thorsheim (per thorsheim net) (1 replies)
Re: Password Blacklist Aug 16 2012 06:01AM
Snipe (snipe snipe net)
RE: Password Blacklist Aug 15 2012 10:38AM
Nigel Ball (Nigel K Ball dsl pipex com)
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: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On
Behalf Of Reed Black
Sent: 15 August 2012 09:48
To: webappsec (at) securityfocus (dot) com [email concealed]
Subject: Re: Password Blacklist

On Tue, Aug 14, 2012 at 11:33 PM, Per Thorsheim <per (at) thorsheim (dot) net [email concealed]> 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-tab
les-
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
--------------------------------------

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus