I admit to being somewhat guilty of this, but I'm astonished anyone would use the same password for throwaway email acconts as for financial stuff. I do use only like 2 different passwords for all my stupid little Internet forum accounts, though.
I have been considering implementing something like a captcha code on my login forms (but haven't yet).
To brute force crack a password, you would really need direct access to the digest. We are talking around the order of 2^80 attempts before finding a collision with a algorithm like SHA-1. Checks need to happen very fast. Doing this through a web interface is already too slow to be feasible from a time perspective.
So really, cracking passwords is only a consideration when someone gets a hold of all your digests (eg. your database) and can crunch away on them locally for a long time.
SHA1 is strong (at least in this application). Passwords are very, very weak.
I have always assumed the database server is safe there alone on it's own network as long as someone doesn't break into a machine that is connected to that network.
for at least 2 weeks.
"Several sentences of very informative information and background on the topic of security for those non-experts (vast majority of us).
One sentence calling the parent poster an embarrassing retard."
Seriously though, I appreciate the insight into the topic and enjoyed your reply post to the one at Coding Horror. Thanks to you I finally understand the reason a decent salt matters, and I'll be sure to ditch SHA1 for bcrypt when I get home. You can rest assured I'm not trying to design my own password system (for anything public)... I was just wondering, are there other systems that do authentication without actually sending the password over the wire besides the supposedly-hard-to-implement Stanford one that may or may not be patented? Bonus points if it's open source...
As for the parent comment: I just really like that picture.
Regarding challenge-response alternatives to SRP: I don't think these work well on the web.
Reason 1: on almost anything unencumbered by the Thomas Wu patent, you're going to have to store cleartext passwords on the server, which is probably worse than forcing clients to send passwords over the wire.
Lesson: use someone else's (good) password system.
(ok, this isn't an option for everybody yet)
Ok, what? I use Ruby on Rails, and I want something open source. What do you recommend?
Truthfully, this isn't even worth talking about. If your user's passwords are compromised, you've already lost the security battle. Hopefully you weren't actually storing something important.
That said, I personally don't mind plaintext passwords if there's a good usability story that goes along with it and if the security tradeoff is negligible. I put the odds of my user database being exposed at approximately zero, so generally it's a fine design decision. When was the last time you heard of passwords being stolen en masse from a major site that didn't also include a hard drive being stolen?
I have no idea why you think the public is told every time a a password table is dumped. In fact, change that "every" to "any".
Here, let me make this easier for you: if you ever plan to monetize your application, you will fail PCI audits for doing a crappy job with password storage. But I'll do you one better and give you a tip from the trenches: if some lame PCI auditor sees that you don't know what you are doing, his company is going to roll you for 8 billable weeks, laughing at you the whole time, before they give you the meaningless stamp of approval that lets your process credit cards.
I'm not a security expert. I write webapps. I'm open to learning new techniques and using other people's libraries. However, I need to balance that against the need to get something out the door. As mynameishere put it, I'd love to have a website that's even worth breaking in to.
If there's some sort of tutorial out there that says "For passwords, use this library. For SQL injection, escape your parameters with this procedure. Here's how to secure your server from being rooted. Add these lines to your mailserver's config to avoid being used as a spam vector", I'd love to read it.
A larger key is always more secure.
The mistake you're making is your misuse of the word "key". Larger keys are more secure. A salt is a nonce, not a key.
Can I say again that people shouldn't be rolling their own password scheme? This is a problem that has been well-addressed for decades, but the majority of new applications still ship with code that is inferior to public domain code from 1976.
I'm not ready to stop thinking about hash dictionaries, and the 4-character salt I prepend to passwords before hashing is too short. A 4-character salt plus a 7-character password is a value that could be vulnerable to dictionaries roughly the size of the Rainbow tables.
But if you can cite a paper demonstrating that brute-force cracks of individual passwords are the only thing one need be concerned about, I'll look at it and see if it changes my mind.
The answer to this is to use someone else's (good) password scheme. If you're shipping on Unix, your system undoubtedly comes with one. Use it.
I'm not arguing that users should be forced to choose secure passwords. They should, of course, but we're talking about how you store them. If you store them using a single-iteration SHA1 hash, then no matter how you structure your nonces, your scheme is insecure and you should be embarassed.
I ask, what type of attack do you think lengthening the nonce deters? The attacker who is going to construct 4 billion rainbow tables?
If I move to, say, a 16-character salt, after that I'll agree that making it longer is pointless.