Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Volmarias posted:

I hate to resurrect password chat, but I don't understand this line. Is the idea that your cracker will find

derpPassword1
derpPrettyPrincess

etc and you can figure out that "derp" is the salt pretty quickly, letting you power through the rest?

Basically it means that instead of having to try and break hashes one-by-one, you can hash "derpabc123", and check that hash against the entire list to see if anyone at all has abc123 as their password.

# ? Mar 5, 2013 01:38

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 13:46

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Volmarias posted:

I hate to resurrect password chat, but I don't understand this line. Is the idea that your cracker will find

derpPassword1
derpPrettyPrincess

etc and you can figure out that "derp" is the salt pretty quickly, letting you power through the rest?

If you have a system wide salt, and are not bolstering it with a random salt or some other mechanism, an attacker can look at the most frequent password hashes in the data and basically guess what they are.

I'm not up on my crypto enough to know if you have the salt+hash -> plaintext if you can "work back" to the salt. I *think* depending on the cipher this is possible and that's all she wrote for the whole DB.

You could also brute force the salt if you have any information on the cipher.

# ? Mar 5, 2013 01:43

tractor fanatic: Sep 9, 2005; Pillbug

trex eaterofcadrs posted:

I'm not up on my crypto enough to know if you have the salt+hash -> plaintext if you can "work back" to the salt. I *think* depending on the cipher this is possible and that's all she wrote for the whole DB.

If you could discover the salt from knowing plaintext and hash, wouldn't that be equivalent to discovering plaintext from knowing salt and hash? I'm pretty sure salt and plaintext are interchangeable here. Plus, you can easily make this a chosen plaintext attack by just registering an account of your own.

# ? Mar 5, 2013 02:10

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

tractor fanatic posted:

If you could discover the salt from knowing plaintext and hash, wouldn't that be equivalent to discovering plaintext from knowing salt and hash? I'm pretty sure salt and plaintext are interchangeable here. Plus, you can easily make this a chosen plaintext attack by just registering an account of your own.

Well you don't know the hash, you only know the one quantity salt+hash. I'm not sure if you can, in one step, reduce a salt+hash to just a salt given a plaintext and the salt+hash. Maybe if you have enough known values ... attacking crypto isn't my strong suit

# ? Mar 5, 2013 02:33

pseudorandom name: May 6, 2007

ultramiraculous posted:

There's the Security Fuckup Megathread in YOSPOS...

Which is currently an argument about tool assisted speed runs...

# ? Mar 5, 2013 03:20

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

trex eaterofcadrs posted:

Well you don't know the hash, you only know the one quantity salt+hash. I'm not sure if you can, in one step, reduce a salt+hash to just a salt given a plaintext and the salt+hash. Maybe if you have enough known values ... attacking crypto isn't my strong suit

If you're adding the salt after hashing, you're very emphatically Doing It Wrong.

The whole point of the salt is that it goes in before hashing, forcing a brute-force attacker to attack one hash at a time.

# ? Mar 5, 2013 04:22

Nippashish: Nov 2, 2005; Let me see you dance!

If you're using a random per-user (or whatever) salt how do you check the password when the user logs in? Do you store the salt somewhere? If so where, and why is this less vulnerable than not using a salt at all. If not then wtf how does that work?

# ? Mar 5, 2013 04:36

tractor fanatic: Sep 9, 2005; Pillbug

If you don't salt then an attacker could precompute hashes, at least for common passwords, and just lookup what hashes match for databases that don't salt. If you use a global salt then the attacker can find out your global salt, and do attacks against your entire database. When you store a per-user salt, the attack has to attack each password hash individually, even knowing the individual salt.

# ? Mar 5, 2013 04:41

npe: Oct 15, 2004

Nippashish posted:

If you're using a random per-user (or whatever) salt how do you check the password when the user logs in? Do you store the salt somewhere? If so where, and why is this less vulnerable than not using a salt at all. If not then wtf how does that work?

The point is that when your database is leaked because someone dumped out an old db archive that wasn't as well secured, or whatever infrastructure leak you discover, they still can't reverse the hash into your actual password that you typed in. This literally just happened with LinkedIn - someone ended up with all of the hashes from their database, and they were able to very quickly reverse a LOT of those hashes into the user's actual password!

Why? Because they could simultaneously attack *all* passwords at once. That is, start a dictionary attack, hashing each possible word and checking all the stolen password hashes for any hits. Run this on a large grid over a few days, and you will get a lot of hits - all of the weakest passwords in your userbase.

