Live data from Hacker News

Twitter urges users to change passwords after computer 'glitch'

reuters.com

481–490 of 490 posts

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

#481
post #343

I think asymmetric encryption would solve all problems. The sever only ever stores the users public key and uses challenge-response to prevent replay attacks. This is a bad idea, but if you are required that your uses have passwords, you could use their password to seed an elliptic curve private key to create the user key on the fly.

So you go to a site, you enter your password, but then javascript creates a private key and public key based on the userid and password (which is a unique tuple). The key will always be the same regardless of the password. When you first set your password, it sends the public key to the server, which is then stored. If that key was intercepted, it's not a problem. Then the server challenges by sending a random code,…

> "The key will always be the same regardless of the password." The keypair is different for each userid and password. Everything else is correct.

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

#482

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…

How does Web Auth API and Credentials Management API address the "manage across multiple client devices" issue?

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

#484
post #198

Earlier quoted context omitted.

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

This discussion is only relevant with an attacker that can break tls. A hash that such an attacker couldn't reverse might be slow on old phones so there is a tradeoff.

Also, hashed passwords shouldn't be logged either.

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

#485
post #317

Earlier quoted context omitted.

I don't think "Yoda notation" is good advice. How do you prevent mistakes like the following with Yoda notation? if ( level = DEBUGLEVEL ) When both sides of the equality sign are variables, the assignment will succeed. Following Yoda notation provides a false sense of security in this case. As an experienced programmer I have written if-statements so many times in life that I never ever, even by mistake, type: if (a…

One of the sides is(should be) a CONSTANT. And you can't assign a value to a constant.

Why should one of the sides be a constant? There is plenty of code where both sides are variables.

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

#487

Earlier quoted context omitted.

You prevent a lot of these problems by hashing passwords as soon as possible (i.e., on the client).

Wouldn't that make it easier for someone that has access to hashed passwords in the case of a database leak? They would just have to submit the username and the hashed password (which they now have).

You're right, but the attacker won't get the user's original password that they probably reuse elsewhere.

If it's just your authentication system hashes that are compromised, the damage can be contained.

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

#488
post #449

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.

Sounds like the same kind of thing that happened with APFS encryption passwords recently, too. https://www.mac4n6.com/blog/2018/3/30/omg-seriously-apfs-enc...

Where is it showing a password there? I assume this has been fixed because I can't duplicate it on my machine and the screenshot posted on that article doesn't seem to show any plaintext passwords.

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

#489

Earlier quoted context omitted.

We made this mistake - the trick is determining what fields are sensitive, what are sensitive enough that they should be censored but included in the log, and the rest of the crud. It turns out that this is non-trivial - when censoring how do you indicate that something was changed, while keeping the output to a minimum? blank/"null" was rejected because it would mask other problems, and " * THIS FIELD HAS BEEN REDAC…

You prevent a lot of these problems by hashing passwords as soon as possible (i.e., on the client).

In this case client side will have our algorithm (i.e in JavaScript) + private key which we will use to hash the password. If this is the case I could not see any different between giving hacker password or hash-password with algorithm and key.

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

#490
post #447

Earlier quoted context omitted.

KeePass and Dropbox works great for me as a free alternative. I use the Kee plugin on Firefox and KeePass2Android on my phone. I set it up to need both a private key and password to unlock my password DB. The private key moves around on a thumbdrive only (never in Dropbox). I like that the only parts of this system I have to trust are open source.

How do you manage the private key on your phone?

I plug my phone into my computer and transfer it over USB. This is actually one of the primary reasons I switched from iPhone to Android.
Post reply on HN