Slack was hacked • Hacker News Board

Re: Slack was hacked

#491

Post by dchest » Sat, Mar 28, 2015, 2:23 PM UTC

danbruc wrote: post #240

antsar wrote: post #231

Earlier quoted context omitted.

Is this true? I would think that static bits are no more dangerous than not having the bits at all.

Here is for example an attack recovering a 384 bit ECDSA key [1] by knowing the five least significant bits of the nonce (obtained by a side channel attack) for 4000 signatures. Now hashes and signatures are obviously very different things but I would not bet on the fact that a bias in the salt does not matter. [1] https://eprint.iacr.org/2013/346.pdf

ECDSA is a completely different beast. I'm not aware of a modern password hashing function that would be broken if it was given a non-uniformly random salt. If such function were to be submitted to PHC (https://password-hashing.net/), I would consider it to be a disqualifying factor.

For password hashing purposes, salt doesn't need to be uniformly random, the only requirement for salt is to be unique and unpredictable to the attacker (see http://crypto.stackexchange.com/questions/6119/hashing-passw...). Most password hashing functions use a cryptographic hash on salt.

This particular function, scrypt, uses one-round PBKDF2-HMAC-SHA256 to mix password and salt:

https://github.com/golang/crypto/blob/master/scrypt/scrypt.g...

PBKDF2 feeds salt, basically, into SHA256:

https://github.com/golang/crypto/blob/master/pbkdf2/pbkdf2.g...

Re: Slack was hacked

#492

Post by ionwake » Sat, Mar 28, 2015, 2:23 PM UTC

mbrubeck wrote: post #374

scythe wrote: post #226

Earlier quoted context omitted.

Why combine hashes? Just use XOR. If bcrypt can protect "not_my_password", it can certainly protect "KKQ{H]zTDWVSJVA", which is the former XOR'd by "%$". XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt; XOR is fast enough to evade any sort of timing attacks, too.

Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. XOR could also result in NULL bytes anywhere in the hash input, which could drastically weaken passwords,. For example, bcrypt ignores any password characters after the first NULL…

>Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte.

Can you be kind enough to explain with a very simple example?

I would appreciate understanding your point - Thank you

Re: Slack was hacked

#493

Post by tomjen3 » Sat, Mar 28, 2015, 2:26 PM UTC

zrail wrote: post #487

tomjen3 wrote: post #322

Earlier quoted context omitted.

The only impossible system I know of would be one that uses client side certificates, but I would be surprised if anybody those in a successful business.

US Government systems typically use client certificates as a component of access control in the form of the Common Access Card[1]. Not that that's a business, or even a success from the point of view of the users, but it's one of the largest deployments of client side certs out there. [1]: http://en.m.wikipedia.org/wiki/Common_Access_Card

Unfortunately the only reason they can do that is that they are the government.

Re: Slack was hacked

#494

Post by ircmaxell » Sat, Mar 28, 2015, 2:47 PM UTC

ntucker wrote: post #473

ircmaxell wrote: post #452

Earlier quoted context omitted.

Well, let's imagine an attack scenario. As an attacker, I get SQL access to your DB (meaning no access to the encryption key). I then download the user names, and the hashes. I then attack the hashes offline. I recover only the weakest few percent (since you're using bcrypt). But since the weakest few are those most likely to be re-used (both by different users and by a single user across sites), they are going to be…

So after a breach, you have our (currently) 2 million hashes, and let's say you recover only the weakest few percent of the passwords, which is 60000 known good passwords. Instead of owning 60000 accounts now, you have 60000 passwords, each of which is going to require on average one million attempts before you guess the correct username. Is this not self-evidently better?

Well, let's look at it realistically: http://arstechnica.com/security/2015/01/yes-123456-is-the-mo...

The #1 password out of 3.3 million was 123456, which was used 20,000 times.

So extrapolating that for your 2 million hashes, we'd expect the top password to appear roughly 12,000 times.

Running those numbers, we'd expect each guess to have a 1/12000 chance of matching. Or more specifically, a 1988000/2000000 of not matching.

With some quick running of those numbers, we'd expect a 50% chance of finding a match after trying just 115 random usernames.

I'm not saying it isn't an interesting approach, I just don't think it's nearly as effective as if you encrypt the hash directly (which has no attack vector unless you can get the key).

Re: Slack was hacked

#495

Post by e12e » Sat, Mar 28, 2015, 2:49 PM UTC

tempestn wrote: post #477

mirashii wrote: post #437

Earlier quoted context omitted.

There isn't a work factor high enough or password complexity high enough that it doesn't justify a reset, in my opinion. People will use bad passwords, and we can't really stop that. Allowing offline attacks against them will never be okay.

