Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack was hacked

slackhq.com

Post reply on HN
Print view View original

511–520 of 526 posts

Re: Slack was hacked

#511

Post by danbruc »

dchest wrote: post #491
danbruc wrote: post #240

Earlier quoted context omitted.

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 unpredicta…

If there was a known attack it would obviously be a non-starter. But why take the risk that someone will come up with something comparable - in the broadest sense - to say the differential attack on MD5 that allows exploiting known bits in the salt if there is no need to?

Re: Slack was hacked

#512

Post by girvo »

pepr wrote: post #469
girvo wrote: post #451

Earlier quoted context omitted.

Christ you weren't kidding about it being expensive. Amazons Cloud HSM is $5k upfront and $1.8/h thereafter, which is completely infeasible for the agencies I've worked at. A shame, I'd love to do the right thing there :(

That's why AWS also started offering Key Management Service: https://aws.amazon.com/kms/ You don't get your own HSM but it's MUCH cheaper ($1/key/month) and more scalable and available than an HSM.

That's brilliant. I'm definitely going to use that, thanks for posting it!

Re: Slack was hacked

#513

Post by jjarmoc »

ntucker wrote: post #378
jjarmoc wrote: post #333

Earlier quoted context omitted.

Uhh.. it doesn't? While it does give some specific values as 'a reasonable starting point' the article suggests tuning these to the specific environment. "Each of these algorithms requires setting of an appropriate work factor. This should be tuned to make digest computation as difficult as possible while still performing responsively enough for the application. For concurrent user logins, you may need The stackexcha…

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting a work factor by benchmarking your current hardware, but they leave it there, and one might come to the conclusion that once they've measured their hardware, they put "13" in a config file and call it done. I'm advocating for advice like "Don't think about wor…

Ohh, okay. I see what you're getting at now.

Yah, that does seem like a reasonable design. The implementation wrinkles there are that the hardness params have to be encoded in the digest itself, or otherwise stored alongside it. Since implementations commonly do this anyhow, that doesn't seem likely to pose much problem in practice (if any). The other issues would be details around when to calculate the hardness. On app initialization seems obvious, but you'd have to sample over some period of time to get a representative benchmark. I worry that this could exceed administrator tolerance for how long an app can reasonably take to start up, but this doesn't seem like a show stopper either.

Ultimately though, I'm not sure the factors are THAT variable. I mean, you want to reconsider work factors as hardware advances, but I don't think the line is so solid that running a work factor of N versus N+1 will make that much of a practical difference in the span of a few months or even a few years. Still, with the goal of making it as hard as feasible while still being suitably performant in the context of a given system it makes sense.

Re: Slack was hacked

#514

Post by saurik »

ntucker wrote: post #378
jjarmoc wrote: post #333

Earlier quoted context omitted.

Uhh.. it doesn't? While it does give some specific values as 'a reasonable starting point' the article suggests tuning these to the specific environment. "Each of these algorithms requires setting of an appropriate work factor. This should be tuned to make digest computation as difficult as possible while still performing responsively enough for the application. For concurrent user logins, you may need The stackexcha…

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting a work factor by benchmarking your current hardware, but they leave it there, and one might come to the conclusion that once they've measured their hardware, they put "13" in a config file and call it done. I'm advocating for advice like "Don't think about wor…

This doesnt make any sense: the goal of this work factor is to make things slower for the opponent, not my own servers. My estimation of the computational power available to my opponent has nothing to do with how large the web servers I chose to use happen to be.

Re: Slack was hacked

#515

Post by dchest »

rmrfrmrf wrote: post #497
FiloSottile wrote: post #210

Earlier quoted context omitted.

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.

In what way it defeats the purpose of using a pepper?

Re: Slack was hacked

#516

Post by tracker1 »

homakov wrote: post #447
tracker1 wrote: post #422

Earlier quoted context omitted.

Or, monitoring software on your computer, the origin of which now has access to the computer, your password, and the token generator.

No, if your computer is infected (=monitoring software) there's no difference because token is transaction-agnostic. 2fa won't help

If you have a hardware token, not on the computer.. and use that as part of your VPN, if your computer is compromised, your account won't be able to be used to reconnect to VPN while you are afk without that hardware token... if the software/key are on the machine, they have your password, and the generator for 2fa... they don't even need your machine anymore... that is definitely less secure.

Re: Slack was hacked

#517

Post by Dylan16807 »

minitech wrote: post #505
Dylan16807 wrote: post #472

Earlier quoted context omitted.

Obviously you have to use type safety. You can't cast a binary string to a null-terminated string, you have to convert. That's a problem unrelated to hashing. I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.)

> That's a problem unrelated to hashing. It (poor implementation) is definitely related to implementing pepper on top of a secure password hash, though, which everybody is already doing differently. > I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is…

Oh sorry I missed this post for a while.

>“algorithm” is, again, really vague

Something that you can use to hash passwords. What you gave works if you assume gen_salt is seeded per user.

>The weakest link here is 374 bits (4 bcrypts), but the output is 288.

I'm afraid I don't follow. Your bit numbers confuse me, and I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt.

Re: Slack was hacked

#519

Post by minitech »

Dylan16807 wrote: post #517
minitech wrote: post #505

Earlier quoted context omitted.

> That's a problem unrelated to hashing. It (poor implementation) is definitely related to implementing pepper on top of a secure password hash, though, which everybody is already doing differently. > I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is…

Oh sorry I missed this post for a while. >“algorithm” is, again, really vague Something that you can use to hash passwords. What you gave works if you assume gen_salt is seeded per user. >The weakest link here is 374 bits (4 bcrypts), but the output is 288. I'm afraid I don't follow. Your bit numbers confuse me, and I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt.

> I'm afraid I don't follow. Your bit numbers confuse me

They’re bits of entropy (not counting the password itself) (I think). SHA-512(M): 512 bits; SHA-512(SHA-256(M)): 256 bits, for example.

> I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt.

That’s my point. It’s not easy to get this kind of thing right, so just don’t bother with pepper.

Re: Slack was hacked

#520

Post by Dylan16807 »

minitech wrote: post #519
Dylan16807 wrote: post #517

Earlier quoted context omitted.

Oh sorry I missed this post for a while. >“algorithm” is, again, really vague Something that you can use to hash passwords. What you gave works if you assume gen_salt is seeded per user. >The weakest link here is 374 bits (4 bcrypts), but the output is 288. I'm afraid I don't follow. Your bit numbers confuse me, and I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt.

> I'm afraid I don't follow. Your bit numbers confuse me They’re bits of entropy (not counting the password itself) (I think). SHA-512(M): 512 bits; SHA-512(SHA-256(M)): 256 bits, for example. > I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt. That’s my point. It’s not easy to get this kind of thing right, so just don’t bother with pepper.

Bits of entropy I understand, how you got "374" and "288" I don't.

>That’s my point. It’s not easy to get this kind of thing right, so just don’t bother with pepper.

What? Your point is that you haven't demonstrated that it's weaker than the weakest link, therefore you win?

Edit: Okay I figured out where you got 288. Still confused by the 374. Anyway you need to make truncations explicit. You didn't pass all of the sha output to bcrypt. You're taking advantage of an implementation API bug.

I'm not asking for evidence that shoving together functions from google without understanding them can go wrong. That's trivially true.

I want an example where combining hash algorithms is inherently wrong. Like using a block cypher twice can pop out your plaintext, but probably not as extreme.

Edit 2: Oh, 384!

Post reply on HN