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

271–280 of 526 posts

Re: Slack was hacked

#271

Post by richardlblair »

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 problem is that pacofvf's answer assumes you don't need to do this retroactively.

This would work if you were building a new system today, but if you had a DB full of one way hashes you're not going to be able to retroactively modify the pepper.

Re: Slack was hacked

#272

Post by kolev »

raphael_l wrote: post #242
kolev wrote: post #207

Earlier quoted context omitted.

I'm not talking about users who care about custom Emojis and animated gifs. That's why I said - let the mere mortals use it; we can do better!

Is this actually the sort of people that get attracted to HN? Thinking of others as "mere mortals" and yourselves as gods? Sad picture.

I was joking. Sometimes emojis help as we're missing a whole communication channel in here (body language).

Re: Slack was hacked

#273

Post by [deleted] »

randunel wrote: post #209
FiloSottile wrote: post #197

Earlier quoted context omitted.

In incident response you assume the worst, but in system design you try to minimize impact of common attacks like SQL injection. There's nothing wrong with nesting algorithms (see the Facebook hash onion), so you can use the following scheme: bcrypt(bcrypt(password, salt), pepper) And do a pass on all your database entries like bcrypt(old_hash, pepper)

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)

[deleted]

Re: Slack was hacked

#274

Post by makeitsuckless »

scrollaway wrote: post #217
santosha wrote: post #164

Earlier quoted context omitted.

Major privacy issues, single point of failure etc etc. We leave payments to third party services because nobody wants to deal with the compliance nightmare that PCI-DSS is, not for security reasons. Payment is also mostly less sensitive to availability and latency issues than authentication.

So in a world where PCI-DSS isn't a thing, you're fine entering your credit card data directly on the forms available on random websites? Why's a password so different, seeing as most people reuse those passwords? Why do we essentially allow (and yes, I am excluding those that use password managers in this statement, I'm one of those) access to our webmail and other critical services to random websites on the interne…

Yes, I have no problem entering my credit card data directly on the forms available on random websites.

Credit card payments online are so ludicrously insecure that it baffles me it's even legal. I only use them when dealing with the US (although some of the major retailers like Apple have finally started accepting 21st century payment methods), and I simply assume my credit card info has been leaking all over the place for ages.

The whole basic premise of credit cards is "we know it's totally broken, we'll just refund you the money because it's cheaper than fixing the problem".

Re: Slack was hacked

#276

Post by richardlblair »

richardlblair wrote: post #271
JimmaDaRustla wrote: post #230

Earlier quoted context omitted.

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

The problem is that pacofvf's answer assumes you don't need to do this retroactively. This would work if you were building a new system today, but if you had a DB full of one way hashes you're not going to be able to retroactively modify the pepper.

And more importantly, slack straight up stated they salt the password and use bcrypt. It's all one way hashes, no encrypting/decrypting going on.

Re: Slack was hacked

#277

Post by tedunangst »

StavrosK wrote: post #249
tedunangst wrote: post #237

Earlier quoted context omitted.

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.

How is it "obvious" when the unit is rounds? Ten was an example, round to 16 if you like. The point is still the same, using few rounds is a risk.

Because the set of values that make sense as linear round counts doesn't overlap with the set that makes sense as log base two work factors. Every implementation takes the log number; it's the only number people ever discuss.

Re: Slack was hacked

#278

Post by nevir »

coldcode wrote: post #228
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.

With a separate salt for each password not even the NSA can crack that (that we know of). With a single salt for all of them, maybe.

Sure they can. Anyone can. It just takes a long time per password to crack (that time is a function of the cost/# of rounds of the hashing function).

Re: Slack was hacked

#279

Post by rudolf0 »

specialk wrote: post #264
rudolf0 wrote: post #255

Earlier quoted context omitted.

A properly implemented, simple pepper can only help password security and can't hurt it. Obviously you first must be using a good, slow algorithm (bcrypt, scrypt, or PBKDF2 with high work factor), but a pepper will only help you. (Let's assume the pepper is an AES key which all hashes are encrypted with.) Yes, many times a dedicated attacker who has read access to your database will also have read access to your sour…

Hey thanks for the long response. I totally get the premise of peppering I think my problem is with this sentiment "A properly implemented, simple pepper can only help password security and can't hurt it". From all the advice I've read security and crypto they don't work like that. The assumption is the other way around. A properly implemented, simple pepper can only hurt password security until proven otherwise by r…

I would argue that while crypto most certainly works that way (use only when definitively proven), security in general is a bit more lax in terms of requirements.

Despite hashes being cryptographic primitives, user password hashing is less about cryptographic principles (preventing first and second preimage attacks) and more about increasing the amount of work an attacker must muster to find an input which hashes to the hash value.

Attributes like collision resistance generally mean almost nothing when on the scale of strings under 100 characters in length, which most user passwords are. Practically, you are never going to run into collision issues if you're using MD5 or later. Your goal is merely to increase the amount of CPU time it takes to find a hash's original input.

Because of this, even if AES encrypting a hash with a random pepper somehow reduced the collision resistance of a hash (I'm 99.8% sure it doesn't), it wouldn't at all affect the speed at which the hash is cracked.

>a sly and subtle vulnerability that simehow leaks information about original plain text by interrogating the cipher text.

Hashes are not ciphertext. For all intents and purposes they can be viewed as CSPRNG output. There is nothing you could do to them to leak info about the plaintext as long as your hash algorithm isn't pathological. There are things you could do to reduce collision resistance, but I addressed that above.

Password protection in web apps is not about encryption or decryption.

Re: Slack was hacked

#280

Post by bentcorner »

Sami_Lehtinen wrote: post #260
FiloSottile wrote: post #130

I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database. https://blog.filippo.io/salt-and-pepper/ tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce. It's simpl…

I still wonder what value does password leak have. I changed my password, my old password was: DV1wn3yHk6W-8m9lZNo_ now you all know it, so what? I don't care, I believe you don't care either. On the other hand, if they were after valuable data, they had access to database and the got what they wanted. So the password is much less valuable than the other stuff they might have wanted. Like chat logs which might contai…

Right, but many people use the same password for their email account as they do for many other services.
Post reply on HN