A multitude of ways, all of the passwords he used were in insecure database’s, just hashed or hashed and salted or so.
First of all, if you are implementing username/passwords in your app, then you are almost assuredly wrong. Don’t do that. If you think you need to do it you are almost certainly wrong. Use OIDC to an actually tested server and backend system or so.
Second, if you have to implement username/password yourself then use bcrypt or argon or so, those are not just hashing algorithms, they are specifically designed to be extremely slow to hash, which would make an attack like this take a few years to a few thousand years (depending on your complexity settings for it) essentially per password as you can’t reuse a hash from one on another even if the password is identical.
Essentially, that brute force attack only works on very poorly designed systems, which is almost every system out there, hence why you want to use OIDC only to well designed systems (facebook, google, github, whatever).
That attack happens if they managed to get access to and dump your database. Nothing you can do on the HTTP server side other than just not letting it happen ‘through’ it (not saying there aren’t other methods though, depending on how the server is built).
It ‘increases’ your chance of security because an OIDC’s server is specifically designed to be hard to breach by every major company that hosts them.
All application specific. Like if you host a SQL database then make sure it’s not accessible except to the sole server that requires it, make sure it can’t run untrusted code, make sure the server that can access it cannot run untrusted code, etc… etc… etc… It’s an almost impossible task to get right and almost none of it relates to the HTTP server like phoenix itself. I consider any site that doesn’t allow me to use only third-party OIDC auth like google/github while disabling local-auth on my account as inherently insecure, and they get a corresponding single-use password and I try to never go there to begin with or put anything important at all.
You can’t prevent such brute force attacks. That means your DB has already been leaked. That’s why it’s recommended to have unique salts on passwords and use something like argon2 that slows down brute force attacks even on specialized hardware, so passwords are very difficult to crack in the worst case scenario of a DB leak.
You’ll remove that responsibility by using a third party with OIDC. I think a better alternative may be WebAuthn that can forego passwords, and prevent phishing. I hope to implement it in Pow at some point.
First rule of security is to never roll your own. The best is to use a maintained and audited open source library to handle auth.
You should follow industry practices, but cracking of password shouldn’t be a big worry. There are plenty of other threats that are much more likely. Phishing is much easier than cracking password. Or DB leak that gets access to personal information can be much more valuable than a password.
A bit but not too much, with how sharded out you can do most hash functions, this is why bcrypt/argon2 is so much better.
Only for querying via the server, but that will be so slow even without rate limiting to be near worthless. What will be done is to get a dump of the database, that is why every leak is via one of those.
True, this is why original OpenID was so nice (and I strive to support it on a few things I build), that way people host their own authentication on whatever domain they themselves control.
Yet, being honest, these corporations are the most likely ones to get the security right.
Which works fine until they get access to the server anyway, which is the number one reason all those leaks happen. Even with a fully bcrypt/argon2 hashed database (those have built-in unique salts) they can just add their own code to log the HTTP requests for example, passwords and all, and people have a surprising tendency to not notice those things for years.
Secure in that stuff sure, but you’d be surprised at how often those routes aren’t the cause of leaks.
WebAuthn will be a huge help, if implemented well!
This is the Golden Rule of authentication. Everyone gets it wrong, it’s just a matter of who gets it least wrong.
That’s unequivocally true. Still, I’d prefer being 85% secure and anonymous (anonymity itself is a pretty powerful shield!) as opposed to 99.9% secure and my personal data harvested and used against me – as is the case with personally-identifiable information since forever.
True. At this point all bets are off, really.
Oh I know. Phishing remains #1 cause of account takeovers, be it normal emails or social profiles or sysadmin root password vaults. Zero-days are #2. I believe @wolfiton is concerned about the wrong thing – brute forces only worked for a few years back in the dial-up modem days with amateur-level authentication gateways. Brute-forcing of passwords hasn’t worked well in decades.
IMO hardening your HTTP listener and sanitising your user input are your best bets when you manage an app server by yourself. That’s one of the value propositions of the clouds: good luck hacking or DDoS-ing CloudFlare!