Re: Password Blacklist

[Snipe <snipe () snipe net>]

On Aug 15, 2012, at 3:56 PM, Per Thorsheim 
> > > 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.

Also be mindful of Unicode issues. If someone use kanji in their password, make sure you can grok that. Don't 
substitute characters, or a 20 character kanji password turns into "????????????????????"


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

I won't flame you for this. As the CSO of my company, I'd MUCH rather let people connect using fb/oauth than store 
passwords. Makes you a smaller target, and if your DB is compromised, a user can simply disconnect the app from their 
account. I don't have to apologize to users about their password getting compromised if I never had it to begin with.

Yes, in some ways this is passing the buck, but it makes the drop-off a non-issue, AND you get the benefits if the 
social platform, which - love them or hate them - FB has kinda nailed.

Security is absolutely important- but security that creates enough of a barrier that business can't be done (web app, 
internal, wherever) is security done wrong, IMHO.

Can you offer two-factor auth using some API radness from Duo Security? For the folks that do care about their data, DS 
makes it trivial to implement two-factor auth on just about everything, (No, I do not work for DS, just a fan.)


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

Absolutely agree. Users won't know what to make for that. At best, they'll be annoyed, at worst, they will be confused 
and afraid something happened to their account to cause a forced password change.

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

I would rather have a system that rate limits me after 20 detailed attempts. Looking at this realistically, who screws 
up their password 20 times in a row? You can't brute force with 20 tries, so any kind of lockout for failed attempts is 
a good deterrent. 

20 failed attempts, 30 minute lockout. Would take too long to bother to brute force that to make it too useful.

Hackers (typically) go for the lowest hanging fruit. If you make your systems enough of a pain in the ass, that's 
already a deterrent. Not a defense, but a deterrent. 

Having some kind of sane log alerting system here is also a huge benefit. You don't want to be alerted o every failed 
login attempt - but 20 different failed login usernames from the same IP within 20 seconds - not even humanly do-able - 
you might consider a system that alerts or auto-blocks/silent-fails on that kind of activity.

Also be away of timing attacks. It should take as long for your system to respond with a fail as it does for a success. 
If your system is designed in such a way whe one is much faster than the other, you can add a deliberate delay.

Also try not to expose too much in your error messaging. If your app responds differently to a bad username than it 
does to a bad password, an attacker can use that to build a database of valid usernames, and now you've just done half 
their work for them.


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

Nicely done :)

Also be mindful of the pairs - a botnet could easily bypass the ip/login lockdown. Come up with some sane rules. It 
sounds like you've got a good head on your shoulders, if ANYTHING is trying too many times from one IP or too many 
attempts on one account or some combination of that, it should trigger an alert whe you can decide what to do from 
there.



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

Truncated for brevity, but agree with everything that was said here.

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

Joe jobbing is always a concern - although in my experience more of a fringe case. It's is where sane log alerting will 
help you a lot. You can deal with an obvious joe job on a case by case basis.

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

And that's the most important takeaway here. If your site is being attacked, I can almost promise you that it's not 
personal, they don't even know what your site does. A huge number of the hacks I see are engineered to harvest 
username/passwords.not for your site, but because odds are very good that those credentials will let them in elsewhere.

- snipe


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