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

311–320 of 526 posts

Re: Slack was hacked

#311

Post by yellowapple »

mike_hearn wrote: post #176
scrollaway wrote: post #125

Earlier quoted context omitted.

Third party authentication should be the norm. Leaving authentication to providers that absolutely know their shit , just like we leave payments to third party services. Of course, that requires a decent protocol, and Mozilla is doing the world a disservice in not marketing Persona better seeing as it's the right solution....

You mean like how Authy specialised in two-factor authentication, but still managed to have basic string concatenation bugs that rendered their entire 2FA system bypassable?

Huh? This is the first I've heard about this, and searching for "Authy concatenation bug" isn't turning up anything useful.

Re: Slack was hacked

#312

Post by minitech »

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 is really bad for text chat.

- It is closed-source, obfuscated, and untrustworthy overall (https://www.eff.org/secure-messaging-scorecard).

- The supported (Windows and Mac) versions have obnoxious ads, and the Linux version is buggy and 32-bit-only.

- Since it’s P2P-ish (which makes sense for audio and video calls), you can’t send a message to someone who’s offline and expect them to be notified (say, via e-mail, which Slack does). Worse, if you go offline, they won’t get it until you’re both on at the same time!

- Files shared on Skype don’t last. You have to use an external service.

- There is no permanent archive; logs are client-side and easy to lose. (You can get messages that are a few days old from peers, but there’s a limit – I don’t know exactly where.)

Re: Slack was hacked

#315

Post by sbov »

jedberg wrote: post #138
rudolf0 wrote: post #2

It's refreshing to 1) see a breach notification including the actual password hashing algorithm, 2) see they're using a strong one like bcrypt (presumably with a reasonable cost factor). Regardless, this is an example of why cloud communication (and ticketing and database off-loading [see MongoHQ] and...) systems probably won't ever become commonplace in most of the government space and the finance and health sectors…

I think this just goes to show exactly why these systems will become more commonplace. There are only so many security experts to go around. Having all the very best concentrated on a smaller set of services seems like it makes more sense than trying to get a security expert for every service.

I have a friend who works security, previously for the government, and now for Visa. In his opinion: if you haven't been hacked, you just aren't an interesting enough target for the right people.

I don't know how common this line of thought is in security. But if it is common, then if you're a small company, aren't you better off not hosting my stuff at these large companies, because it's putting information you collect with someone who is more likely to be "interesting" to the right people?

Re: Slack was hacked

#316

Post by worklogin »

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 point of hashing passwords is that the true password is not revealable.

The point of salting password hashes is to prevent identical cleartext passwords from being stored as identical hashes in the database. Salts are often stored in the database, as well.

The point of peppering keeps a database dump from being at all useful for recovering passwords. It make sure that a component of the process of cleartext -> DB entry is not even in the database, requiring something from the app as well.

Why does encryption work here? Because you've already done a one way function on the cleartext -> salted hash. At that point, there is still no way to reverse the process all the way to get the cleartext. By using a two-way encryption function for the pepper portion, you keep the ability to rotate 'peppers' periodically, in case it is leaked, for example.

Re: Slack was hacked

#317

Post by dragonwriter »

BrainInAJar wrote: post #305
dragonwriter wrote: post #148

Earlier quoted context omitted.

Because SMS is not even remotely a secure communication channel, and the point of two factors is proof of possession of two different classes of things (that you have some device and that you know some secret), and using an insecure channel to send a message weakens the proof of the have half of that, in much the same way as using a weak or published password weakens the know half. Ideally, you want as strong as prac…

> Because SMS is not even remotely a secure communication channel Neither is 2FA, it's a key stored completely unencrypted in both your phone and the the host's db.

That's not particularly weak as proof to the person who controls the DB that you have access to the phone, which is what the device factor of a 2FA scheme is intended to prove, since you have to have access to either the DB or the phone to get the key.

Conversely, SMS's weakness is in the communication channel, which can be compromised without compromising the things for which the factor is intended as proof.

Re: Slack was hacked

#318

Post by minitech »

FiloSottile wrote: post #197
randunel wrote: post #153

Earlier quoted context omitted.

I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link? Later edit: I'm referring to your example in your link: salt = urandom(16) pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or, getenv('PEPPER') hash…

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)

> There's nothing wrong with nesting algorithms

This is really vague. What kind of algorithm? With itself, or just anything inside anything else? Passing the raw output of any common cryptographic hash (SHA-x) to bcrypt, for example, completely destroys its security, as bcrypt input is null-terminated.

(What happens when you nest DES in A*, anyway?)

Re: Slack was hacked

#319

Post by kordless »

kolev wrote: post #137

Can we go back to IRC now, please! Slack is not only distracting, proprietary, but it is also pretty expensive. Let the mere mortals use it, but we should stay away!

That cow left the barn a while ago.

Re: Slack was hacked

#320

Post by drewwwwww »

yellowapple wrote: post #311
mike_hearn wrote: post #176

Earlier quoted context omitted.

You mean like how Authy specialised in two-factor authentication, but still managed to have basic string concatenation bugs that rendered their entire 2FA system bypassable?

Huh? This is the first I've heard about this, and searching for "Authy concatenation bug" isn't turning up anything useful.

i believe he's referring to this: http://www.scmagazineuk.com/authy-patches-after-2fa-bypassed...
Post reply on HN