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

Twitter urges users to change passwords after computer 'glitch'

reuters.com

Post reply on HN
Print view View original

221–230 of 490 posts

Re: Twitter urges users to change passwords after computer 'glitch'

#221

Post by mehrdadn »

jrochkind1 wrote: post #156
ams6110 wrote: post #152

Earlier quoted context omitted.

So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?

nah, that just makes the "hashed password" the equivalent of the cleartext password. Whatever it is your client sends to the server for auth is the thing that needs to be protected. If the client sends a "hashed password", that's just... the password. Which now needs to be protected. Since if someone has it, they can just send it to the server for auth. But you can do fancy cryptographic things where the server never…

Not really... it's not that simple. You could use the time of day as a seed for the hash, for example. There are tradeoffs to be made, which is partly why they don't do it, but the story isn't as simple as "the hash becomes the password".

Re: Twitter urges users to change passwords after computer 'glitch'

#222

Post by kevin_thibedeau »

tehbeard wrote: post #202
jrochkind1 wrote: post #177

Earlier quoted context omitted.

There are probably ways to make it reasonable UX, but they probably require built-in browser (or other client) support. Someone in another part of this thread mentioned the "Web Authentication API" for browsers, which I'm not familiar with, but is possibly trying to approach this?

Web Auth API (authn) does try to make it usable. It ties in with the credential management API (A way to have the browser store login credentials for a site, a much less heuristic based approach than autocomplete on forms) and basic principle is generate a key pair, pass back public key to be sent to server during registration. On login generate a challenge value for the client to sign. I don't think iirc the JS code…

Useless unless browsers get their act together and encrypt their autocomplete data. I would never trust any API loosely associated with it.

Re: Twitter urges users to change passwords after computer 'glitch'

#223

Post by tada-ssola »

theCricketer wrote: post #217
fatratchet wrote: post #6

Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/... "Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again." Exact same thing that github did just recently.

For people that know more about web security than I: Is there a reason it isn't good practice to hash the password client side so that the backends only ever see the hashed password and there is no chance for such mistakes?

I think there is value in that. I would still be sure to hash it a second time on the server.

My guess is that this isn't popular because of the added client side complexity.

I'm also curious if anyone has considered or implemented this idea.

Re: Twitter urges users to change passwords after computer 'glitch'

#224

Post by Alex3917 »

krapp wrote: post #170
ams6110 wrote: post #152

Earlier quoted context omitted.

So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?

>That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that? No [0,1...n]. Note that these articles are about encryption, but the arguments against javascript encryption apply to hashing as well. Also consider that no one logs this stuff accidentally to begin with. If the entity controlling the server and writing the code wants to log the passwords, they can rewrit…

> Also consider that no one logs this stuff accidentally to begin with.

It can happen if requests are logged in middleware, and the endpoint developer doesn't know about it. It's still an extremely rookie mistake though, regardless of whether it was done accidentally or on purpose.

Re: Twitter urges users to change passwords after computer 'glitch'

#225

Post by johnsonjo »

adrianmonk wrote: post #189
krapp wrote: post #170

Earlier quoted context omitted.

>That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that? No [0,1...n]. Note that these articles are about encryption, but the arguments against javascript encryption apply to hashing as well. Also consider that no one logs this stuff accidentally to begin with. If the entity controlling the server and writing the code wants to log the passwords, they can rewrit…

> consider that no one logs this stuff accidentally to begin with It's possible. You create an object called Foo (possibly a serialized data like a protobuf, but any object), and you recursively dump the whole thing to the debug log. Then you realize, oh, when I access a Foo, sometimes I need this one field out of the User object (like their first name), so I'll just add a copy of User within Foo. You don't consider…

Any user object on the server should only ever have the password when it is going through the process of setting or checking the password, and this should be coming from the client and not stored. So, your case of logging the user would only be bad at one of those times. Otherwise like in the case of a stored user you should just have a hashed password and a salt in the user object.

Re: Twitter urges users to change passwords after computer 'glitch'

#226

Post by hiccuphippo »

ams6110 wrote: post #152
fatratchet wrote: post #6

Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/... "Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again." Exact same thing that github did just recently.

So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?

Instead of trying to hash the password, just use SSL so the whole request is encrypted. But that doesn't fix servers accidentally logging passwords.

Maybe there could be a standard way to signal the beginning and end of a password string so logging software can redact that part.

Re: Twitter urges users to change passwords after computer 'glitch'

#227

Post by gerald42 »

hakanito wrote: post #120
calebh wrote: post #99

I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords. Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the inf…

+1 for 1Password. Never looked back. Great for all sorts of passwords/credit cards/private keys. It also syncs to the 1Pass app on your phone.

+2 for 1Password. Being able to use it as an MFA device has been brilliant. https://support.1password.com/one-time-passwords/

Re: Twitter urges users to change passwords after computer 'glitch'

#228

Post by stordoff »

chipperyman573 wrote: post #84
jwilliams wrote: post #21

The Tweet from the Twitter CTO on this: https://twitter.com/paraga/status/992135139994943488 "We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do." The "we didn't have to" is a little jarring given the scale of this.

>The "we didn't have to" is a little jarring given the scale of this. How come? I interpreted it to mean that no regulations required this, but they chose to anyway. Which is true.

I think it's part of the problem of writing a statement to be read by a large number of people - it could be read as "There is nothing legally forcing us to do this, but we are doing us anyway as it is in the best interests of our users" (which is positive) OR it could be read as "We didn't have to do this; we did you a favour, but there might be situations where we don't disclose this" (which is fairly negative). FWIW, I think the former is the intent.

Personally, I'd probably just say "We felt that we had to disclose this to protect the interests of our users" (and not acknowledge that they might not, or that they had to make a decision to do so), or just say what they _are_ doing ("We are disclosing this in order to protect our users") and avoid the possibility that it is misinterpreted. I don't think there is anything to be gained by saying that they might not have done this.

Re: Twitter urges users to change passwords after computer 'glitch'

#229

Post by philip1209 »

fatratchet wrote: post #6

Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/... "Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again." Exact same thing that github did just recently.

In the past, I've seen logs monitored for high-entropy strings that could be API keys or passwords. However, in a NoSQL/UUID-using environment, this could be really hard to implement.

Re: Twitter urges users to change passwords after computer 'glitch'

#230

Post by euyyn »

mehrdadn wrote: post #221
jrochkind1 wrote: post #156

Earlier quoted context omitted.

nah, that just makes the "hashed password" the equivalent of the cleartext password. Whatever it is your client sends to the server for auth is the thing that needs to be protected. If the client sends a "hashed password", that's just... the password. Which now needs to be protected. Since if someone has it, they can just send it to the server for auth. But you can do fancy cryptographic things where the server never…

Not really... it's not that simple. You could use the time of day as a seed for the hash, for example. There are tradeoffs to be made, which is partly why they don't do it, but the story isn't as simple as "the hash becomes the password".

Then how does the server check that it's valid?
Post reply on HN