wolfiton
Password hacking - how to prevent?
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.
Marked As Solved
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.
Also Liked
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.
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.
OvermindDL1
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.
Seems accurate.
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.
dimitarvp
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!
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