If they had randomized per-user hashes (and even if the attacker has possession of those hashes, which you should assume), they would have to run a new dictionary attack on each hash individually. This means that your weakest passwords aren't instantly crackable via a rainbow table or dictionary attack.

# ? Mar 5, 2013 04:49

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Nippashish posted:

If you're using a random per-user (or whatever) salt how do you check the password when the user logs in? Do you store the salt somewhere? If so where, and why is this less vulnerable than not using a salt at all. If not then wtf how does that work?

The thing to understand is that there is nothing here which is uncrackable. With enough time and CPU cycles available they will be able to solve the large majority of passwords in a database. The objective of the security provided is to make the process as slow as possible to make a full breach less achievable in this life time. Per User salting is THE most effective tactic available to increase this time, as it ensures each password must be attacked individually. The next tactic is ensuring your hashing function uses a slow encryption method which means each brute force guess takes more time to compute, again slowing the rate of cracking.

# ? Mar 5, 2013 05:48

shrughes: Oct 11, 2008; (call/cc call/cc)

Maluco Marinero posted:

Per User salting is THE most effective tactic available to increase this time, as it ensures each password must be attacked individually. The next tactic is ensuring your hashing function uses a slow encryption method which means each brute force guess takes more time to compute, again slowing the rate of cracking.

No, using a slow hash function is more important than using per-user salting.

# ? Mar 5, 2013 11:31

Funking Giblet: Jun 28, 2004; Jiglightful!

shrughes posted:

No, using a slow hash function is more important than using per-user salting.

No, use both. Computers will speed up, so if the password isn't rehashed again, it will soon become vulnerable to attack.

# ? Mar 5, 2013 11:44

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Funking Giblet posted:

No, use both. Computers will speed up, so if the password isn't rehashed again, it will soon become vulnerable to attack.

I don't think you understand just how slow slow hash functions are.

# ? Mar 5, 2013 11:46

Funking Giblet: Jun 28, 2004; Jiglightful!

Aleksei Vasiliev posted:

I don't think you understand just how slow slow hash functions are.

Doesn't matter how slow it is if you have numerous duplicate hashes, and used the most likely passwords against those duplicates hashes. Also, COMPUTERS WILL SPEED UP BY ORDERS OF MAGNITUDE!

BCrypt etc also generate salts as part of the password, because if they didn't, the passwords could be guessed by eyeballing a large dataset.

# ? Mar 5, 2013 11:51

ymgve: Jan 2, 2004; Offensive Clock

Without a proper salt, your effective cracking speed increases linearly with the number of passwords you're cracking. Without salts, a slow function doesn't help. Without a slow function, salt doesn't help. You need both.

# ? Mar 5, 2013 12:20

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Yeah, I shouldn't have phrased it as an order of priority. Obviously you should have both.

# ? Mar 5, 2013 12:34

Zombywuf: Mar 29, 2008

420 rehash every day

By which I mean literally rehash each password each day and check user's passes with something like:

code:

for (i = 0; i < massive_number; ++i) {
   user_pass = hash(user_pass);
   if (user_pass == password_hash) {
        return true;
   }
}
return false;

Can't remember what this scheme is called though. It's pretty future proof though when you run the initial hash on a timed (rather than counted) loop, say 1s of rehashing.

# ? Mar 5, 2013 13:23

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Jabor posted:

Basically it means that instead of having to try and break hashes one-by-one, you can hash "derpabc123", and check that hash against the entire list to see if anyone at all has abc123 as their password.

Thanks, I understand now. That's a clever attack.

# ? Mar 5, 2013 13:40

Doctor w-rw-rw-: Jun 24, 2008

Zombywuf posted:

420 rehash every day

By which I mean literally rehash each password each day and check user's passes with something like:
code:
for (i = 0; i < massive_number; ++i) {
   user_pass = hash(user_pass);
   if (user_pass == password_hash) {
        return true;
   }
}
return false;
Can't remember what this scheme is called though. It's pretty future proof though when you run the initial hash on a timed (rather than counted) loop, say 1s of rehashing.

Is this supposed to guard against timing attacks?

# ? Mar 5, 2013 13:48

Zombywuf: Mar 29, 2008

Doctor w-rw-rw- posted:

Is this supposed to guard against timing attacks?

No it's supposed to guard against some kid with GPU breaking all your hashes.

