Exactly the same thing happened with GitHub couple of days back. Funny both faced the same issue within days of each other.
Twitter urges users to change passwords after computer 'glitch'
351–360 of 490 posts
Re: Twitter urges users to change passwords after computer 'glitch'
#352Naive question - wouldn't a lot of these issues be much better if passwords were (on top of server side processing) salted and hashed client-side? Then in principle you couldn't do these cross-site attacks where people reuse their passwords.
Re: Twitter urges users to change passwords after computer 'glitch'
#353Earlier 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…
Couldn't you hash it client-side, then hash it again server-side?
How is that any different to only hashing server-side?
Re: Twitter urges users to change passwords after computer 'glitch'
#354Earlier quoted context omitted.
You can store things as follows. Store the salted hashed password with its salt server side. When the user wants to login send them the salt and a random salt. Client side hashes the password + salt then hashes that hash with the random value. What am I missing? Probably something since this is something I rolled my own version of when I was a teenager, but it's not immediately obvious to me.
So let me make sure we're on the same page... -- Server stores hashed-password, hash-salt, and random-salt. Server sends hash-salt, and random-salt to client. Client uses user password and hash-salt to generate hashed-password. Client hashes hashed-password using random-salt. Client sends hashed-hashed-password to server. Server grabs stored hashed-password and hashes used stored random-salt to check for match agains…
No, random-salt is not stored permanently but generated at random by the server every time a client is about to authenticate. Alternatively a timestamp would be just as good.
Re: Twitter urges users to change passwords after computer 'glitch'
#355Earlier quoted context omitted.
In this specific case DEBUGLEVEL should be a constant anyways, and thus assignment should fail, no? Also kind of denoted by being all caps.
Which language would stop/warn you assigning the value of a constant to a variable? Doesn't "var = const" just work in most languages?
It's yoda condition, so const = var would fail.
Re: Twitter urges users to change passwords after computer 'glitch'
#356Earlier quoted context omitted.
And consider “Yoda Notation”[0], which some people find annoying, but I found an easy hurdle to clear: if ( 3 = DEBUGLEVEL ) wouldn’t pass the the parser because you can’t assign to an rvalue. [0] https://en.wikipedia.org/wiki/Yoda_conditions
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…
What about this?
if (env('LOG_LEVEL') = 3) {}
Would throw and everything would be ok. Otherwise, use constants.
Also, lint against assignment in if/while conditions. If you want to assign in those conditions, disable linting for the line and make it explicit.
Re: Twitter urges users to change passwords after computer 'glitch'
#357Re: Twitter urges users to change passwords after computer 'glitch'
#358For the thousandth time, can we be done with passwords and move to physical tokens please?
Re: Twitter urges users to change passwords after computer 'glitch'
#359I don't understand why servers don't just store passwords as a public/private key schema. A private key is algorithmically generated from a password with the public key stored on the server. When logging in the server sends a one-use-only 'challenge' as an encrypted blob to the person logging in. Locally they use the algorithmic private key generated from their password to decrypt the blob and send the response back. And you're logged in.
Seems like a pretty simple system and absolutely nothing that has to be secured is stored server side. Is there some clever reason I'm missing that this system fails?
----
Even better you can also salt the password->key schema based on something like the username, making table based attacks infeasible.
Re: Twitter urges users to change passwords after computer 'glitch'
#360Earlier quoted context omitted.
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.
If the previous breaches are of any indication, it's that users don't give a shit - many major websites have leaked passwords ( https://haveibeenpwned.com/PwnedWebsites ) and they're still alive and kicking; for the ones that have gone down the drain (Yahoo!) it was more because the service itself faded into irrelevance. Based on that I'd say it would be pretty safe to disclose a breach and reset all passwords; if yo…
I suspect by "Losing active users", GP meant losing people who get confused or stuck throughout the password reset phase. Twitter is used by a lot of computer novices.
Twitter did disclose this, through email and on first login. Anyone they'd lose because of the breach is long gone and I also think it's probably next to nobody.