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

[ reply ]
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)


 

Privacy Statement
Copyright 2010, SecurityFocus