Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Security by obscurity is the only kind that exists.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: