5 ms·

Presumably checking user passwords for security is out of scope? How do you mitigate credential stuffing attacks? Throttling per account? Globally? By source I

Presumably checking user passwords for security is out of scope? How do you mitigate credential stuffing attacks? Throttling per account? Globally? By source IP? A user leaves their company. How do you automatically deactivate their account? You're using password hashes. Cool. A secure password hash function, right? Scrypt, argon2, maybe bcrypt? (MD5, SHA1, and SHA2 are not password hashes.) You're comparing them in constant time, right? Are you sure? The compiler hasn't "optimized" you into problems here? You're working with enterprise websites. You obviously support 2FA; and you're probably going to want to support SSO with SAML2, and definitely integrate with Active Directory over LDAP. And your password reset flow- just send an email with a magic link? do you generate the magic link's token with a CSPRNG? Is it long enough? When does it expire? And admins probably have to be able to reset anybody's password, but with strong auditing and accountability features... You store user info in the session information- basically caching it out of the database? How do you invalidate sessions after a user changes their password or has their account disabled? Can somebody put Unicode in their password? You're writing a POST handler. You protect against CSRF, right? (yes, tricking somebody into logging in as another user can be very useful!) Doesn't seem so simple to me...

fredsted 7y ago
Good points. Difficult and unforeseen issues like these are exactly why you'd use a framework of some kind, where thousands of users have already tested and fixed various issues.
foota 7y ago
Nit: I don't believe that comparing hashes in constant time is important, as long as you accept the user's password and then hash it, since being able to find the prefix of the hash is computationally just as hard as reversing the hash. Though it doesn't hurt to do anyway :) It is important when comparing (some forms of) auth tokens, such as csrf tokens.
- thephyber 7y ago
  Side note: Using the language the correct way to compare hashes is important. Researchers found that PHP can coerce strings into scientific notation if the hash begins with “0e...” and using the == != operators, thereby causing a massive error space[1] [1] http://www.darkreading.com/vulnerabilities---threats/php-hash-comparison-weakness-a-threat-to-websites-researcher-says-/d/d-id/1320353 http://www.darkreading.com/vulnerabilities---threats/php-has...
  - foota 7y ago
    sob
sammorrowdrums 7y ago
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.
- tmikaeld 7y ago
  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).
- unscaled 7y ago
  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.
- ta999999171 7y ago
buboard 7y ago
incidentally though i ve not had passwords stolen from custom-built authentications (that were not as strong as u say), but i did from cms systems that are common and thus have tons of bots attacking them (e.g. wordpress). Security through obscurity should be added to off-the-shelf auth libraries i guess
james_s_tayler 7y ago
Sounds like the perfect job for outsourcing to a 3rd party solution or using a battle tested framework!
blablabla123 7y ago
It's not so simple but also not an obscene amount of effort. Even with a Micro framework the first iteration should be there after a week or two. Probably most effort is 2FA and the whole E-Mail sending, verification etc. Especially testing this :/ Reliable implementations for hash functions are available for literally any language that is used in production. They take care of all the problematic parts. (In fact nobody should write this by himself or herself) I'm sure as a custom implementer it's still possible to accidentally sneak in something time-dependent (still difficult to exploit, with smart rate limiting in place, I would say forget it) or a null/whitespace bug (easy to exploit but might require custom tooling). But that's just a matter of testing and having a 2nd pair of eyes look over it. How do you know an off-the-shelve solution doesn't have the same problems or different ones? With a limited time/money budget auditing someone else's code is far more effort than doing the same thing with the own code.

fredsted 7y ago

Good points. Difficult and unforeseen issues like these are exactly why you'd use a framework of some kind, where thousands of users have already tested and fixed various issues.

foota 7y ago

Nit: I don't believe that comparing hashes in constant time is important, as long as you accept the user's password and then hash it, since being able to find the prefix of the hash is computationally just as hard as reversing the hash. Though it doesn't hurt to do anyway :) It is important when comparing (some forms of) auth tokens, such as csrf tokens.

thephyber 7y ago
Side note: Using the language the correct way to compare hashes is important. Researchers found that PHP can coerce strings into scientific notation if the hash begins with “0e...” and using the == != operators, thereby causing a massive error space[1] [1] http://www.darkreading.com/vulnerabilities---threats/php-hash-comparison-weakness-a-threat-to-websites-researcher-says-/d/d-id/1320353 http://www.darkreading.com/vulnerabilities---threats/php-has...
- foota 7y ago
  sob

sammorrowdrums 7y ago

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.

tmikaeld 7y ago
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).
unscaled 7y ago
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.
ta999999171 7y ago

buboard 7y ago

incidentally though i ve not had passwords stolen from custom-built authentications (that were not as strong as u say), but i did from cms systems that are common and thus have tons of bots attacking them (e.g. wordpress). Security through obscurity should be added to off-the-shelf auth libraries i guess

james_s_tayler 7y ago

Sounds like the perfect job for outsourcing to a 3rd party solution or using a battle tested framework!

blablabla123 7y ago

It's not so simple but also not an obscene amount of effort. Even with a Micro framework the first iteration should be there after a week or two. Probably most effort is 2FA and the whole E-Mail sending, verification etc. Especially testing this :/ Reliable implementations for hash functions are available for literally any language that is used in production. They take care of all the problematic parts. (In fact nobody should write this by himself or herself) I'm sure as a custom implementer it's still possible to accidentally sneak in something time-dependent (still difficult to exploit, with smart rate limiting in place, I would say forget it) or a null/whitespace bug (easy to exploit but might require custom tooling). But that's just a matter of testing and having a 2nd pair of eyes look over it. How do you know an off-the-shelve solution doesn't have the same problems or different ones? With a limited time/money budget auditing someone else's code is far more effort than doing the same thing with the own code.