Twitter urges users to change passwords after computer 'glitch' • Hacker News Board

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

#461

Post by dwyerm » Fri, May 04, 2018, 3:26 PM UTC

CiPHPerCoder wrote: post #96

I've seen this scenario unfold before: 1. User provides username/password. 2. An exception occurs somewhere. 3. The stack trace from the exception is logged. 4. The stack trace includes the credentials. 5. The exception ends up in a ticketing system (Trac, JIRA, etc.) 6. Nobody notices for years.

When I was doing some consulting via RDP, I made sure to inform the client that I was about to expose things. "I am about to run strace on this web server instance. This is going to show what all the system calls are doing and how long they're taking. It is going to make the performance of this one instance very poor. It is possible that this will print private information like passwords and credit card numbers in clear text. Are you okay with this?"

I'm not sure they fully understood what they were acknowledging, but I heard back later that they were impressed with my professionalism.

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

#462

Post by dwild » Fri, May 04, 2018, 3:31 PM UTC

fpgaminer wrote: post #143

Back in my younger, move naive days when I first started using a password manager and such a practice was not as widespread, I had the same question I think most other people have: "If my computer gets hacked or infected, won't the attacker instantly grab all the passwords from the manager?" I chose to use a manager anyway, with the logic that if my system was compromised I was owned either way; memorizing passwords…

> Well, as it turns out, the opposite was true and the fear was unfounded. The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises.

That's absurd. I can count on one hand how many account I need to be extremely secured. Accounts that will actually affect me if they were hacked.

- Works - Bank - Paypal - Google - AWS

All have a different and secure passwords.

The remaining accounts that I care about but won't affect me much if they were hacked use variation of a single password.

The accounts where I don't care use a simple password.

If any one of the first one are hacked or leaked, well I was already screwed I guess, the service was hacked... just hope that they take care of it.

If I get hacked, I just hope that I catch it before I log into one of theses accounts, which funnily enough, doesn't happen that much (except for work, but that's mostly at works so not my responsibility).

If any other password get leaked? Well not too bad, I request a new password and that's it.

> The single points of failure offered by servers are far more valuable now than the unwashed masses of networked user computers.

It's true up until it's no longer the case. So many people use cloud backed password manager too... your point currently apply to them too.

You see the big leaks but you don't see the peoples that get their passwords stolen from their computers, it's not new worthy.

It's also the classical: it won't happen to me.

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

#463

Post by brownell » Fri, May 04, 2018, 3:39 PM UTC

jstanley wrote: post #354

brownell wrote: post #291

Earlier quoted context omitted.

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.

The random-salt has to be stored, at least for the length of the authentication request, because the server needs to generate the same hashed-hashed-password as the client to be able to match and authenticate.

> Alternatively a timestamp would be just as good.

I don't see how that would work at all.

I also don't see the need to go any further in detail about how this scheme will not be better than the current best practices.

Never. Roll. Your. Own. Crypto. https://security.stackexchange.com/questions/18197/why-shoul...

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

#464

Post by cryptozeus » Fri, May 04, 2018, 4:02 PM UTC

dschuetz wrote: post #379

cryptozeus wrote: post #340

Earlier quoted context omitted.

Its a mistake , it happens. Software is hard. Change your password.

It would be fine, but people who claim to be pro in software and are being paid premium refuse to learn from mistakes, neither from their own nor from others'. They just mitigate the fallout by saying things "It's was a mistake, sorry about that, it happens, software is hard". Brain surgery is hard. Mistakes happen. But after a few mistakes you probably should stop doing brain surgery altogether. At least the patient…

I understand your frustration but its coming from flawed argument. According to cancer.org, there is 50% chance you survive brain tumor surgery. From that account half the surgena should stop working.

Imagine the twitter traffic and how much code they are dealing with. This kind of mistake can happen and will happen. Someone was surely held accountable which they do not need to disclose.

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

#465

Post by baud147258 » Fri, May 04, 2018, 4:04 PM UTC

_asummers wrote: post #430

baud147258 wrote: post #386

Earlier quoted context omitted.

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.

Good point regarding mutable data. But since we were talking about loglevels, I don't think it's a problem there.

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

#466

