Earlier quoted context omitted.
I'm not arguing for a fine, but companies should be legally obligated to tell their users when the personal data of their users might have been compromised.
Like with GPDR ?
Twitter urges users to change passwords after computer 'glitch'
211–220 of 490 posts
Re: Twitter urges users to change passwords after computer 'glitch'
#212A 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…
Re: Twitter urges users to change passwords after computer 'glitch'
#213Why even hash the password on the remote side, shouldn't some challenge-response hashing be more secure? The most likely downside is that without JS it won't work.
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.
Re: Twitter urges users to change passwords after computer 'glitch'
#214The "right" way to handle this is to revoke access to all logged-in devices, revoke all previous passwords, send an email notifying users of the revocations, and force a password change upon next login. But Twitter won't do that because a non-trivial percentage of their user base would never jump through the hoops to get things up and running again and Twitter's MAU numbers would sink.
This doesn’t make a big impact in the end because of how prevalent password reuse is.
Re: Twitter urges users to change passwords after computer 'glitch'
#215Earlier 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?
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…
edit: considering someone eavesdrops on the connection, otherwise that's a whole different kind of vulnerability
Re: Twitter urges users to change passwords after computer 'glitch'
#216I 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…
Time for me to advertise my personal setup again! I use KeePassXC [1] with Syncthing [2] to synchronize my passwords between machines. No third-party! [1] : https://keepassxc.org/ [2] : https://syncthing.net/
Re: Twitter urges users to change passwords after computer 'glitch'
#217Actual 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.
Re: Twitter urges users to change passwords after computer 'glitch'
#218A 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…
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…
Re: Twitter urges users to change passwords after computer 'glitch'
#219I 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…
I keep all my passwords in a text file. I can't imagine remembering them all. I suppose I should keep that file encrypted and synced to multiple devices with rsync or so. Would a password manager give me any advantage over this scheme?
Re: Twitter urges users to change passwords after computer 'glitch'
#220Actual 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?