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

New information about Slack’s 2015 security incident

slackhq.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: New information about Slack’s 2015 security incident

#11

Post by cryptozeus »

cremp wrote: post #6

> inserted code that allowed them to capture plaintext passwords as they were entered by users at the time Huh? I get if you 'lose' a database backup, but hashing on the server side has always been the wrong way to do things. If you hash it in JS before the request is sent, there is no possible way for you, or any attacker to get the raw user password; only if they literally change production code to send a new reque…

Anyone can get your JS hash function and reverse it. This has to be on server side

Re: New information about Slack’s 2015 security incident

#12

Post by rys »

nvr219 wrote: post #3
oceliker wrote: post #2

The blog post doesn't make it clear: In 2015, did Slack let the users know that the plaintext passwords were captured as well?

No

And tried to claim in the emails to those affected that it might be the result of malware on their system, performing exfil from a password manager, because they didn't know the real reason.

I spent a couple of days doing nothing but trying to prove to myself that wasn't the case on my machine, and have low-key (and sometimes really seriously) worried about it ever since.

Re: New information about Slack’s 2015 security incident

#13

Post by ubercow13 »

maxtaco wrote: post #4

Keybase CEO here. Let me tell a quick story. January 2019. I was loading the car to leave for a short family ski vacation when I got a truly horrifying email: that my slack account had been accessed from a distant land (that I hadn't been to). There goes my weekend! When we first started Keybase, we used Slack as other teams did, but were gradually moving all Slack-based workflows over to Keybase. As such, we didn't…

I think if this happened to me I would just assume the company was hacked due to poor security practices. It seems much more likely than my password being stolen from a device of mine considering that a very significant percentage of companies I have account with seem to have had breaches at some point. But maybe I am just naive.

Re: New information about Slack’s 2015 security incident

#14

Post by DINKDINK »

>The attackers also inserted code that allowed them to capture plaintext passwords as they were entered by users at the time. >Today we are resetting passwords for all accounts that were active at the time of the 2015 incident

Ok so Slack's security is still dependent on the (unrealistic) hope that their authentication-receiving process isn't manipulable and nothing has changed. I.e. "we are very sorry, we are praying this doesn't happen again"

It would be better if their authentication-receiving process wasn't dependent on being not manipulable through a "Password-authenticated key agreement" PAKE: https://en.wikipedia.org/wiki/Password-authenticated_key_agr...

>irreversibly encrypted, or “hashed,” passwords

Please, don't describe hashes inaccurately as enciphering information. "Scrambled" is marketable enough.

Re: New information about Slack’s 2015 security incident

#15

Post by maxtaco »

ubercow13 wrote: post #13
maxtaco wrote: post #4

Keybase CEO here. Let me tell a quick story. January 2019. I was loading the car to leave for a short family ski vacation when I got a truly horrifying email: that my slack account had been accessed from a distant land (that I hadn't been to). There goes my weekend! When we first started Keybase, we used Slack as other teams did, but were gradually moving all Slack-based workflows over to Keybase. As such, we didn't…

I think if this happened to me I would just assume the company was hacked due to poor security practices. It seems much more likely than my password being stolen from a device of mine considering that a very significant percentage of companies I have account with seem to have had breaches at some point. But maybe I am just naive.

That was my 90%+ likelihood explanation too, but I figured Slack had its act together, and the risk of being wrong was too high.

Re: New information about Slack’s 2015 security incident

#16

Post by frivolous »

maxtaco wrote: post #7
jhiesey wrote: post #5

Earlier quoted context omitted.

Why throw away your computers? Why not remove/disconnect the batteries (if portable) and just store them somewhere in case you eventually no longer suspect a hardware hack, as in this case?

https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-r...

Sorry, but you're just being wasteful. You were looking for an excuse and you know it.

Re: New information about Slack’s 2015 security incident

#17

Post by txcwpalpha »

cryptozeus wrote: post #11
cremp wrote: post #6

> inserted code that allowed them to capture plaintext passwords as they were entered by users at the time Huh? I get if you 'lose' a database backup, but hashing on the server side has always been the wrong way to do things. If you hash it in JS before the request is sent, there is no possible way for you, or any attacker to get the raw user password; only if they literally change production code to send a new reque…

Anyone can get your JS hash function and reverse it. This has to be on server side

An attacker knowing what hash function you used does not reduce your hash security in any material way. The most secure thing you can do is to use just regular out-of-the-box Argon2 or scrypt hashing. And even if an attacker knows the exact code of the Argon2 function you used to hash, they are no closer to cracking it. In fact, customizing it in any way is almost certain to reduce your security.

Hashing password client-side is a terrible idea (not only is it a terrible idea but it's pretty much useless in terms of security), but it's not because of someone being able to "get" your hash function.

Re: New information about Slack’s 2015 security incident

#18

Post by colejohnson66 »

donaltroddyn wrote: post #10
cremp wrote: post #6

> inserted code that allowed them to capture plaintext passwords as they were entered by users at the time Huh? I get if you 'lose' a database backup, but hashing on the server side has always been the wrong way to do things. If you hash it in JS before the request is sent, there is no possible way for you, or any attacker to get the raw user password; only if they literally change production code to send a new reque…

Client-side hashing of passwords does not provide any of the benefits of server-side password hashing, as the client-side hash of the password effectively becomes the password, as it's all that's required to authenticate. Client-side hashing does provide very limited protection against plaintext reuse (on other sites where the user uses the same password) in the case that it's leaked in transit, which is far less of…

What about double hashing? Once on the client and once more on the server? Then, the server never sees the password, but prevents using a leaked password hash from the DB

Re: New information about Slack’s 2015 security incident

#19

Post by colejohnson66 »

swsieber wrote: post #9
cremp wrote: post #6

> inserted code that allowed them to capture plaintext passwords as they were entered by users at the time Huh? I get if you 'lose' a database backup, but hashing on the server side has always been the wrong way to do things. If you hash it in JS before the request is sent, there is no possible way for you, or any attacker to get the raw user password; only if they literally change production code to send a new reque…

The point of hashing it server side is that even identical passwords get different hashes in the database. You can't do that just by hashing the password in the js.

Is letting the client know the salt a problem?

Re: New information about Slack’s 2015 security incident

#20

Post by concert-gilled »

colejohnson66 wrote: post #18
donaltroddyn wrote: post #10

Earlier quoted context omitted.

Client-side hashing of passwords does not provide any of the benefits of server-side password hashing, as the client-side hash of the password effectively becomes the password, as it's all that's required to authenticate. Client-side hashing does provide very limited protection against plaintext reuse (on other sites where the user uses the same password) in the case that it's leaked in transit, which is far less of…

What about double hashing? Once on the client and once more on the server? Then, the server never sees the password, but prevents using a leaked password hash from the DB

I don't think that solves the problem. Instead of logging the plaintext passwords they would have just logged the 1-hashed password.
Post reply on HN