# ? Mar 5, 2013 13:58

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Zombywuf posted:

check user's passes with something like:

Can't remember what this scheme is called though. It's pretty future proof though when you run the initial hash on a timed (rather than counted) loop, say 1s of rehashing.

That's basically implementing your own bcrypt. Except worse.

Funking Giblet posted:

Doesn't matter how slow it is if you have numerous duplicate hashes, and used the most likely passwords against those duplicates hashes. Also, COMPUTERS WILL SPEED UP BY ORDERS OF MAGNITUDE!

I wasn't saying 'salts aren't important', I was saying that bcrypt/similar are slow. Yes, computers will speed up, but the hashes won't be vulnerable "soon" unless you have a workfactor that's way too low.

# ? Mar 5, 2013 14:05

Sereri: Sep 30, 2008; awwwrigami

Zombywuf posted:

No it's supposed to guard against some kid with GPU breaking all your hashes.

So basically hash the old hash every day and just hash the entered password until it fits?

Because that would increase the chance of guessing the password by chance, wouldn't it? I mean it takes longer and it's not controllable but if you get lucky (and its like 20 years later) you're in.

# ? Mar 5, 2013 14:07

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Aleksei Vasiliev posted:

That's basically implementing your own bcrypt. Except worse.
I wasn't saying 'salts aren't important', I was saying that bcrypt/similar are slow. Yes, computers will speed up, but the hashes won't be vulnerable "soon" unless you have a workfactor that's way too low.

Chances are at least one person on your website is using "abc123" as their password. Without a per-user salt, it literally doesn't matter how slow your hashes are - if your login server can do them in a reasonable amount of time, so can I, and then it's trivial for me to find which of your users have that as their password.

# ? Mar 5, 2013 14:11

The Gripper: Sep 14, 2004; i am winner

Jabor posted:

Chances are at least one person on your website is using "abc123" as their password. Without a per-user salt, it literally doesn't matter how slow your hashes are - if your login server can do them in a reasonable amount of time, so can I, and then it's trivial for me to find which of your users have that as their password.

To be fair, per-user salt + large work factor are only a barrier to finding an unknown password for a given user, not a barrier to finding which dumb unknown user has a stupid password (like "abc123" or "password").

# ? Mar 5, 2013 14:18

tractor fanatic: Sep 9, 2005; Pillbug

The Gripper posted:

To be fair, per-user salt + large work factor are only a barrier to finding an unknown password for a given user, not a barrier to finding which dumb unknown user has a stupid password (like "abc123" or "password").

What? No, it's the opposite. A per user salt has no effect if you want to find the password for a given user, but it prevents you from just hashing "password" and trying to match it across the database.

# ? Mar 5, 2013 14:21

The Gripper: Sep 14, 2004; i am winner

tractor fanatic posted:

What? No, it's the opposite. A per user salt has no effect if you want to find the password for a given user, but it prevents you from just hashing "password" and trying to match it across the database.

I mean if you have per-user salts and you know someone has the password "password", you only need to generate one hash per user to find that vulnerable user.

# ? Mar 5, 2013 14:24

Funking Giblet: Jun 28, 2004; Jiglightful!

The Gripper posted:

I mean if you have per-user salts and you know someone has the password "password", you only need to generate one hash per user to find that vulnerable user.

