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

231–240 of 490 posts

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

#231

Post by eric_h »

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.

+1 from me as well. Great for storing literally anything sensitive, syncs flawlessly across devices (I currently use dropbox to sync the vault, but it supports other options & they have their own syncing/account system (that is not required to use 1password)).

It is not open source but the vault format is open.

I've no affiliation, just a satisfied customer.

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

#232

Post by hiccuphippo »

theon144 wrote: post #215
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…

But wouldn't you due to random salting at least mitigate the disclosure of the password which might people use elsewhere? edit: considering someone eavesdrops on the connection, otherwise that's a whole different kind of vulnerability

But then you have to store the password instead of a hash of it because it would change each time thanks to the salt. A much worse situation.

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

#233

Post by TimWolla »

abrichr wrote: post #216
ealhad wrote: post #173

Earlier quoted context omitted.

Time for me to advertise my personal setup again! I use KeePassXC [1] with Syncthing [2] to synchronize my passwords between machines. No third-party! [1] : https://keepassxc.org/ [2] : https://syncthing.net/

What if you’re on someone else’s machine?

Not GP, but KeePass user: I store my KeePass database on a small thumb drive (SanDisk Cruzer Fit), together with a copy of the KeePass executable. If I absolutely need to decrypt my password database on someone else's machine I can take the "secure" software from the USB and hope for the best. The USB also stores a copy of Truecrypt and a large Truecrypt container with backups of my encrypted private keys (PGP, SSH).

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

#234

Post by tada-ssola »

tada-ssola wrote: post #223
theCricketer wrote: post #217

Earlier quoted context omitted.

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.

Ah answered elsewhere, if the client sends the hash and you log the hash then you still have a problem. The user should change passwords.

Although I think this still improves the situation if the password is reused. I.E. I can't use the logged hashed password on other sites.

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

#235

Post by tajen »

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?

If you don’t have control on the client, it’s a bad idea: Your suggestion means the password would be the hash itself, and it wouldn’t be necessary for an attacker to know the password.

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

#236

Post by techdragon »

philip1209 wrote: post #229
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.

Log line -> high entropy check -> false positive uuid check -> alerts

I’m not seeing how it would be a challenge in a uuid based environment, unless there’s a nuanced detail I’m missing.

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

#237

Post by pishpash »

zackbloom wrote: post #220
theCricketer wrote: post #217

Earlier quoted context omitted.

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?

Realize the point of hashing the password is to make sure the thing users send to you is different than the thing you store. You'll still have to hash the hashes again on your end, otherwise anyone who gets accessed to your stored passwords could use them to login.

But at least, with salt, it wouldn't be applicable to other sites, just one. Better to just never reuse a password though. Honestly sites should just standardize on a password changing protocol, that will go a long way towards making passwords actually disposable.

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

#238

Post by wool_gather »

madeofpalk wrote: post #139
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.

So Twitter found out they had a bug that caused them to store passwords in one of their databases in plaintext. Their response is just a generic 'hey maybe you want to store your password'. Compare that to Github who just yesterday went through the exact same problem, except they're requiring users change their password. Their CTO didn't make some 'hey you should THANK US" claim.

Are they? I just signed in on a machine where I had signed out and got no prompt to change it. Is it only certain users?

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

#239

Post by beedogs »

ealhad wrote: post #173
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…

Time for me to advertise my personal setup again! I use KeePassXC [1] with Syncthing [2] to synchronize my passwords between machines. No third-party! [1] : https://keepassxc.org/ [2] : https://syncthing.net/

Same thing here. I ditched the online password managers a few years back for a similar setup and it's been just about as good as lastpass was, with the added benefit of being stored locally.

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

#240

Post by zenhack »

zackbloom wrote: post #220
theCricketer wrote: post #217

Earlier quoted context omitted.

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?

Realize the point of hashing the password is to make sure the thing users send to you is different than the thing you store. You'll still have to hash the hashes again on your end, otherwise anyone who gets accessed to your stored passwords could use them to login.

In particular, the point is to make it so that the thing you store can't actually be used to authenticate -- only to verify. So if you're doing it right, the client can't just send the hash, because that wouldn't actually authenticate them.
Post reply on HN