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

191–200 of 490 posts

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

#191

Post by PhasmaFelis »

fpgaminer wrote: post #143

Back in my younger, move naive days when I first started using a password manager and such a practice was not as widespread, I had the same question I think most other people have: "If my computer gets hacked or infected, won't the attacker instantly grab all the passwords from the manager?" I chose to use a manager anyway, with the logic that if my system was compromised I was owned either way; memorizing passwords…

I wonder if it has to do with the changing motivations of malware authors. In the pre-internet and early internet days, it was mostly young folks doing it for shits and giggles, as a power trip. It wasn't targeted; they just wanted it widely distributed to make a big splash, and it often didn't communicate with the creator in any way.

Now, malware is a criminal industry. People are making big money off of it. It doesn't make a lot of sense to target individuals when you could go after big, wealthy institutions. Same goes for government malware--they're looking to infiltrate and disrupt rival institutions and industries, not inconvenience private citizens.

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

#192

Post by geofft »

u801e wrote: post #144
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…

> I highly recommend using a password manager. I really wish websites would support use of client side TLS certificates as part of the authentication process. Combining that with a username and password would give you two-factor authentication.

Client side TLS certificates get sent in the clear before you authenticate the server. (You can send them in a renegotiation, but renegotiation has been a historic source of both implementation and protocol security bugs because it does complicated things to TLS state.) So you don't want a client-side certificate that includes your name; that's a huge privacy leak.

You could imagine a scheme where you give a user a certificate with a random subject, and you have a server-side map of random string to user account (so leaking that map isn't the end of the world like leaking passwords, it merely reintroduces the privacy leak above). I recall some proposals for that several years ago. Today, Web Authentication effectively does something effectively equivalent, as does U2F, although they don't involve TLS client certificates specifically.

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

#193

Post by pound »

jwilliams wrote: post #131
chipperyman573 wrote: post #84

Earlier quoted context omitted.

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

There is very little to be gained or added from pointing out this was optional -- for some reason the CTO decided to make a point of it. I think the tone matters. Particularly for matters like this. To my ear (and many who replied to that Tweet) this reads as "we've decided to do you a favor." Which is very much not the case.

I see it more of "we may have kept it quiet, but we're not making secrets from you - it's indeed our open culture"

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

#194

Post by lifeisstillgood »

fpgaminer wrote: post #143

Back in my younger, move naive days when I first started using a password manager and such a practice was not as widespread, I had the same question I think most other people have: "If my computer gets hacked or infected, won't the attacker instantly grab all the passwords from the manager?" I chose to use a manager anyway, with the logic that if my system was compromised I was owned either way; memorizing passwords…

> The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises.

Why do you rob banks?

Because that's where the money is.

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

#195

Post by ryanmcm »

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?

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

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

#196

Post by Cyph0n »

fpgaminer wrote: post #172
hardly_a_mirage wrote: post #153

Earlier quoted context omitted.

> The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Something to consider is that malware-based compromises of personal systems don't raise as much brouhaha as corporate-level compromises.

My statement is based not on frequency of news, but rather on my understanding of the provenance of passwords in password lists. The vast majority of passwords in password lists are sourced from service hacks; not from user malware. And that makes sense. Malware events net maybe thousands of user passwords? On a good day maybe 100k. But hacks of major services like LinkedIn ... those yielded hundreds of millions of p…

> Malware events net maybe thousands of user passwords? On a good day maybe 100k.

You are underestimating how much malware there is out there, both on desktop and mobile. There are probably botnets that consist of >100k compromised machines.

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

#198

Post by iGoog »

honoredb wrote: post #161
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?

No, there fundamentally isn't, because you can't trust the client to actually be hashing a password. If all the server sees is a hash, the hash effectively is the password. If it's stolen, a hacker can alter their client to send the stolen hash to the server.

If a hash is salted with a domain it won't be use-able on other websites. You should additionally hash the hash on the server, and if you store the client hashes, you can update the salts on next-sign in. A better question is why clients should be sending unhashed passwords to servers in the first place. https://medium.com/the-coming-golden-age/internet-www-securi...

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

#199

Post by stordoff »

chatmasta wrote: post #82
krallja wrote: post #68

Earlier quoted context omitted.

Then anyone with a copy of your DB can log in by sending the hash directly. It’s identical to storing plain text passwords.

You could hash it twice, once at the client and once at the server. So your database would store a hash of a hash. But without persistence on the client side you wouldn’t be able to do salting in the first hash (where do you store the salt?)

Does it buy you anything at that point? A server-side issue, such as this, would still log the thing you need to log in, and a client-side issue would just intercept the hashed form or could derive the hashing mechanism from analysing the client.

At most, it would seem to prevent weak passwords from being passed directly to bcrypt, but salting should solve that in a similar way anyway, and anyone brute-forcing a copy of the database can incorporate the same weak hashing logic

Post reply on HN