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

431–440 of 490 posts

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

#431

Post by Bromskloss »

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.

Wouldn't it be better to never even send the password to the server, but instead performing a challenge-response procedure? Does HTTP have no such feature built in?

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

#432

Post by bonesss »

tigershark wrote: post #334
foo101 wrote: 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…

And if you write f# or Java code?

These kinds of issues are excellent commercials for why the strictness of a language like F# (or OCaml, Haskell, etc), is such a powerful tool for correctness:

1) Outside of initialization, assignment is done with the `2) Return types and inputs are strictly validated so an accidental assignment (returning a `void`/`unit` type), would not compile as the function expects a bool.

3) Immutable by default, so even if #1 and #2 were somehow compromised the compiler would still halt and complain that you were trying to write to something unwriteable

Any of the above would terminally prevent compilation, much less hitting a code review or getting into production... Correctness from the ground up prevents whole categories of bugs at the cost of enforcing coding discipline :)

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

#433

Post by Bromskloss »

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.

> implementing plans to prevent this bug from happening again

How does one do that?

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

#434

Post by tigershark »

Freak_NL wrote: post #397
tigershark wrote: post #334

Earlier quoted context omitted.

And if you write f# or Java code?

In Java you usually use `.equals()` to test equality, or if your argument is a boolean value: if (myVar) { // } Instead of `myVar == true/false`. The accidental assignment is much less common due to the way equality is tested in Java. Also, `null` comparisons being assigned will fail to compile (assuming var is a String here): TestApp.java:6: error: incompatible types: String cannot be converted to boolean if (var =…

But in Java it’s much easier to do the error of using == instead of equals if you always jump language.

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

#435

Post by tigershark »

bonesss wrote: post #432
tigershark wrote: post #334

Earlier quoted context omitted.

And if you write f# or Java code?

These kinds of issues are excellent commercials for why the strictness of a language like F# (or OCaml, Haskell, etc), is such a powerful tool for correctness: 1) Outside of initialization, assignment is done with the ` 2) Return types and inputs are strictly validated so an accidental assignment (returning a `void`/`unit` type), would not compile as the function expects a bool. 3) Immutable by default, so even if #1…

This is why I love F# but if you jump between f# and c# your muscle memory will suffer.

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

#436

Post by rscafi »

Bromskloss wrote: post #433
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.

> implementing plans to prevent this bug from happening again How does one do that?

Being simplistic, perhaps an automated test with a known password on account creation or login (e.g. "dolphins") and then a search for the value on all generated logs.

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

#437

Post by wool_gather »

madeofpalk wrote: post #244
wool_gather wrote: post #238

Earlier quoted context omitted.

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?

Yup. Affected users were emailed 24 hours ago. Only affected people who initiated a password reset previously (I assume during a certain time frame?) > During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you'll need to reset your password to regain access to your…

+1 Thanks for the details.

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

#438

Post by mbid »

sumeno wrote: post #429
mbid wrote: post #426

Reminder that none of this would be necessary if nobody reused their passwords.

Sure it would. People using Twitter still need to change their password even if it is the only place they use their password.

To defend against what? That some guy at twitter who saw the logs can login and change somebody's status?

Anyway, I guess you're right, I simplified. It is kind of a valid point, although if I was this paranoid then I would never leave the house. I just wanted to say that if the web wouldn't have been built on a giant piece of s*, for example password authentication, none of this would have been necessary.

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

#439

Post by pbhjpbhj »

deepbreath wrote: post #280
pbhjpbhj wrote: post #263

Earlier quoted context omitted.

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?

Verify the signature, check the time, use the hash as if it were the password to re-hash and compare with DB?

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

#440

Post by amelius »

overlordalex wrote: post #398
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.

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).
Post reply on HN