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

261–270 of 490 posts

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

#261

Post by yorwba »

John_KZ wrote: post #213
LyndsySimon wrote: post #162

Earlier quoted context omitted.

If you hash the password on the client, the hash made on the client is now the password. It's easy enough to send the hash directly, and the server is none the wiser. That's not to say it's a bad idea, though. I have used client-side hashing in the past to allow passwords of arbitrary length while using finite network resources.

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.

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

#262

Post by tripletao »

jchw wrote: post #209
jrochkind1 wrote: post #156

Earlier 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…

I believe you could use a construction like HMAC to make it so that during authentication (not password setting events) you don't actually send the token. But if someone is already able to MITM your requests, what are the odds they can't just poison the JavaScript to send it in plaintext back to them?

I think their goal is to still use https, but stop anything important from leaking if a sloppy server-side developer logs the full requests after TLS decryption (as Twitter did here).

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

#263

Post by pbhjpbhj »

cerebellum42 wrote: post #252
theCricketer wrote: post #217

Earlier quoted context omitted.

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?

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 reducing hash "replay" possibilities ... but now I'm amateurishly trying to design a crypto scheme ... never a good idea.

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

#264

Post by tzhenghao »

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.

Hmm why should passwords (hashed or not) be stored in logs though? I don’t see a reason for doing that. You could unset it (and/or other sensitive data) before dumping them into logs.

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

#265

Post by geofft »

sbov wrote: post #242
geofft wrote: post #186

Earlier quoted context omitted.

Probably better than 2 is to use actual privilege separation between sensitive data and as much of your service as possible. Handle passwords and password changes in a separate microservice which exchanges it quickly for a session cookie, so that the bulk of your application logic doesn't have passwords in memory at all. For credit card numbers, do something like what Stripe does where one API endpoint exchanges the…

While good advice, your proposal is not necessarily better than #2 because #2 is something that happens automatically once the password hits your object model. If rather than a naked string you have a Password class with literally no way to extract the plain text password then you can be positive that any code that uses it will never accidentally log the password. In contrast, if you rely on microservice tokenization…

You have to get the password into the object model first, though—and your object model can simply not contain a Password type in this process (and only in the password-handling one). You shouldn't pass the password on as a naked string and then drop it—you should prevent the password from getting past the auth service at all.

I think the risk of logging raw passwords in the auth service model is lower because logging in a password-specific microservice is an intuitively dangerous thing to do, so both code authors and code reviewers will pay heightened attention to it. Meanwhile, "log all requests" is a common thing to want to do and will raise fewer alarms in a primarily-business-logic service. (In fact, another usually reasonable thing to do is "log all requests that don't parse properly and return 500...")

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

#266

Post by Zombieball »

tzhenghao wrote: post #264
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.

Hmm why should passwords (hashed or not) be stored in logs though? I don’t see a reason for doing that. You could unset it (and/or other sensitive data) before dumping them into logs.

They shouldn’t. It was an unintentional bug

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

#267

Post by patrickthebold »

tzhenghao wrote: post #264
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.

Hmm why should passwords (hashed or not) be stored in logs though? I don’t see a reason for doing that. You could unset it (and/or other sensitive data) before dumping them into logs.

They shouldn't. It was a mistake.

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

#268

Post by ShabbosGoy »

omarforgotpwd wrote: post #257
hmwhy wrote: post #254

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

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?

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

#269

Post by methodover »

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?

Because when fatal exceptions happen you want to know what the request was. It helps debug what went wrong.

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

#270

Post by mancerayder »

How exactly does one manage in a major company to set up an app in production that spits passwords, or even less sensitive customer data, to a logfile?

Is that the state of infrastructure engineering? The cynic in me wonders if it's related to the trend to take developers with some systems knowledge and turn them into Ops/SA's.

Post reply on HN