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

21–30 of 36 posts

Re: New information about Slack’s 2015 security incident

#21

Post by txcwpalpha »

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

The problem with client-side hashing is that the client-hashed password then becomes the password. An attacker doesn't care if the password being sent to the server is "password123" or if it's "e2389cbb675c3ef00879482bd1702f76", because either way, all the attacker needs to do to log in as you is send that "e2389cbb..." string to the server.

I suppose double hashing would have the benefit of preventing your server from ever seeing the plaintext password, but I'm don't think I've ever seen that be a major concern.

Re: New information about Slack’s 2015 security incident

#22

Post by txcwpalpha »

colejohnson66 wrote: post #19
swsieber wrote: post #9

Earlier quoted context omitted.

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?

A salt being public is usually fine. AFAIK most modern suggested hashing libraries use a random salt and store the salt in plaintext next to the hashed password anyway. A properly salted-and-hashed password is still practically uncrackable even if the attacker knows the exact salt used.

Re: New information about Slack’s 2015 security incident

#23

Post by [deleted] »

maxtaco wrote: post #15
ubercow13 wrote: post #13

Earlier quoted context omitted.

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.

[deleted]

Re: New information about Slack’s 2015 security incident

#24

Post by voiper1 »

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...

tl;dr: UEFI rootkits can survive operating system reinstallation and even a hard disk replacement.

That's why he needed a new physical computer.

Re: New information about Slack’s 2015 security incident

#25

Post by flatiron »

txcwpalpha wrote: post #22
colejohnson66 wrote: post #19

Earlier quoted context omitted.

Is letting the client know the salt a problem?

A salt being public is usually fine. AFAIK most modern suggested hashing libraries use a random salt and store the salt in plaintext next to the hashed password anyway. A properly salted-and-hashed password is still practically uncrackable even if the attacker knows the exact salt used.

i've always stored the salt plain text, how else do you store a salt? i need to be able to use it with 0 information about the user other than "they are trying to use this password"

Re: New information about Slack’s 2015 security incident

#26

Post by txcwpalpha »

flatiron wrote: post #25
txcwpalpha wrote: post #22

Earlier quoted context omitted.

A salt being public is usually fine. AFAIK most modern suggested hashing libraries use a random salt and store the salt in plaintext next to the hashed password anyway. A properly salted-and-hashed password is still practically uncrackable even if the attacker knows the exact salt used.

i've always stored the salt plain text, how else do you store a salt? i need to be able to use it with 0 information about the user other than "they are trying to use this password"

I've seen lots of people under the false impression that salts need to be kept secret, and jump through some hoops to do stuff like encrypt salts before storing them. Well intentioned, but misinformed and error prone, and likely indicates that they're not using standard login/password hash libraries and might be doing other things wrong, too.

Re: New information about Slack’s 2015 security incident

#27

Post by segmondy »

DINKDINK wrote: post #14

>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 prayin…

Don't forget that Slack is a php shop. Once a system is compromised, it's easy to edit the code.

Re: New information about Slack’s 2015 security incident

#28

Post by tlb »

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

A hash function isn't feasible to reverse, even knowing the algorithm.

https://en.wikipedia.org/wiki/Cryptographic_hash_function

Re: New information about Slack’s 2015 security incident

#29

Post by swsieber »

colejohnson66 wrote: post #19
swsieber wrote: post #9

Earlier quoted context omitted.

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?

Hmmm... I don't think so? I honestly never considered that possibility. My only concern would be accidentally leaking whether a login username/email is valid depending on your strategy for returning salt for invalid usernames. That should be able to be worked around though.
Post reply on HN