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

251–260 of 490 posts

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

#251

Post by jaccarmac »

hiccuphippo wrote: post #232
theon144 wrote: post #215

Earlier quoted context omitted.

But wouldn't you due to random salting at least mitigate the disclosure of the password which might people use elsewhere? edit: considering someone eavesdrops on the connection, otherwise that's a whole different kind of vulnerability

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.

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

#252

Post by cerebellum42 »

theCricketer wrote: post #217
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.

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 would be.

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

#253

Post by stingrae »

pishpash wrote: post #237
zackbloom wrote: post #220

Earlier quoted context omitted.

Realize the point of hashing the password is to make sure the thing users send to you is different than the thing you store. You'll still have to hash the hashes again on your end, otherwise anyone who gets accessed to your stored passwords could use them to login.

But at least, with salt, it wouldn't be applicable to other sites, just one. Better to just never reuse a password though. Honestly sites should just standardize on a password changing protocol, that will go a long way towards making passwords actually disposable.

I don't think a password changing protocol would help make passwords disposable. Making people change passwords often will result in people reusing more passwords.

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

#254

Post by hmwhy »

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.

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 weird to me that this mistake is considered a “bug” instead of a very careless mistake. Am I missing something?

EDIT: Thank you very much in advance!

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

#255

Post by jcoffland »

bigiain wrote: post #245
milesokeefe wrote: post #141

Earlier quoted context omitted.

Yep, glad I read this thread. We were making the same simple mistake.

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.

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

#256

Post by bognition »

bigiain wrote: post #245
milesokeefe wrote: post #141

Earlier quoted context omitted.

Yep, glad I read this thread. We were making the same simple mistake.

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

seems like a bug in your platform

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

#257

Post by omarforgotpwd »

hmwhy wrote: post #254
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.

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.

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

#258

Post by mehrdadn »

euyyn wrote: post #230
mehrdadn wrote: post #221

Earlier quoted context omitted.

Not really... it's not that simple. You could use the time of day as a seed for the hash, for example. There are tradeoffs to be made, which is partly why they don't do it, but the story isn't as simple as "the hash becomes the password".

Then how does the server check that it's valid?

The time of day is known to both the client and the server right? So they check to see that they get the same hash.

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

#259

Post by nokcha »

theCricketer wrote: post #217
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.

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?

I can't think of a good reason not to hash on the client side (in addition to doing a further hash on the server side -- you don't want the hash stored on the server to be able to be used to log in, in case the database of hashed passwords is leaked). The only thing a bit trickier is configuring the work factor so that it can be done in a reasonable amount of time on all devices that the user is likely to use.

Ideally all users would change their passwords to something completely different in the event of a leak. But realistically this just doesn't happen -- some users refuse to change their passwords, and others just change one character. If only the client-side hash is leaked rather than the raw password, you can greatly mitigate the damage by just changing the salt at the next login.

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

#260

Post by avemg »

hmwhy wrote: post #254
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.

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…

Careless mistakes are probably one of the most common types of bug you’ll find in the wild
Post reply on HN