Live data from Hacker News

Twitter urges users to change passwords after computer 'glitch'

reuters.com

421–430 of 490 posts

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

#421

At work one of our most commonly used libraries prints it's connection string (including the plain text password, username and database) in the log files on debug level (which I often see as the configured level). When I pointed it out they told me it was intentional, and that attackers wouldn't go to the log files anyway if they could acces the system. I gave up on the discussion at that point

Should probably clarify I'm not talking about client passwords being logged; just the credentials required to read just about anything in the database

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

#422
post #192
post #144

Earlier quoted context omitted.

> I highly recommend using a password manager. I really wish websites would support use of client side TLS certificates as part of the authentication process. Combining that with a username and password would give you two-factor authentication.

Client side TLS certificates get sent in the clear before you authenticate the server. (You can send them in a renegotiation, but renegotiation has been a historic source of both implementation and protocol security bugs because it does complicated things to TLS state.) So you don't want a client-side certificate that includes your name; that's a huge privacy leak. You could imagine a scheme where you give a user a c…

In TLS 1.3 client certs are sent over an encrypted link, and a reasonable client can and should wait for Finished from the server to arrive, at which point they're entirely sure of who their recipient is too.

Another nice thing is that TLS 1.3 servers can send a CertificateRequest asking for a particular _type_ of certificate, so (if that's ever used in anger) it lets us have clients that don't need to waste the user's time when they don't actually have a suitable certificate anyway. In earlier versions servers could only hint about which CAs they trust, not anything else.

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

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

I don't think there's a solution that "solves all problems". What if you want to log in using a dumb terminal or not execute untrusted code on your host?

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

#425

Earlier quoted context omitted.

Paying people more doesn't prevent mistakes. If you banned every developer the first time they made a mistake their wouldn't be any developers.

No, it doesn't. And that's not the issue. It's OK to make mistakes if you learn from them to prevent them from happening twice or trice. But apparently even if paid premium they don't. There were soooo many password db hacks and cracks in the recent years, I can't believe people still defend bad software engineering as if mistakes is a natural occurrence which cannot be prevented. You can't prevent singular mistakes,…

Would you relax? If what Twitter says is true (and there's no reason to think it's not), these were passwords which were logged to plaintext logs, which only people internal to the company can read.

We're not talking about a massive password breach, a bunch of script kiddies who found a database of plaintext credit cards by going to /admin.php and logging in with "admin / admin", or anything like that. We're talking about a mistake Github themselves made (and if you think Github doesn't know what they're doing in terms of security, I question your judgement).

Furthermore, when was the last time there was a major security breach at Twitter? You're claiming they're "keeping" bad developers and not learning from their mistakes as if this was a regular occurence for them.

And coming from me, I don't usually defend security breaches and malpractice. This doesn't really qualify. They made an official announcement, notified all users, even unaffected ones, both by email and on first login; that's more than you can ask them to do.

What bothers me about reactionary posts like yours is they give negative feedback to companies who actually do right by their breaches, which as is well known in the security field, is a matter of when, not if.

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

#427
post #417
post #183

Earlier quoted context omitted.

We schedule log reviews just like we schedule backup tests. (Similar stuff gets caught during normal troubleshooting, but reviews are more comprehensive.) It only takes one debug statement leaking to prod - it has to be a process, not an event.

Why not automate this? Create a user with an extremely unusual password and create a script that logs them in once an hour. Use another script to grep the logs for this unusual password, and if it appears fire an alert. Security reviews are important but we should be able to automate detection of basic security failures like this.

This only works if you automate every possible code path. If you're logging passwords during some obscure error in the login flow then an automated login very likely won't catch it.

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

#428
post #416

Stupid question department: W3c and IETF or other similar clever folks really like security stuff and do lots of clever things to make us safer. So why couldn't we create a http browser/server authentication method that has something closer to a nonce-based challenge/response mechanism? If it were standardized, the browsers could even do some clever hashing of some peer addresses or other things that we think should…

These challenge response mechanisms still require a shared secret. This means the server still needs to know either your password or a hashed version of it. TLS covers the problems a challenge-response method is supposed to solve. That is, TLS prevents replay attacks because the shared secret is sent under encryption. Really, the solution to exposing passwords to the endpoint is to do key-derivation client-side, with…

> This means the server still needs to know either your password or a hashed version of it.

Yes, the latter, please.

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

#430

Earlier quoted context omitted.

And if you write f# or Java code?

For java code, use final so that you have constants.

Note these are only constant pointers. Your data is still mutable if the underlying data structure is mutable, (e.g. HashMap). Haven't used Java in a few years, but I made religious use of final, even in locals and params.
Post reply on HN