Play-by-play on the phpbb.com hack(erratasec.blogspot.com)
erratasec.blogspot.com
Play-by-play on the phpbb.com hack
http://erratasec.blogspot.com/2009/02/importance-of-being-canonical.html
6 comments
The second thing is to fix the password problem. They should force users to create more complex passwords when they log in.
Seen from a security perspective this adds to the overall security of the site, however most users simply find an easy password that fits the bill. blink182, 123456qwerty, qwerty! - which is almost as easy to bruteforce or keep in a rainbow table as normal dictionaries.
You should be aware, however, that password requirements detract from the user experience. When users pick a password for a new account they are at the most crucial part of a website: The sign-up. This is where you can lose people that were otherwise ready to sign up.
So it's a trade-off. If your site holds credit card numbers, or other vital information a certain minimum requirement for passwords is certainly in place, but if your site is something like HN, where no valuable information is held, you should probably just let users pick whatever password they like. Worst case they will lose a few comments and some karma.
Seen from a security perspective this adds to the overall security of the site, however most users simply find an easy password that fits the bill. blink182, 123456qwerty, qwerty! - which is almost as easy to bruteforce or keep in a rainbow table as normal dictionaries.
You should be aware, however, that password requirements detract from the user experience. When users pick a password for a new account they are at the most crucial part of a website: The sign-up. This is where you can lose people that were otherwise ready to sign up.
So it's a trade-off. If your site holds credit card numbers, or other vital information a certain minimum requirement for passwords is certainly in place, but if your site is something like HN, where no valuable information is held, you should probably just let users pick whatever password they like. Worst case they will lose a few comments and some karma.
Worst case they will lose a few comments and some karma.
I think the worse case is actually substantially worse -- call it an identity escalation attack. I think a huge number of Internet users are vulnerable to it:
a) Use any means you please to compromise the password on a low-security site, such as HN.
b) Use the same login credentials at other low-security sites, such as Facebook and Twitter. These compromises are valuable in their own right, but what you are really looking for is the email address.
c) After you have their email address, compromise it using variations on the same password you already know.
d) You can now read their email. Search for "statement", and identify which bank they bank with. Go to bank and try logging in with their email and password. That probably just worked. If not, click "lost password", supply email address and their security question (you have their Facebook already or can in seconds, how hard will it be to find their mother's maiden name or middle school?), and enjoy.
e) For added fun, look for other high-value accounts whose security is premised on the email user being authorized, such as brokerages (a tough target due to strong institutional controls, like banks) and GoDaddy (a successful compromise would cost me FAR more than what I have in my bank account).
The worst part? You can automate large portions of this attack (given a list of usernames and password, writing a script to try them at a dozen or a hundred popular services is child's play) and outsource the rest right up until the "compromise bank account" portion.
I think the worse case is actually substantially worse -- call it an identity escalation attack. I think a huge number of Internet users are vulnerable to it:
a) Use any means you please to compromise the password on a low-security site, such as HN.
b) Use the same login credentials at other low-security sites, such as Facebook and Twitter. These compromises are valuable in their own right, but what you are really looking for is the email address.
c) After you have their email address, compromise it using variations on the same password you already know.
d) You can now read their email. Search for "statement", and identify which bank they bank with. Go to bank and try logging in with their email and password. That probably just worked. If not, click "lost password", supply email address and their security question (you have their Facebook already or can in seconds, how hard will it be to find their mother's maiden name or middle school?), and enjoy.
e) For added fun, look for other high-value accounts whose security is premised on the email user being authorized, such as brokerages (a tough target due to strong institutional controls, like banks) and GoDaddy (a successful compromise would cost me FAR more than what I have in my bank account).
The worst part? You can automate large portions of this attack (given a list of usernames and password, writing a script to try them at a dozen or a hundred popular services is child's play) and outsource the rest right up until the "compromise bank account" portion.
Thanks for posting the link. I found this particular tidbit especially useful:
"The first is to create 'canary' accounts. Create accounts that have e-mail addresses, like "[email protected]". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database."
"The first is to create 'canary' accounts. Create accounts that have e-mail addresses, like "[email protected]". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database."
The problem with this advice is that it is not particularly useful.
In the event that your canary account receives a spam message, you will have gained one piece of data: that at some point in the months since you installed the account, it is likely that someone exploited a problem that exposed a table column in your database.
Now what?
You don't know what the bug was. You don't know how far-reaching the damage is. You don't know when the event occurred. There is, in fact, almost nothing actionable about this information at all.
You might be telling yourself two things:
* That, upon learning of the possible breach, you will lock down the security of your code and your site. Of course, think for two more seconds and realize this is ass-backwards; if you can reasonably lock down your site, you might as well do it before you burn your whole database.
* That, upon learning of the breach, you can get all your users to change passwords. Which, of course, you will never do, because you will be taking an enormous reputational hit over circumstantial evidence, and for the purposes of seeding your database with a couple thousand new passwords for the same attacker to steal.
People like this "canary" and "honey token" stuff because it's fun. But it's not valuable.
In the event that your canary account receives a spam message, you will have gained one piece of data: that at some point in the months since you installed the account, it is likely that someone exploited a problem that exposed a table column in your database.
Now what?
You don't know what the bug was. You don't know how far-reaching the damage is. You don't know when the event occurred. There is, in fact, almost nothing actionable about this information at all.
You might be telling yourself two things:
* That, upon learning of the possible breach, you will lock down the security of your code and your site. Of course, think for two more seconds and realize this is ass-backwards; if you can reasonably lock down your site, you might as well do it before you burn your whole database.
* That, upon learning of the breach, you can get all your users to change passwords. Which, of course, you will never do, because you will be taking an enormous reputational hit over circumstantial evidence, and for the purposes of seeding your database with a couple thousand new passwords for the same attacker to steal.
People like this "canary" and "honey token" stuff because it's fun. But it's not valuable.
If I called you and said, "Hey, would you like me to tell you your site has been cracked?", would you really say "no"? I would argue that the cost of adding a canary is similar to the amount of time that phone call would take.
I'm guessing that after that call, you'd go through your logs and attempt to find out how the site was cracked. Then, if you find some anomalous behavior, you might be able to isolate the component that was being exploited and fix it. Maybe you wouldn't find it, but maybe you would.
I'm guessing that after that call, you'd go through your logs and attempt to find out how the site was cracked. Then, if you find some anomalous behavior, you might be able to isolate the component that was being exploited and fix it. Maybe you wouldn't find it, but maybe you would.
What's your point? Sure. Set up a canary account. It won't hurt you. But the only way it will help is if your monitoring regime is already so good that it works with or without the canary.
But wouldn't the "canary" idea be more useful if the email was changed frequently? Suppose a cron job updated the email address every day to include a few non-obvious characters encoding the current date so that the spam you get tells you when that row was copied from your database.
No, that wouldn't improve it at all. The problem with the canary is that it's a weak, not particularly useful signal: "we probably got compromised".
Here, let me help all of you with web apps out right now: you have probably been compromised.
Go do something about it. Then come back and tell me what you did.
Here, let me help all of you with web apps out right now: you have probably been compromised.
Go do something about it. Then come back and tell me what you did.
To me it makes sense to keep good records of security events so if I were to get this "signal" I'd make sure the details were captured and the appropriate people informed. Then I'd double check the obvious things like who logged into the database server that day, who had access to backups, who may have worked on database code in that time, when that code was last (or ever) audited and so on.
What if you automatically created a new canary every day with the date in it? Something like [email protected]. Then you could find out exactly when your database was stolen. If all canaries up to 2009-01-01 were spammed, and later ones weren't, you'd know they dumped your db on New Year's Day.
Not sure how much that would help either though.
Not sure how much that would help either though.
All that would tell you is the earliest date your database was compromised and then sold to spammers. If an attacker can harvest your database once, they can do it repeatedly --- which is why warning all your users to change their passwords in this situation is a bad idea.
I know that I'm more likely to find a bug if I know it's there than if I'm just reviewing my own code for the hell of it.
You are highly unlikely to find your own bugs; teams that have invested millions of dollars in training and process (for instance, requiring detailed internal code reviews before signing off on code to ship, and passing static analysis systems) still have gameovers shown to them during third party pen tests.
Agreed -- I thought that was a good idea (useful + cheap to implement + low false positive rate).
One thing I've also debated about before is whether to use a per-site or a per-user salt for passwords. From this article, it sounds like a per-site hash is enough to defeat the rainbow table services.
One thing I've also debated about before is whether to use a per-site or a per-user salt for passwords. From this article, it sounds like a per-site hash is enough to defeat the rainbow table services.
Not sure I agree. It seems true that a per-site hash would be enough to defeat _just_ the rainbow table services, but I wouldn't want to have the hacker be able find one password and then be able to distinguish what the salt is for everyone. I would rather have this mitigated by knowing that even if the hacker does brute-force one password, he still won't know the salt for anyone else.
I'm just going to remind you that if you are talking about your code and you are using words like "salt" and "rainbow table" you have already lost.
Yeah, I don't think I made the point I meant to make. Previously, I was under the (silly) assumption that folks who were trying to brute force passwords were running their own rainbow set ups, generating them as necessary based on whatever per-site hash was being used. But the fact that services exist for cracking this sort of thing implies that there are plenty of sites that aren't using salts at all, and by using a per-site salt, you are not the softest target.
None of this matters if someone is trying to crack your site in particular, but sometimes you just have to be faster than the slowest gazelle in the herd.
None of this matters if someone is trying to crack your site in particular, but sometimes you just have to be faster than the slowest gazelle in the herd.
Why not use both a per-site and a per-user salt?
The original (first person) story is here, but the erratasec post adds a lot: http://hackedphpbb.blogspot.com/2009/01/place-holder.html
I'm going to check milw0rm constantly now and try to avoid/update services. The Google Chrome and VNC vulnerabilities look particularly bad.
They've got a twitter account: http://twitter.com/milw0rm
How much more productive would the world be if it didn't have to worry about hackers breaking into our sites?
What you should be doing is using bcrypt, tuned to take several hundred milliseconds per crypt. /usr/share/dict/words --- a pitiful dictionary --- with even the most basic set of permutations will take weeks to test a single password under this regime. Bcrypt is free and available for every major web platform. I didn't write it; the guys who did, David Mazieres and Niels Provos, are much smarter than me.
Computer science has solved the brute force problem on passwords, and we should stop dithering and adopt the solution.