Password hacking - how to prevent?

Rate limiter does not help when the DB is dumped.

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).

Thank you,

I already use argon2 for hashing my passwords.

Is there a way to detect such an attack and block it?

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).

So you have to rely on third party auth to be secure?

Also can you mention those other methods that can be used to stop something like this?

Thanks in advanced

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.

Thank you for taking the time and explaining your point of view and experience, this really meant a lot.

Also if others would like to add to this discussion please do so.

Many opinions may provide multiple solutions

After searching a bit more on the Internet it appears that a table with unique salts combined with passwords can make an attacker’s life a bit harder.

Also a rate limiter may determine the hacker or in most cases the bot(automated attack server) to move on to easier targets.

If you like to review the info you can read it here from the Kaspersky blog What is a brute force attack?

This may be factually correct but it also centralizes authentication and gives the providers access to literally billions of social graphs.

This is not okay. Providers like Facebook and Google have a very poor track record of reusing such information to relentlessly chase you around with ads.

I like OAuth like everybody else due to it making the lives of users easier but let’s not pretend that centralisation of credentials is an innocent issue, especially when handed to corporations.

In the meantime, a lot of libraries provide pretty okay security: CORS, form tokens, Argon / Bcrypt / Scrypt with hashes, salts and peppers, cookies expiring in 1 hour, etc.

Let’s face the facts: if you use a modern library, you are very reasonably secure unless a state actor or spy agency targets you… In which case you are royally screwed anyhow.

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.

Also please don’t forget CSRF tokens that validate the request