I'm definitely not an expert, but my understanding is that a per-user salt, which Slack was using, protects against brute-forcing bad passwords. So assuming a reasonable work factor, it really should be computationally unfeasible to retrieve these passwords. That said, I'll change mine, because why not.

No, using bcrypt and per-user salts, forces an attacker to actually do brute-forcing -- not being able to use rainbow tables, or easily test one password against all users. So if they have 2M users, and you can check ~20 passwords per second (what I can do on my workstation with a bcrypt work-factor of 10, single-threaded), it'd take 2M*11/20 seconds ~ 12 days -- to try "username[0-9]?" (e12e, e12e1, e12e2 ... e12e0) against all accounts. And to try any given password, like "Password2015" against all accounts, it'd take 2M/20 seconds ~ 27 hours per guess.

Note that the actual times here are off by a magnitude or two; first they're single-threaded, secondly I happen to have an AMD r9 290 -- and oclhashcat reports 197 hashes/second -- which cuts the time to ~3 hours per guess).

Re: Slack was hacked

#496

Post by im2w1l » Sat, Mar 28, 2015, 2:55 PM UTC

kijin wrote: post #488

ntucker wrote: post #400

Earlier quoted context omitted.

Yes, but we currently have 2.1 million users, so that's still no small burden. And don't forget that's only after you brute forced the passwords.

So you basically increased the cracker's workload by six orders of magnitude, which is equivalent to increasing bcrypt's work factor by 20. Cool!

If you increase bcrypt's workfactor then legitimate requests take longer.

Re: Slack was hacked

#497

Post by rmrfrmrf » Sat, Mar 28, 2015, 3:58 PM UTC

FiloSottile wrote: post #210

stiff wrote: post #170

Earlier quoted context omitted.

Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...

That sounds like fuzzy scare-mongering to me. 1) You should not invent your own algorithm. That's a given. That's why you use bcrypt/scrypt. 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case). 3) There's nothing wrong with nesting algorithms (just remember to use hex/base64 encodings, not binary). For example Facebook passes passwords through half a dozen algorithms. They call it…

The "concatenation case" completely defeats the purpose of using a pepper and leads me to believe that you're not qualified to be giving this kind of advice.

Re: Slack was hacked

#498

Post by rmrfrmrf » Sat, Mar 28, 2015, 4:00 PM UTC

mbrubeck wrote: post #377

randunel wrote: post #209

Earlier quoted context omitted.

In your website's example, you have bcrypt(password, salt+pepper) Observe the difference between that and the rehash you just posted bcrypt(bcrypt(password, salt), pepper)

> bcrypt(password, salt+pepper) I hope it's obvious that no one should never do this, since the output would contain the "salt+pepper" bits in cleartext alongside the hash, defeating the entire point of the "pepper": https://www.usenix.org/legacy/event/usenix99/provos/provos_h... In fact, this is a perfect illustration of why it's bad to put secret bits into a crypto function in a place that's not designed to take se…

One would think it's obvious, yet this is what the person in the linked article suggests doing :/

Re: Slack was hacked

#499

Post by kybernetikos » Sat, Mar 28, 2015, 4:03 PM UTC

ntucker wrote: post #400

kybernetikos wrote: post #398

Earlier quoted context omitted.

> you won't know what usernames they go with But if you've got a list of all usernames (probably a relatively small number) and access to a running system, isn't it easy to just try each password against each user until you find a match? The common practice of limiting logins from a single username wouldn't help with that either.

Yes, but we currently have 2.1 million users, so that's still no small burden. And don't forget that's only after you brute forced the passwords.

It's not the security of the passwords I'm thinking about, it's whether or not you've really enhanced it much by obfuscating the relationship between password and username. I'm sure you've thought about this more than me, but I'm a bit skeptical, since if you have a lot of users, you probably have had to create systems to make the log in process extremely efficient. If all of your users wanted to log into your system within a 24hr period, could they? Maybe a week? If they could, then an attacker can attempt to log in with each username over the same period of time.

Re: Slack was hacked

#500

Post by nitrogen » Sat, Mar 28, 2015, 4:13 PM UTC

rifung wrote: post #293

MichaelGG wrote: post #171

Earlier quoted context omitted.

No, a simple password like "slack123" should be easy to crack with any usable password storage method.

True, I guess it's possible to crack a password for a single user, especially one with a weak password. I was more thinking that it's unlikely they'll be able to crack the passwords of everyone who was in their database, and given that Slack has so many users it's unlikely for any single person that his/her password will be cracked. Of course, even if they can't steal everyone's passwords, maybe the hackers will try…

GPUs are fast enough to crack a very large percentage of passwords in a short time by brute force, if a simple algorithm was used, even with salt.