I have two-factor authentication with Twitter and wherever else I can using authy. Isn't that enough for me to not change my password? It truly gets bothersome. Maybe I'll need to break down one day and finally get a password manager. :(
Twitter urges users to change passwords after computer 'glitch'
281–290 of 490 posts
Re: Twitter urges users to change passwords after computer 'glitch'
#282Re: Twitter urges users to change passwords after computer 'glitch'
#283Earlier quoted context omitted.
We aren't. Now. (We caught ourselves doing it 4-5 months back, and went through _everything_ checking... Only random accident that brought it to the attention of anyone who bothered to question it too... Two separate instances by different devs of 'if (DEBUG_LEVEL = 3){ }' instead of == 3 - both missed by code reviews too...)
This is why you should turn on compiler warnings and heed them. It would have caught this.
And consider “Yoda Notation”[0], which some people find annoying, but I found an easy hurdle to clear:
if ( 3 = DEBUGLEVEL )
Re: Twitter urges users to change passwords after computer 'glitch'
#284Earlier quoted context omitted.
Genuine question—how would this bug be produced in the first place? My (limited) experience makes me think that cleartext passwords are somehow hard coded to be logged, perhaps through error logging or a feature that’s intended for testing during development. I personally would not code a backend that allows passwords (or any sensitive strings) to be logged in any shape or form in production, so it seems a little wei…
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.
Even logging a username field is likely to catch a bunch of false positives of users entering their passwords in the username input.
Re: Twitter urges users to change passwords after computer 'glitch'
#285Earlier quoted context omitted.
We aren't. Now. (We caught ourselves doing it 4-5 months back, and went through _everything_ checking... Only random accident that brought it to the attention of anyone who bothered to question it too... Two separate instances by different devs of 'if (DEBUG_LEVEL = 3){ }' instead of == 3 - both missed by code reviews too...)
This is why you should turn on compiler warnings and heed them. It would have caught this.
Yeah, exactly. This error shouldn't ever happen, period. All modern development tools give big fat warnings when you do this.
Re: Twitter urges users to change passwords after computer 'glitch'
#286Actual 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.
Genuine question—how would this bug be produced in the first place? My (limited) experience makes me think that cleartext passwords are somehow hard coded to be logged, perhaps through error logging or a feature that’s intended for testing during development. I personally would not code a backend that allows passwords (or any sensitive strings) to be logged in any shape or form in production, so it seems a little wei…
Not exactly log files, but I once noticed a C coredump contained raw passwords in strings that had been free'd but not explicitly overwritten. Similar to how Facebook "deletes" files by merely marking them as deleted, "free" works the same way in C, the memory isn't actually overwritten until something else writes onto it.
Re: Twitter urges users to change passwords after computer 'glitch'
#287Earlier quoted context omitted.
This is why you should turn on compiler warnings and heed them. It would have caught this.
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
Yep - I pointed out that I used to do this in Perl back in '95 or so. At least one of the devs wasn't born then, none of them had ever used Perl.
(I'm not even sure how they'd ended up with a Grails configuration that'd let them do this anyway...)
Re: Twitter urges users to change passwords after computer 'glitch'
#288Earlier quoted context omitted.
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.
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.
It's unclear to me how your random salt would work. From my understanding, you're suggesting smth like:
register: send (username, user_salt, HMAC(user_salt, pwd))
login: send (username). retrieve user_salt. retrieve a server_salt generated randomly. send HMAC(server_salt, HMAC(user_salt, pwd))
But now your password is effectively just HMAC(user_salt, pwd), and the server has to store it in plaintext to be able to verify. Since plaintext passwords in the db are bad, this solution doesn't sound too attractive, unless you were suggesting something else.
Re: Twitter urges users to change passwords after computer 'glitch'
#289Earlier 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…
"Since if someone has it, they can just send it to the server for auth" unless it's only good for a few moments (the form you type it into constantly polling for a new nonce).
The server would not be able to verify a changing hash without knowing the password
Re: Twitter urges users to change passwords after computer 'glitch'
#290Earlier quoted context omitted.
This is why you should turn on compiler warnings and heed them. It would have caught this.
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
Thanks for sharing. I am a less experienced programmer and have never seen this before. The name is so wonderful.