No amount of entropy will protect against plain security goofs. "It would take a computer about 115 OCTILLION YEARS to crack your password" some analysis tells me. Guess how many engineers it takes to downgrade any password's strength to "123456".
Twitter urges users to change passwords after computer 'glitch'
171–180 of 490 posts
Re: Twitter urges users to change passwords after computer 'glitch'
#172Back 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…
> The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Something to consider is that malware-based compromises of personal systems don't raise as much brouhaha as corporate-level compromises.
My statement is based not on frequency of news, but rather on my understanding of the provenance of passwords in password lists. The vast majority of passwords in password lists are sourced from service hacks; not from user malware. And that makes sense. Malware events net maybe thousands of user passwords? On a good day maybe 100k. But hacks of major services like LinkedIn ... those yielded hundreds of millions of passwords. The two just don't compare in magnitude. Remember that HIBP's list is sitting at something like half a billion password combos right now.
Re: Twitter urges users to change passwords after computer 'glitch'
#173I 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'
#174Earlier 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…
"Since if someone has it, they can just send it to the server for auth" unless it's only good for a few moments (the form you type it into constantly polling for a new nonce).
Re: Twitter urges users to change passwords after computer 'glitch'
#175Earlier 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?
You could do client ssl certs and just skip the password. It would be more work for the user though.
That would transfer it from something you know (a password) to something you have (a device with SSL cert installed) which are meant to protect against different problems.
Re: Twitter urges users to change passwords after computer 'glitch'
#176Actual 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?
[deleted]
Re: Twitter urges users to change passwords after computer 'glitch'
#177Earlier quoted context omitted.
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…
Makes sense, and then you're getting into something akin to SSH key pairs, and I know from experience that many users can't manage that especially across multiple client devices.
There are probably ways to make it reasonable UX, but they probably require built-in browser (or other client) support.
Someone in another part of this thread mentioned the "Web Authentication API" for browsers, which I'm not familiar with, but is possibly trying to approach this?
Re: Twitter urges users to change passwords after computer 'glitch'
#178Earlier quoted context omitted.
> The vast majority of password leaks we've seen over the past decade have been due not to malware but rather server compromises. Something to consider is that malware-based compromises of personal systems don't raise as much brouhaha as corporate-level compromises.
My statement is based not on frequency of news, but rather on my understanding of the provenance of passwords in password lists. The vast majority of passwords in password lists are sourced from service hacks; not from user malware. And that makes sense. Malware events net maybe thousands of user passwords? On a good day maybe 100k. But hacks of major services like LinkedIn ... those yielded hundreds of millions of p…
One thing to note is that a remotely-compromised computer gets you access to the actual browser session and not solely to the password. In fact, most of the time the user has already logged in, and so the session is accessible but the password isn't (users without password managers have no persistent store, and password managers try to keep the secrets encrypted except when the master password has been recently typed).
So it's not often useful to take a password from an individual user and put it in a password list, but it is often useful to maintain persistence on their machine. Tools for doing that (RATs) are definitely common, both from random internet attackers and from e.g. angry exes with physical access to your device. But those aren't the attacks that e.g. HIBP is interested in, so if you're looking at data from people interested in password compromises, the effect is that you'll undercount client-side compromises.
Re: Twitter urges users to change passwords after computer 'glitch'
#179If this happens in a month's time, will they have to pay out $96,000,000 via the GDPR? This came up at my place of work the other day: are data leaks as a result of bugs breaches of the act?
[deleted]
Re: Twitter urges users to change passwords after computer 'glitch'
#180A 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…
Observation: security really does happen in low-level code quality like this.
This is a hard notion to accept because it has to be built into the organization. No silver bullet, no consultant, no five-step methodology. Just rigorous software engineering up and down the stack, and care, and attention to detail.