Can't leak a password if the only thing you have to begin with is a hash...
Twitter urges users to change passwords after computer 'glitch'
181–190 of 490 posts
Re: Twitter urges users to change passwords after computer 'glitch'
#182Re: Twitter urges users to change passwords after computer 'glitch'
#183Earlier quoted context omitted.
It's funny, I wonder if hearing about that github bug made them check if they had committed the same mistake... only to find that they did :-)
I think I, and everyone here, should check as well. If capable, security-minded companies can make such a mistake, so can you.
It only takes one debug statement leaking to prod - it has to be a process, not an event.
Re: Twitter urges users to change passwords after computer 'glitch'
#184Earlier quoted context omitted.
So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?
>That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that? No [0,1...n]. Note that these articles are about encryption, but the arguments against javascript encryption apply to hashing as well. Also consider that no one logs this stuff accidentally to begin with. If the entity controlling the server and writing the code wants to log the passwords, they can rewrit…
Re: Twitter urges users to change passwords after computer 'glitch'
#185So why are they not invalidating exposed passwords like Github did the other day? At the very least they should have a security alert at the top of your feed or something. Edit: Looks like they are alerting users.
Github didn't invalidate passwords. They sent an email to affected users (or just everyone?) with a generic password reset link ( https://news.ycombinator.com/item?id=16972050 )
To add to the speculation in the linked thread, I _did_ recently reset my password, but it was on 28th February.
Re: Twitter urges users to change passwords after computer 'glitch'
#186A couple of steps you can take to reduce the chances of accidentally putting sensitive information in a log. 1. Make a list of all sensitive information that the test users in your test environment will be giving to your application. As part of your test procedure, search all logs for that information. This can be as simple as having a text file with all the sensitive information, and doing a 'grep -F -f sensitive.tx…
This assumes that passwords and credit card numbers are more sensitive than session cookies or tokens, which is usually true because people tend to share passwords across sites and definitely share credit card numbers across sites. So the risk of logging cookies/tokens is much lower. Also, you can revoke all cookies and token much more easily than you can force everyone to change passwords or credit card numbers.
Re: Twitter urges users to change passwords after computer 'glitch'
#187Re: Twitter urges users to change passwords after computer 'glitch'
#188I highly recommend using a password manager. I finally bit the bullet and started using 1Password a few weeks ago, and I haven't looked back since. It's just so much better than having to remember a thousand different passwords. Besides securely managing passwords, you can also use a password manager to secure your digital legacy. 1Password has a feature where you can print out "emergency kit" sheets that has the inf…
Re: Twitter urges users to change passwords after computer 'glitch'
#189Earlier quoted context omitted.
So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?
>That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that? No [0,1...n]. Note that these articles are about encryption, but the arguments against javascript encryption apply to hashing as well. Also consider that no one logs this stuff accidentally to begin with. If the entity controlling the server and writing the code wants to log the passwords, they can rewrit…
It's possible. You create an object called Foo (possibly a serialized data like a protobuf, but any object), and you recursively dump the whole thing to the debug log. Then you realize, oh, when I access a Foo, sometimes I need this one field out of the User object (like their first name), so I'll just add a copy of User within Foo. You don't consider that the User object also contains the password as one of its members. Boom, you are now accidentally logging passwords.
Re: Twitter urges users to change passwords after computer 'glitch'
#190Actual 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.
So best practice would be that the cleartext password is never sent to the server, so they could never log it even accidentally. That means the hashing needs to be done client side, probably with JavaScript. Is there any safe way to do that?