Only if you know the salt (which you may do, if it's stored with the password) and how it was applied. (Not all are done through concatenation).

# ? Mar 5, 2013 14:47

The Gripper: Sep 14, 2004; i am winner

Funking Giblet posted:

Only if you know the salt (which you may do, if it's stored with the password) and how it was applied. (Not all are done through concatenation).

That's true, I was thinking of the bcrypt case where your hash is $2a$<workfactor>$<salt><...> and to compare you just crypt("password", existing_hash) == existing_hash.

# ? Mar 5, 2013 14:53

Zombywuf: Mar 29, 2008

Aleksei Vasiliev posted:

That's basically implementing your own bcrypt. Except worse.

Nah, the point is that you leave the number of rounds open-ended, you can set it based on the amount of time between the user typing their password the first time and clicking the "Save Password" button. Makes life really hard for brute forcers as there's no definite "this is the wrong password" result. There is a name for the scheme and I can't remember what it's called.

Sereri posted:

Because that would increase the chance of guessing the password by chance, wouldn't it? I mean it takes longer and it's not controllable but if you get lucky (and its like 20 years later) you're in.

The chances of a collision in the way you describe should be astronomically low, although I guess it's possible there would be some unintended collisions.

# ? Mar 5, 2013 15:01

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

The Gripper posted:

I mean if you have per-user salts and you know someone has the password "password", you only need to generate one hash per user to find that vulnerable user.

Getting it to one hash per user is already a massive win compared to just one hash period.

# ? Mar 5, 2013 15:08

The Gripper: Sep 14, 2004; i am winner

Plorkyeran posted:

Getting it to one hash per user is already a massive win compared to just one hash period.

Definitely, I only mentioned it because that specific case (trying to find a user with the password "abc123" when you know that user exists) isn't one where a per-user salt really shines, an attacker could perform the attack in short order either way.

# ? Mar 5, 2013 15:27

KaneTW: Dec 2, 2011

Even with computing power growing in orders of mag, a one second hash will only become a 1 microsecond hash after 30 years assuming Moore's law holds.

30 years is a reallllly long time.

# ? Mar 5, 2013 15:31

UxP: Aug 27, 2007

Zombywuf posted:

There is a name for the scheme and I can't remember what it's called.

Hash-stretching.

In 98% of cases, it's just as retarded as a homebrew PHP authentication mechanism that ends up being a re-implementation of rot13. It does not guard against future computing speed. It does not guard against GPU attacks. It does not guard against timing attacks. It does not guard against mis-implementation, and it prevents future upgrades with drop-in replacements once the recommended library is deemed insufficient. Congratulations, you just made it 650% harder for an attacker to get your password on a GPU farm, so instead of 3500M/s they can try 550 Million hashes per second because you're using a lovely hashing algorithm to begin with, and your users end up waiting 10 seconds with a spinning beachball waiting for the page to load and spiking your CPU on every login because gently caress user experience and PHP/Ruby/Python isn't designed to handle cryptography well. You just implemented a DOS vulnerability in your application.

Seriously. Just use an existing library in the recommended way. Good libraries (bcrypt/scrypt) already implement a good use of hash-stretching that work with the strengths and weaknesses already present in the algorithm. There's no need to re-implement it on top of itself.

# ? Mar 5, 2013 15:46

Hughlander: May 11, 2005

KaneTW posted:

Even with computing power growing in orders of mag, a one second hash will only become a 1 microsecond hash after 30 years assuming Moore's law holds.

30 years is a reallllly long time.

Which is why it's easier to just use cloud computing with GPGPU on hacked credit cards, then your computing power grows in orders of mag without waiting 30 years.

# ? Mar 5, 2013 16:00

gariig: Dec 31, 2004; Beaten into submission by my fiance; Pillbug

Ars Technica had an article about password hacking. With so many different websites having their user database dumped and being cracked over the years hackers have gotten good at heuristically guessing the problem set of the average users possible password. It's a very interesting read.

# ? Mar 5, 2013 16:19

Strong Sauce: Jul 2, 2003; You know I am not really your father.

I'm... I'm trusting my passwords with.... you guys?

# ? Mar 5, 2013 16:28

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Aleksei Vasiliev posted:

That's basically implementing your own bcrypt. Except worse.

Nah, it's PBKDF2, except worse.

Edit: And seriously just use bcrypt/scrypt. Either will individually salt and slow cook your passwords by default unless you start messing with them. You literally have to go out of your way to do something stupid like use a site-wide hash.

ultramiraculous fucked around with this message at 17:24 on Mar 5, 2013

# ? Mar 5, 2013 17:07

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Strong Sauce posted:

I'm... I'm trusting my passwords with.... you guys?

individual passwords for each site

# ? Mar 5, 2013 17:16

Opinion Haver: Apr 9, 2007

ultramiraculous posted:

Nah, it's PBKDF2, except worse.

It doesn't even give you anything over bcrypt, since bcrypt lets you increase (but not decrease, obviously) the strength of a password just from the hash. It's perfectly stupid.

# ? Mar 5, 2013 17:24

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 13:46

Zombywuf: Mar 29, 2008

UxP posted:

Hash-stretching.

Nope, not that. You're missing the point about it being open ended time-wise. You can use whatever iteration system you want, I would recommend that you do use bcrypt. That bit of code I dumped is not meant to be something you copy and paste into your app. The entire point of the system is to make hashes that depend on human time scales, and get more secure storage by the user simply waiting a few seconds. Obviously you need to use a secure password hash iteration system to do it.

# ? Mar 5, 2013 18:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »