Earlier quoted context omitted.
It's also a great reason to use them, isn't it? Your searchable chat history basically becomes the knowledge base of your company.
And a great target for discovery in any sort of lawsuit.
As is email.
Slack was hacked
431–440 of 526 posts
Re: Slack was hacked
#432Why is everyone worried about what hashing algorithm was used and not if their company's private chat logs are about to become public knowledge?
Re: Slack was hacked
#433Earlier quoted context omitted.
By that logic, every extra character you concat onto a salt is also "rolling your own crypto." For example if my salt was CrytoRandom(10), and you increase it to CrytoRandom(15) you've just "rolled your own crypto" according to you. If that is not the case then explain the difference between CryptoRandom(15) and CrytoRandom(10) + CryptoRandom(5) (longer salt Vs. salt+pepper). There's a lot of people spreading FUD ("i…
PBKDFs like bcrypt assume the salt is a random value that is not re-used and is not required to be secret. You are re-using part of it, and require that it is secret. That's the worrying part, and it's one of the reasons that several concrete proposals posted here have actual security flaws.
Maybe. But that only makes sense if you reduce the length of the salt to add the pepper, which nobody is suggesting.
If the salt remains the same length and you add the pepper on top, it won't make the final hash less secure/strong, due to the way hashing algorithms are folded.
At worst case scenario you've literally added no security at all with the pepper. There's no rational scenario where it reduces the security when all other things remain equal (i.e. you aren't replacing the salt with a pepper, or reducing the salt's length/complexity for the pepper, etc).
Re: Slack was hacked
#434If I were Slack, I would pretend to get hacked. Slack critics often point to its centralized architecture as a weak point, because rational corporations should not entrust security of their internal communications to a third party. Particuarly when that third party aggregates communications of its many clients, it becomes a target of hacking. Why hack a single corporation when you can hack Slack and get all their cli…
Note: My comments and thoughts are geared specifically to Slack or a very similar entity (tech start up, which sells a service).
I strongly disagree with this idea:
"Now that Slack has captured the low-hanging-fruit of the market, it needs to pick the high-hanging-fruit. The most profitable clients for slack will be the largest, conservative, enterprise clients who will join the Slack platform and then never leave. The long term survivability prospects of Slack depend on capturing these large enterprise customers."
I think this is a large misconception held by people. Often times, and I say this from experience, enterprise customers will demand a large amount of support/coddling because of the gross amount they're paying.
That "$1 million" a year contract sounds less and less good when you realize it requires constant attention of two, now dedicated, engineers, two support reps, sales person, and on occasion an executive... Compare that to 1,000 individual customers/subscribers who require next to no special attention, or dedicated engineers. Large, conservative, enterprise customers distort profit margins, and should be avoided.
Think about this: some enterprise customers are so large they may hire a person (or persons) to _only_ deal with your product. Now you've got a team of cogs (people) at your enterprise client, working, to take up your time and cost you money.
What's worse is that in most corporate cultures, partners/suppliers/providers are not looked at as "family" but as disposable. There's no vested interest in your success or failure. So there is little to no concern over how your smaller company may be abused by a larger one.
Re: Slack was hacked
#435Earlier quoted context omitted.
> what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable? The question is irrelevant anyway, because if someone gets access to your app server, they get the secret in both cases (pepper and encryption). So the first risk there is present in both cases, which just makes this a static "what's t…
You never know. Some developers might not be smart enough to use an SSL connection from their app server to their DB server. The influx of newb devs out there is growing and security is usually not high on the learning list or the new devs priority list. If so, hackers could possibly get access to the DB without even needing the app server in the first place. Get your certs folks!
I don't see how this is relevant. There is no reason to believe that the hacker needs to get at your app server in order to access your DB server in the first place.
Re: Slack was hacked
#436Why is everyone worried about what hashing algorithm was used and not if their company's private chat logs are about to become public knowledge?
Because obtaining a hash of a password does not mean the attacker can access the accounts and the chat logs.
If the passwords were not hashed or hashed in a weak manner then that means the attacker could figure out the account passwords, then gain access to the accounts, which would be bad.
Re: Slack was hacked
#437Surprisingly, they didn't force a password reset on all accounts. Even though the passwords are hashed and salted, targeting a couple users and checking for weak passwords can now be done offline, with no rate-limiting or network calls necessary. In breaches like these, it should still be mandatory to issue service wide password resets. Anything less is unacceptable.
I was curious about this too. I don't use Slack, do they enforce a password complexity and use a bcrypt work factor high enough to justify not requiring a reset?
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.
Re: Slack was hacked
#438Earlier quoted context omitted.
PBKDFs like bcrypt assume the salt is a random value that is not re-used and is not required to be secret. You are re-using part of it, and require that it is secret. That's the worrying part, and it's one of the reasons that several concrete proposals posted here have actual security flaws.
Maybe. But that only makes sense if you reduce the length of the salt to add the pepper, which nobody is suggesting. If the salt remains the same length and you add the pepper on top, it won't make the final hash less secure/strong, due to the way hashing algorithms are folded. At worst case scenario you've literally added no security at all with the pepper. There's no rational scenario where it reduces the security…
> At worst case scenario you've literally added no security at all with the pepper.
Yes, I think this is the most likely failure mode (though not necessarily the only one - crypto can fail in very suprising ways!).
But even this is harmful, since you are potentially making changes to security-critical code for no benefit. At best you get more complexity and more chances to introduce bugs, plus a false sense of security.
Re: Slack was hacked
#439One thing that bugged me about this today was that after I changed my password on desktop, my mobile session wasn't invalidated. Apparently it's an option for mass password resets, but it really should be mandatory.
Re: Slack was hacked
#440Why is everyone worried about what hashing algorithm was used and not if their company's private chat logs are about to become public knowledge?
Because obtaining a hash of a password does not mean the attacker can access the accounts and the chat logs. If the passwords were not hashed or hashed in a weak manner then that means the attacker could figure out the account passwords, then gain access to the accounts, which would be bad.
I completely understand the risks associated with user passwords and hashing algorithms. But you know what? That shit gets leaked all the time. It's not uncommon and unfortunately, users are accustomed to it by now. It's relatively easy to fix.
You know what's a big deal? Having your company's internal private communications suddenly public or sold to the highest bidder. That's the sort of thing that doesn't have a "reset password" simple fix.