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

231–240 of 526 posts

Re: Slack was hacked

#231

Post by antsar »

danbruc wrote: post #222
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…

Your second point might be dangerous - your salt values are no longer random but heavily biased and knowing that all salt values share some common bits might provide a new attack vector.

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

Re: Slack was hacked

#232

Post by rnovak »

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…

Correct me if I'm wrong, but an algorithm is a set of steps, which this looks like to me

    salt = urandom(16)  
    pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q"  
      # or,        getenv('PEPPER')  
    hashed_password = scrypt(password, salt + pepper)  
    store(hashed_password, salt)
That is an algorithm, which composes bcrypt with pepper.

The idea of not using key-rotation alone is insane, but lets just focus on your last point

    Also, I'm confused at how the proposed alternative would be harder to get wrong
Really? AES literally has hardware support, and can be done in a single call, and has been studied for years. How can that reasonably be considered "harder" to get wrong than something proposed by some random guy on the interwebs?

Outside of Peer-Review, what reason would anyone have to use the pepper scheme? As others have posted, there are several community members who's opinions do matter due to extensive research and body of work

Re: Slack was hacked

#233

Post by xrstf »

jxcl wrote: post #203
xrstf wrote: post #158

Earlier quoted context omitted.

If I set bcrypt cost to 11, hashing takes 0.1 seconds . At 12, it takes 1 second roughly. Setting it to anything higher leaves my service open to Denial-of-Service attacks, so I'm very hesitant to increase the cost factor. To you have a credible source for the "10..12 is too low for 2015" claim? HHVM 3.6 on a small Ubuntu server

You have either a very slow server or a very bad bcrypt implementation. Running bcrypt in python on my 5 year old server has these results: >>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(11))", setup="import bcrypt", number=5) / 5 0.13497538566589357 >>> timeit.timeit("bcrypt.hashpw('this is a password', bcrypt.gensalt(12))", setup="import bcrypt", number=5) / 5 0.28287739753723146 >>> timeit.t…

You are right, my times are apparently somewhat dated. HHVM 3.6 actually gives me 1.88 seconds with costs of 15.

Good thing you made me re-measure :) That makes 13 my new bcrypt default.

Re: Slack was hacked

#234

Post by aturek »

baby wrote: post #186
stiff wrote: post #170

Earlier quoted context omitted.

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

so the downsides are "it's not maintanable" and "don't roll your own crypto". I think they are negligible compared to the upsides.

You consider "not maintainable" to be an acceptable downside to _anything_ you're doing with your software? What?

Re: Slack was hacked

#235

Post by typedweb »

JimmaDaRustla wrote: post #230
pacofvf wrote: post #218

Earlier quoted context omitted.

passwordHash = bcrypt(salt + password) encryptedHash = encrypt(passwordHash, pepper) This way you can rotate your pepper by doing: decryptedHash = decrypt(encryptedHash , oldpepper) encryptedHash = encrypt(decryptedHash , newpepper)

Excuse my ignorance, but you probably shouldn't be able to reverse an irreversible hash.

It's reversing the encryption, not the hash.

Re: Slack was hacked

#236

Post by spullara »

JimmaDaRustla wrote: post #230
pacofvf wrote: post #218

Earlier quoted context omitted.

passwordHash = bcrypt(salt + password) encryptedHash = encrypt(passwordHash, pepper) This way you can rotate your pepper by doing: decryptedHash = decrypt(encryptedHash , oldpepper) encryptedHash = encrypt(decryptedHash , newpepper)

Excuse my ignorance, but you probably shouldn't be able to reverse an irreversible hash.

The pepper is being used as an encryption key in that example rather than using hashing.

Re: Slack was hacked

#237

Post by tedunangst »

StavrosK wrote: post #213
tedunangst wrote: post #183

Earlier quoted context omitted.

10 rounds of bcrypt is "dire"?

Yes? 16 rounds take 1ms on my (old) machine. In Python, no less.

10 is obviously the log rounds number. It's not even a power of two! Nor has any implementation of bcrypt even supported such a low number.

Re: Slack was hacked

#238

Post by mastermojo »

curiously wrote: post #92

is there anything that slack does you can't do with skype? I find lot of these new startups are just creative ways of reinventing the wheel and convincing you need it to appear cool & hip....kind of like fashion for high schoolers

skype doesn't have admin/team lead functions that companies typically might want. my skype mobile app crashes all the time. also inline gifs are cool.

Re: Slack was hacked

#240

Post by danbruc »

antsar wrote: post #231
danbruc wrote: post #222

Earlier quoted context omitted.

Your second point might be dangerous - your salt values are no longer random but heavily biased and knowing that all salt values share some common bits might provide a new attack vector.

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

Post reply on HN