Post by blklivesmatter » Fri, May 04, 2018, 4:36 PM UTC

Provacy policy in my hairy bottoms

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

#467

Post by jrochkind1 » Fri, May 04, 2018, 4:49 PM UTC

jaccarmac wrote: post #251

hiccuphippo wrote: post #232

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

> Store the salted hashed password with its salt server side.

So now _this_ is effectively just "the password", that needs to be protected, even though you're storing it server side.

If an attacker has it, they can go through the protocol and auth -- I think, right? So you prob shouldn't be storing it in the db.

All you're doing is shuffling around what "the password" that needs to be protected is, still just a variation of the original attempt in top comment in this thread.

The reason we store hashed passwords in the db instead of the password itself is of course because the hashed password itself is not enough to successfully complete the "auth protocol", without knowing the original password. So it means a database breach does not actually expose info that could be used to successfully complete an auth. (unless they can reverse the hash).

I _think_ in your "protocol" the "original" password actually becomes irelevant, the "salted hashed password with it's salt" is all you need, so now _this_ is the thing you've got to protect, but you're storing it in the db, so now we don't have the benefits of not storing the password in the db that we were hashing passwords in the first place for!

I guess your protocol protects against an eavesdropper better, but we generally just count on https/ssl for that, that's not what password hashing is for in the first place of course. Which is what the OP is about, that _plaintext_ rather than hashed passwords ended up stored and visible, when they never should have been either.

Cryto protocols are hard. We're unlikely to come up with a successful new one.

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

#468

Post by skolemtotem » Fri, May 04, 2018, 5:29 PM UTC

simias wrote: post #389

icebraining wrote: post #346

Earlier quoted context omitted.

This is just one of the many reasons why I like Python. > if a = 3: ^ SyntaxError: invalid syntax

Rust has an interesting take on that, it's not a syntax error to write "if a = 1 { ... }" but it'll fail to compile because the expression "a = true" returns nothing while "if" expects a boolean so it generates a type check error. Of course a consequence of that is that you can't chained affectations (a = b = c) but it's probably a good compromise.

Well in Rust ypu couldn't have = return the new value in general anyway, because it's been moved. So even if chained assignment did work, it'd only work for copy types, and really, a feature that only saves half a dozen characters, on a fraction of the assignments you do, that can only be used a fraction of the time, doesn't seem worth it at all.

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

#469

Post by zerostar07 » Fri, May 04, 2018, 5:37 PM UTC

madrox wrote: post #50

These comments are everything from eliminating passwords (good luck) to “congress should fix it with law” (lol). Having been in the identity space for a while and seen how various companies think about it, these kinds of problems will keep coming up...mostly at companies for whom identity is commodity. These companies will always give account security the minimum requisite attention. No one at Twitter gets excited ab…

Alternatives to passwords have "kind of worked" with bitcoin and cryptocurrencies: When they became valuable and exchange breaches became costly, people started using 2FA (exchanges made them mandatory) and ledgerwallets en masse. We should be making these kinds of technologies cheaper and dumbproof so that everybody can use them. Some alternatives proposed in the past, like OpenID, were almost comically complicated for Joe User.

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

#470

Post by jstanley » Fri, May 04, 2018, 7:22 PM UTC

brownell wrote: post #463

jstanley wrote: post #354

Earlier quoted context omitted.

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.

The random-salt has to be stored, at least for the length of the authentication request, because the server needs to generate the same hashed-hashed-password as the client to be able to match and authenticate. > Alternatively a timestamp would be just as good. I don't see how that would work at all. I also don't see the need to go any further in detail about how this scheme will not be better than the current best pr…

A timestamp would work the same way it works in (e.g.) Google Authenticator.

Incidentally, I really resent how it's impossible to have a discussion of anything at all related to cryptography on HN without somebody bringing up the "never roll your own crypto" dogma.

If the ideas being proposed are bad, please point out why, don't just imply that everyone except you is too stupid to understand.

Edit:

I just reread your comment above and you did a perfectly good job of explaining why it's a bad idea, I must have misunderstood first time round: it's a bad idea because now the login credentials get compromised in a database leak instead of a MITM, which is both more common in practice and affects more users at once.

Sorry for saying you didn't explain why it is a bad idea.