Password hacking - how to prevent?

[wolfiton]

Hey community,

After reading this https://hackernoon.com/20-hours-18-and-11-million-passwords-cracked-c4513f61fdb1

I thought i should share it with all of you and maybe find a solution to this potential problem.

My questions are:

Can this brute force attack be stopped?

If so how?

What is the best defense to prevent such an attack?

Also can a rate limiter prevent this penetration in the database?

Thanks and hope to hear your points of view on this.

[OvermindDL1]

@wolfiton

Also can a rate limiter prevent this penetration in the database?

Rate limiter does not help when the DB is dumped.

@wolfiton

Can this brute force attack be stopped?

If so how?

What is the best defense to prevent such an attack?

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

[wolfiton]

@OvermindDL1

Second, if you have to implement username/password yourself then use bcrypt or argon

Thank you,

I already use argon2 for hashing my passwords.

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

[OvermindDL1]

@wolfiton

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

[wolfiton]

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

[OvermindDL1]

@wolfiton

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

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.

@wolfiton

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

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.

[wolfiton]

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

[wolfiton]

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?

[dimitarvp]

@OvermindDL1

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

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.

[danschultzer]

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.

[wolfiton]

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

[OvermindDL1]

@wolfiton

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.

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.

@wolfiton

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

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.

@wolfiton

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

Seems accurate.

@dimitarvp

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.

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.

@dimitarvp

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.

Yet, being honest, these corporations are the most likely ones to get the security right.

@dimitarvp

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.

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.

@dimitarvp

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.

Secure in that stuff sure, but you’d be surprised at how often those routes aren’t the cause of leaks.

@danschultzer

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.

WebAuthn will be a huge help, if implemented well!

@danschultzer

First rule of security is to never roll your own.

This is the Golden Rule of authentication. Everyone gets it wrong, it’s just a matter of who gets it least wrong.

[wolfiton]

Also this may be a new player to help with user identity https://sovrin.org

Although it’s extremely risky to store your personal data in someone else’s server and trust them to keep you protected.

Has anyone used similar services based on blockchain?

[danschultzer]

It’s a different problem they try to solve. Their focus is on KYC (e.g. for banks), not authentication.

[dimitarvp]

@OvermindDL1

Yet, being honest, these corporations are the most likely ones to get the security right.

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.

@OvermindDL1

Which works fine until they get access to the server anyway

True. At this point all bets are off, really.

@OvermindDL1

Secure in that stuff sure, but you’d be surprised at how often those routes aren’t the cause of leaks.

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!

[wolfiton]

@dimitarvp

@wolfiton is concerned about the wrong thing

That maybe so, but don’t want to find out the hard way in productions that my applications are going down due to DDOS(Denial of service attacks ) or brute force password hacking or database dumps.

As they always say:

better be wrong in dev, then in production

Also

better be safe then sorry

I think this words posses a lot of wisdom.

Also appreciate all the ideas and solutions so far.

Thank you all!

[wolfiton]

Thank you all for the valuable informations and solutions to this topic.

I don’t think anyone else wants to add something more so i am closing it.