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

271–280 of 490 posts

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

#271

Post by John_KZ »

yorwba wrote: post #261
John_KZ wrote: post #213

Earlier quoted context omitted.

That's not true if you ask the client to hash both the password and a one-time token you just send. Knowing both the password/key (which was send during registration) and the token, you can calculate the hash. Otherwise you can't. Password/key is never transmitted. You can also use asymmetric encryption. I always cringe with amateur devs sending plaintext.

Your scheme requires the server to store the password in plaintext, and it's transmitted at least during registration.

It does. You can do the same with with the salted hash of the password and not the password the user entered. It's still worse than real authentication protocols where you don't store the shared secret at all, but better than those diy schemes described earlier.

Also you can't get away from sending the shared secret during registration. Even with asymmetric cryptography you have to rely on the TLS to make sure you exchange the real untampered public keys.

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

#272

Post by peteretep »

chrischen wrote: post #130
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…

Everyone should be using a password manager. You can't really trust the average joe to be able to make secure passwords for the potentially dozens or hundreds of sites and services, and even if they do, they probably use just one secure password for everything. I just wish there was more seamless support for apps to use 1Password to paste in passwords. There are still sites that prevent pasting into password fields!

I have this fantasy that Apple starts rejecting App submissions that don't allow use of a password manager.

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

#273

Post by aylons »

A honest question from a hardware guy:

Why isn't the password hashed and salted client-side, with the salt being sent from server to client?

I understand that hashing in the client side would only substitute the user password for a new one. This alone sounds like a win to me, as it at least contains the damage somewhat in case of leakage, specially if salted.

EDIT:Sorry, I just found the exact same discussion in this thread.

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

#274

Post by krapp »

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…

Ok.

Creating a User object that holds a password (much less a password in plaintext) seems next level stupid to begin with, but fair enough, I guess it could happen.

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

#275

Post by san_at_weblegit »

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?

Assuming that you are referring to browsers as client here. One simple reason is that the client side data can always be manipulated so it does not really makes any difference. It might just give a false sense of safety but does not changes much.

In case we are talking about multi-tier applications where probably LDAP or AD is used to store the credentials then the back end is the one responsible for doing the hashing.

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

#276

Post by sjwright »

pishpash wrote: post #237
zackbloom wrote: post #220

Earlier quoted context omitted.

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.

If by protocol you mean a standard, consistent API that can be used by password managers to update passwords automatically, then I completely agree.

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

#277

Post by gutnor »

ShabbosGoy wrote: post #268
omarforgotpwd wrote: post #257

Earlier quoted context omitted.

Let's say you log requests and the POST body parameters that are sent along with them. Oops, forgot to explicitly blank out and fields known to contain passwords. Now they're saved in cleartext in the logs every time the user logs in.

In the context of production, why would you need to log anything other than X-Forwarded-For/X-Real-IP, timestamp, and the endpoint that was hit?

Remember that the context is a bug.

So sure you don't want to log everything in Prod, but maybe you do in Dev. In that case, a bug would be to push the dev logging configuration to Prod. Oops.

If you have the clear text password at any point in your codebase, then there is no full-proof way to prevent to log it unintentionally as the result of a bug. You just have to be extra-careful ( code review, minimal amount code manipulating it, prod-like testing environment with log scanner, ...)

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

#278

Post by maddyboo »

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.

Perhaps implement some type of “password canary” - some type of test account(s) with known high-entropy passwords.

Have an automated system send periodic login requests (or any other requests which contain sensitive information that shouldn’t be logged) for this account, and have another system which searches log files for the password.

If it’s ever found, you know something is leaking.

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

#279

Post by ghazak »

Rjevski wrote: post #148

It would be nice if they forced a password reset for all affected users and submitted the old passwords to the Pwned Passwords list. I have trouble believing no passwords have been misused by insiders - sure, there wasn't any large-scale misuse but I am sure someone poaching a few passwords here and there for later mischief (once everything has settled down) would have gone unnoticed.

Agreed. I am assuming they will not do it for the same reason yahoo didn’t. They are simply afraid of losing too many active users.

Yahoo’s case was worse though, since it was hacked.

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

#280

Post by deepbreath »

pbhjpbhj wrote: post #263
cerebellum42 wrote: post #252

Earlier quoted context omitted.

Ultimately, what the client sends to the server to get a successful authentication _is_ effectively the password (whether that's reflected in the UI or not). So if you hash the password on the client side but not on the server, it's almost as bad as saving clear text passwords on the server. You could hash it twice (once on the server once on the client) I suppose, but I'm not entirely sure what the benefit of that w…

A benefit would be that under the sort of circumstance in the OP, assuming sites salted the input passwords, the hashes would need reversing in order to acquire the password and so reuse issues could be obviated. But I don't think that's really worth it when password managers are around. I'm imagining we have a system where a client signs, and timestamps, a hash that's sent meaning old hashes wouldn't be accepted and…

> meaning old hashes wouldn't be accepted and reducing hash "replay" possibilities

How would the server even verify the hash, then?

Post reply on HN