Slack Resets Passwords For 1% of Its Users Because of 2015 Hack (zdnet.com) 20
ZDNet: Slack published more details about a password reset operation that ZDNet reported earlier today. According to a statement the company published on its website, the password reset operation is related to the company's 2015 security breach. In March 2015, Slack said hackers gained access to some Slack infrastructure, including databases storing user credentials. Hackers stole hashed passwords, but they also planted code on the company's site to capture plaintext passwords that users entered when logging in. At the time, Slack reset passwords for users who it believed were impacted, and also added support for two-factor authentication for all accounts. But as ZDNet reported earlier today, the company recently received a batch of Slack users credentials, which prompted the company to start an investigation into its source and prepare a password reset procedure. "We immediately confirmed that a portion of the email addresses and password combinations were valid, reset those passwords, and explained our actions to the affected users," Slack said. In a message on its website, Slack said this batch of credentials came via its bug bounty program. The company said it initially believed the data came from users who had their PCs infected with malware, or users who reused passwords across different services.
Plain text password communications (Score:3)
Any idea why passwords are still sent unhashed to the server in this day and age?
Why not get a nonce and a salt from the server, hash the password and the nonce with the salt, then send the result back to the server. It then applies the nonce to its own hashed value and then it compares the results.
Or something like that, which prevents original password interception.
Re: (Score:2)
Since the login page is going to come from at least the same organisation (and likely the same server), if it's been compromised then that won't help - it just means the attacker has to do marginally more work adding a bit of code to the stuff sent to the browser to harvest the plain text password there instead.
Re: (Score:2)
As long as it's done in the page, I agree.
But if this process takes place in the browser rather than the page, and the page has no access to the original input, I can't see what they could do with the one-time rubbish they receive for authentication.
Say, have a <password> tag, which takes the salt and the nonce, which can be styled and even duplicated for "confirm your password" (with appropriate attributes), but you aren't given access to the field value in the document itself. And the process would
Re: (Score:3)
Hashing the password on the client don't make things more secure.
The hash of the password would then be used as the password, and nothing have changed.
Re: (Score:2)
That's why I mentioned the nonce. It would make the hash usable only once (i.e. no replay attack), and if done the way I thought about it, the server would start from its own stored hash, add the nonce, then compare.
I posted a longer text as a response to somebody else, and found a problem with my idea: how does the server get the initial hash while not revealing the password and also preventing replays?
So back to the drawing board, and learning some more security concepts (it's impossible that nobody thoug
Re: (Score:2)
I'll take a guess and say you're not a security professional, and not even an armchair one at that.
Done in a certain order (say add the "nonce" last) you can get the same result (you just start from a different point on the server).
This prevents replay attacks (the nonce is valid just once) and works much better than plain text or simple hash.