I think most people don't realise how many attack surfaces there are.
Good TLS and salt + strong hash solve the simple cases of DB theft and network MITM... But that's the bare minimum amount of protection.
As it does nothing for tokens being stolen, sessions, password reset hacks and emails being compromised.
It does nothing for stopping users trying to brute force. Password strength, loads of things mentioned.
I think the point is not really needing to know what good libraries mitigate against, but that you probably (as an individual) don't know all the ways that things can be compromised, and can't easily remember to implement them all, so you want a system that has been created, tested and improved by many security conscious people and out in the wild.
You probably wouldn't build your own lock for your front door either. The risks simply outweigh the benefits.
You're absolutely right, but there's one pretty critical point I want to make:
Good TLS and salt + strong hash solve the simple cases of DB theft and network MITM...
It doesn't even solve this that.
If you're explicitly salting your password hashes and not using a library, you're probably doing something very wrong.
Unless you're hashing your passwords with an expensive key stretching function such as bcrypt or scrypt (or even better, a CPU hard hash like argon2) anyone who get their hands on your database can very cheaply bruteforce about 90% of your passwords (all but the most expensive ones).
A salt will only protect you from rainbow table attacks, and while that's useful, since computing SHA-2 on a GPU is so mind-bogglingly fast today, it just doesn't mean much anymore.
Depends. Spending years researching security and finding as many possible attack vectors and accounting for those, plus, building tests for the situations will make for a very hardened system.
More eyes on security, can also mean a short time of eyes by a single person on a single problem - missing the bigger picture. Adding to the problem, security researchers are very few and very busy (I've hired). They don't have time to look at open source code, unless there's a possible reward (that's big enough).
I can see what you mean, but that's not to say a normal person would be likely to do it better themselves though. Lock levels are selected (perhaps naïvely sometimes), based on a certain tolerable level of inconvenience and cost factor.
Luckily software is cheaper to implement strongly, but still email + password is usually selected as the method in spite of being the easiest thing to crack (as far as getting into individual accounts is concerned).
We could get users to all use ubikeys or more complex forms of multiple factor auth.
We could make it so that if you compromise an email account, you can't just reset all the external account passwords using it.
Plenty of sites allow insecure passwords that are in rainbow tables and cannot defend against targeted attacks (unless a user actually selects a strong password themselves).
Also just as houses often have big windows that can be smashed, perfect crypto / secure auth practices fail to work with the presence of an exploit somewhere else in the stack are frequent sources of compromise too.
It's not a perfect analogy of course, but actually I don't think locks / houses is a bad one. Users don't value security enough to want the most secure locks on their accounts and frequently get annoyed if asked to use 2-factor Auth, multiple passwords for single sites etc.
Comments
I think most people don't realise how many attack surfaces there are.
Good TLS and salt + strong hash solve the simple cases of DB theft and network MITM... But that's the bare minimum amount of protection.
As it does nothing for tokens being stolen, sessions, password reset hacks and emails being compromised.
It does nothing for stopping users trying to brute force. Password strength, loads of things mentioned.
I think the point is not really needing to know what good libraries mitigate against, but that you probably (as an individual) don't know all the ways that things can be compromised, and can't easily remember to implement them all, so you want a system that has been created, tested and improved by many security conscious people and out in the wild.
You probably wouldn't build your own lock for your front door either. The risks simply outweigh the benefits.
You're absolutely right, but there's one pretty critical point I want to make:
It doesn't even solve this that. If you're explicitly salting your password hashes and not using a library, you're probably doing something very wrong. Unless you're hashing your passwords with an expensive key stretching function such as bcrypt or scrypt (or even better, a CPU hard hash like argon2) anyone who get their hands on your database can very cheaply bruteforce about 90% of your passwords (all but the most expensive ones).
A salt will only protect you from rainbow table attacks, and while that's useful, since computing SHA-2 on a GPU is so mind-bogglingly fast today, it just doesn't mean much anymore.
Depends. Spending years researching security and finding as many possible attack vectors and accounting for those, plus, building tests for the situations will make for a very hardened system.
More eyes on security, can also mean a short time of eyes by a single person on a single problem - missing the bigger picture. Adding to the problem, security researchers are very few and very busy (I've hired). They don't have time to look at open source code, unless there's a possible reward (that's big enough).
The most common front door locks sold are the ones people who pick can open the fastest, perhaps a bad analogy?
I can see what you mean, but that's not to say a normal person would be likely to do it better themselves though. Lock levels are selected (perhaps naïvely sometimes), based on a certain tolerable level of inconvenience and cost factor.
Luckily software is cheaper to implement strongly, but still email + password is usually selected as the method in spite of being the easiest thing to crack (as far as getting into individual accounts is concerned).
We could get users to all use ubikeys or more complex forms of multiple factor auth.
We could make it so that if you compromise an email account, you can't just reset all the external account passwords using it.
Plenty of sites allow insecure passwords that are in rainbow tables and cannot defend against targeted attacks (unless a user actually selects a strong password themselves).
Also just as houses often have big windows that can be smashed, perfect crypto / secure auth practices fail to work with the presence of an exploit somewhere else in the stack are frequent sources of compromise too.
It's not a perfect analogy of course, but actually I don't think locks / houses is a bad one. Users don't value security enough to want the most secure locks on their accounts and frequently get annoyed if asked to use 2-factor Auth, multiple passwords for single sites etc.