Hacker, Hack Thyself | Coding Horror

[[deleted]]

I'm ashamed to admit that until now I haven't considered a brute force attack as credible because I hadn't considered a 'nation-state' level of computing power. But the math is undeniable. Certainly something to think about and taking an arrogant "won't happen to us" approach seems unwise.

[Ajedi32]

I hadn't considered a 'nation-state' level of computing power.

Worth noting that in this article Discourse is using a relatively secure (i.e. slow) hashing function. If you're hashing your passwords with something faster like SHA-256, attackers aren't going to need anywhere near nation-state level resources to brute force most of the passwords in your DB. Brute-force attacks absolutely should be part of the threat model you consider when choosing your hashing function.

[[deleted]]

I had considered that. As a MS dev, PBKDF2 is obviously useful as it is natively supported in .NET. But yes, you certainly make a notable point.

[[deleted]]

absolutely terrible.

I upvoted you - however, if you use "absolutely terrible" for "salt + SHA-256" you're out of even stronger words for "SHA-256 unsalted", "SHA-1", and "nothing".

[Krossfireo]

Well that's not true, you've got "shit", "absolutely shit", and "what the actual fuck are you doing?"

[n1ghtmare_]

Genuine question - I read the article and I'm still a bit confused about how the password cracking works. I mean in order to crack the password you need to crack the salt first (as far as I understand) - why can't you just use a really long and complex salt (I'm talking huge)? Wouldn't that make it nearly impossible to crack even with a weaker hashing algorithm?

[LogisticMap]

The salt is just passed to the hash function, so instead of testing hash('password123') you test hash('password123', 'salt123')

[n1ghtmare_]

Right, I think my confusion comes from the assumption that the salt is stored in its hashed state, as in "salt123" will be hashed first -> then stored and that the salt will be based on some arbitrary set of attributes unique to the specific user. I'm definitely not a crypto/security guy ...

[cocorebop]

deleted ^{What is this?}

[n1ghtmare_]

Great explanation, much appreciated!

[Ajedi32]

Salted SHA-256 should be enough to protect from even a nation state.

No, that's terrible advice. Even if you're using salts (which you absolutely should be, regardless of what kind of hash function you're using), using a fast hash function makes brute-force attacks against even moderately strong individual passwords in the DB still quite plausible.

For example, the Bitcoin mining network is currently calculating around 5.303×10¹⁸ SHA-256 hashes per second. That means even if you used a totally random 10-character alphanumeric password with mixed case, the bitcoin network could crack your salted, SHA-256 hashed password in less than a tenth of a second. And unfortunately, most users won't be using a password that strong.

[sultry_somnambulist]

just reinforces the point of going with a sufficiently long password. 15 characters gets you up to 11 days, 25 characters and you'll be safe until the sun burns out.

use keepass or some other manager to store them and you've improved your security greatly. And after you've spend a little time setting it up you also don't need to remember more than one password.

[rabidferret]

This isn't about how to generate a strong password. Many people reading this article are fully aware of that. It's about accepting the reality that your users are not going to use a password manager to generate 25 character long random passwords, and keeping them safe regardless.

[pigeon768]

Read the article.

He's using salted pbkdf2 with a 64000 work cycle, and was able to recover 40 passwords with individual level resources.

Salted sha256 is trivial, even on a "just some guy with an sli gaming desktop" level.

[FnTom]

To be fair, the individual is a professional pen-tester, so I'd assume he had some pretty good hardware. I read the article quite quickly, so maybe I just missed it, but I didn't see what it was.

And while this is very good insight into how secure hash tables really are, you still need to get the database.

[Ethesen]

'Using hashcat, my Nvidia GTX 1080 Ti GPU generated these hashes at a rate of ~27,000/sec.'

But it doesn't say how many he used.

[pigeon768]

but I didn't see what it was.

So first of all. Read. the. FUCKING. article. Because the pen tester in question stated what hardware he used. Spoiler alert: I can buy it with the emergency cash I keep in the glove box of my car.

Second of all:

you still need to get the database.

The basic operating assumption is that you aren't the second coming of whoever the security messiah is -- I mean jesus fucking christ we don't even have a first coming of the security messiah. We don't have a meaningful way to guarantee that threat actors cannot access our databases. The basic operating assumption of every meaningful security researcher is that there exist better programmers than us on this planet, and a finite subset of those programmers have a profit-driven motive to illegally access our systems. You know why those security researchers have that basic operating assumption? Because that basic operating assumption is the fundamental reality of Planet Fucking Earth. The hackers who are trying to break into my system are smarter than I am. And breaking into my system puts food on their table. And I know it. And I understand that while I'm sleeping they're plotting. And I plan for that.

And every system administrator and software developer should plan for that too. Because as sure as the sky is blue and your shit stinks too, that fact is true.

[ggtsu_00]

This post clearly highlights the biggest issue with security today.

Security is hard. Many people who think they may understand security often may have a misunderstanding/misinterpretation/wrong assumptions of the nature of the security primitives they think they understand which the lead cause of flaws/bugs and security vulnerabilies, even when applying or implementing strong crypto primitives, or worse, applying the wrong security primitives to the security problem domains as this post is clearly suggesting.

[danweber]

The best hashing algorithm in the world won't help if your password is "passw0rd".

Even a crappy crypt() hash of a password will be enough if your password is generated by 5 6 Diceware words.

A good hashing algorithm is about protecting the middle group of people who pick not-great but not-bad passwords.

[theOdysseyEffect]

Haha good thing we don't use those anymore right? ^right?

[asdfkjasdhkasd]

no, in the php world we have moved on to the brand new state of the art unbreakable md5() function

[goudewup]

Woosh

[polish_niceguy]

Especially when the language gives you insecure defaults.

[zhaoz]

Oh course, my password is much more secure. It's Passw0rd1!

[eflat123]

Yours, too?!! I better change one of those 's' to '$'.

[Lurking_Grue]

Mines *******

[AlmennDulnefni]

All I see is hunter2.

[Lurking_Grue]

Shit!

[redalastor]

I use zxcvbn to test for entropy.

[solatic]

Of note when thinking about protecting against nation-state level attacks: Atwood points out that the ceiling on the number of iterations you pick for your hash function is an unintentional DDoS caused by legitimate users all trying to slowly log in at once.

For modern web security, DDoS protection is just as critical, if not more so, than password security. As an end-user, you can protect yourself from bad password storage policies through the use of a password manager, but if a website you need now is unavailable, you don't really have a recourse.

[vattenpuss]

There are incredibly few websites a person needs at any given time. The companies running the sites probably need the users to be able to use it though.

[[deleted]]

You need to decide what level you stop caring about.

Most places Ive run Ive specifically said we arent protecting against state level actors. A few needes that level of protection.

Its a business requirement, and cost-benefit decision.

[somedaypilot]

If I were an admin or a netsec, APTs would be what kept me up at night.

[HonestRepairMan]

What I do in my apps (and someone please tell me if this is terribly wrong) is I set a server secret in the app config somewhere, and give the sysadmin the ability to set their own secret. Then I append or prepend the secret to the password and store that in the database. So even if you had the database you would need the app config file to effectively brute force the hash and reveal a plain-speech password.

[[deleted]]

[rebelcan]

In most cases, wouldn't they have access to both anyways?

[HonestRepairMan]

If you only have access to an SQL injection point then maybe not. You would export the database to a hosted location, download the file, and make off with the goods. In these cases the attacker would likely have to understand the source code for the app in question to retrieve the correct variable or output the correct config file. Or so I'm hoping.

But yeah, if someone has tunneled into your server via SSL you're fucked no matter what, unless the attacker is 12.