Does the number of passwords in the hashed list matter in terms of how easy or hard they will be to crack? Does this have implications for a rainbow table-type attack?
It would increase the likelihood of more common passwords being present in the list giving the attackers insight into what hashing technique was being used to store the passwords.
But the difference between 10,000 hashes and 10,000,000 would not make it easier to crack.
Just use a hardcoded application salt (significantly large, >128 bytes is more than enough) in addition to your per-user salt (stored in the DB, or derived from a DB field). That way, an attacker would need both code access and DB access to crack the hashes, and if that happens you're basically screwed beyond redemption anyway.
We really want to go the extra mile with Authic (it's going to be main selling point of outsourcing your webapps authentication with us), so we'll consider adding as many different aspects as possible.
And yes, you do have big problems if someone has access to your db AND code, but if you have done your job properly at least it will be very difficult/expensive/time consuming for the attackers to crack your hashes.
In the worst case scenario of someone dumping your entire database, you want there to be as much time as possible to contact your user base to let them know of the breach so that they can update their passwords before the crackers have finished the job.
Doesn't that still leave the door open to database compromise?
What are the practicalities of distributing the system among various technology stacks, minimizing the damage caused by a 0day or single engineered attack vector? Really thats just security by obscurity and the solution should be a robust system to begin with but I'm wondering about anticipating the human mistakes that render an otherwise secure system into a series of news articles like we're seeing.
Doesn't that still leave the door open to database compromise?
Well, if you have it in the same DB table you are still at the mercy of database compromise. Better would be to store the salts in a separate table from your password hashes. Better yet, store it in a different database. And even better, store it on a different server.
What are the practicalities of distributing the system among various technology stacks, minimizing the damage caused by a 0day or single engineered attack vector?
Yes, having the salt in a different type of db from the hashes adds protection from zero day exploits exposing one brand of db. A combo of NoSQL and SQL seems logical.
Really thats just security by obscurity
Security through obscurity is not a bad thing, as long as it is not the only measure you are taking. But anyway, you need to have security through obscurity - or are you suggesting that making your salts and hashes publicly accessible would be ok? Or is it a good idea to obscure it?
and the solution should be a robust system to begin with
Of course, you should do everything possible to make system secure. A big part of this is to try to minimize the number of single point of failure attack vectors.
but I'm wondering about anticipating the human mistakes that render an otherwise secure system into a series of news articles like we're seeing.
Well, a lot of these news articles could be lot less worrying if people were salting their password hashes properly.
