That said, I would love it if the default single factor authentication method were public keys rather than passwords. I get how impractical that is with people constantly trying to access things in some device-independent way, but I fantasize about a world where everyone carries around a cheap hardware authentication module that just negotiates the cryptographic part of SSL handshakes as the primary authentication factor (with passwords and biometrics as secondary and tertiary factors as desired). Sure would be nice if the only thing that could be leaked after a data breach was your public key.
You mean you don't have ssh-agent and Google Authenticator on your mobile 'phone?
Also, Google Authenticator is similar to a really fancy password because it's a symmetric key system. It's nice because you only have to enter in one-time passwords on untrusted devices, but the downside is that both you and the service you're authenticating with has the same key, meaning that if either you or the service you're authenticating with is compromised, the attacker can authenticate as you. With SSL, the service being compromised doesn't actually get the attacker anything except your public key.
There are moves towards such a future with U2F / UAF (Fido) and Yubikeys (a U2F version is meant to be released this year). I know it won't roll out exactly as planned, but I'm still excited by the tech.
We move closer to the day when I can buy embedded authentication hardware in the form of a ring, and I can make endless jokes about One Ring to Rule Them All.
Why would you have both passwords be the same? That makes no sense. All passwords should be different.
> I only use two factor authentication if I can add it to my Authenticator app and save the code/QR code somewhere offline. Everything else is just too complex to be secure.
TOTP based two-factor auth (e.g. Google Authenticator) is my preferred method as well though I'll still set up an alternative method if it's not available. For example Namecheap offers 2FA via SMS. While not preferred, it's better than nothing.
I'd put good money on the percentage of AT&T customers who use the same password for all their web services being sizable enough to make that a valid concern.
Sure it does. With only one password you are less likely to forget how to log in to an account. It makes perfect sense.
>All passwords should be different.
And eat veggies with every meal. And properly hydrate throughout the day. And get 40 minutes of moderate cardio at least three times a week. And call your mother more. And floss daily.
You can't expect all the people to follow the "best" advice all the time.
What about authenticating a logout? If someone is intercepting your communication, and you logout, how can you be sure that your logout has actually executed?
The "You have signed out" page could display a one-time code that should match a second set of seemingly randomly generated codes on your mobile phone.
[1]This is, the twitter account wasn't being used to log into other services.
OP's Twitter account is only as secure at his cell phone service account.
It used to generate a QR code for you to scan, but that's apparently broken.
As for charges, that may be a problem. But I have never seen international charges of over a dollar for a simple text. But I haven't been to really exotic locations.
I still use SMS for the second factor, it's way less secure, but I have it mostly to protect against opportunistic attacks, and having the second factor bound to a device that I will lose or kill with 100% certainty isn't a great solution for me.
"We encrypt your CloudEntr password with a cryptographic hash function – and make sure you’re the only one with the key. We also secure your web logins with AES-256 symmetric key encryption algorithm."
I met with the CloudEntr team to learn more about the technical implementation. They are working on a security page which will provide more details soon. In the meantime, I can share what I learned from them.
The CloudEntr password is stored hashed and salted on our servers, it is also used to encrypt and decrypt all the application passwords and notes within our web browser plug-in.
I will post the link to the security page once it is published! Thanks for your feedback.
> But a glaring flaw in Twitter’s account-security system lets anyone who obtains your password learn whatever mobile-phone number you’ve associated with your Twitter account if you turned on a simple but highly effective security measure
So...I don't know what the "flaw" is...but it doesn't seem to me that the OP learned the biggest lesson of all about security: that pretty much everything is a tradeoff.
Granted, I'm having a hard time thinking why Twitter would feel the need to expose the phone-number at all to a user outside of his/her own account page, so I'm guessing that is some unintended bug. However, consider the situation: The OP gives away his password...Two-factor authentication never, ever meant "hey, it's just as strong as if you give away one of the factors"...I've never designed a security system before, but I'm guessing things would become very convoluted if security designers had to treat giving away your password -- as a public announcement and media figure -- as anything but an edge case. The inconvenience of 2-factor-authentication is meant to offset the problem of total compromise given the relatively frequent chance of getting phished. Twitter's flaw, as described, is likely not a main attack vector for phishers who are sending out thousands and thousands of emails and hoping to get turnkey access to someone's account...even if Twitter gives away the phone-number through some sort of exerted effort...that's unlikely to be the exerted effort used by mass phishers. It's a totally different security game when you're the target of thousands rather than one target among thousands.
(that said, Twitter should fix the flaw, unless there's some other dependency on having the phone number be accessible)
The flaw is side-channel data leakage about the authentication process and about the user data - they're revealing private information to someone who has not successfully authenticated. Just because the guy published his password doesn't mean it's not a flaw - if someone got his password from a compromised database they shouldn't be able to leverage that into finding out his phone number or anything else about him, if he's already arranged with Twitter (or any other service) to a protocol which basically says, "Don't believe anyone saying they are me unless they both know my password and have my phone."
Frankly, a well-designed 2FA system shouldn't even reveal whether or not you've successfully authenticated using one of the factors. For TOTP this is possible because you can enter in the username, password and TOTP code all at the same time (though it's rare to see this implementation). Even if TOTP is not enabled for most accounts, you'd still want to show the box and say, "Leave this blank if you don't have TOTP enabled". For this SMS-based second-factor, I'm not sure how to design it so that there are no side-channel attacks other than sending an SMS with an authentication token every single time, whether or not the password was entered correctly (which allows random people with your login to just randomly send you authentication spam).
So, if you're thinking, what kind of dumbass would need to be reminded what phone the code was going to?...well, the OP for starters. In fact, he recommends readers to get Google Voice numbers (ooh, another attack vector/dependency, but let's ignore that for now)...so, if you're such a user, who has a phone and some burner numbers, and you tell the Twitter app to send a reminder to your phone number...and nothing comes...that's going to seem like a point of failure.
And IMO, that situation is going to be much more likely than the case of a user telling the world his password and username. Also, it seems more likely than phishers doing something more damaging than getting phone numbers after manually going through the phone app for each password stolen...My impression is that such phishers do not typically rely on manual methods, especially if by doing so, they don't get access to the target account...seems like a low return on investment of effort.
That's primarily to tell the user which phone to check - which isn't a bad thing.
They should probably fix it by saying "we've texted your 2FA code to the phone number ending 171" - or similar.
Now the other part of the equation: a security system has to be designed against real-world practicalities...In this case, where does the main risk come from? Mass-anonymous attacks, such as phishing or a database compromise ...now unless phone-numbers can be mass-acquired via knowing a bunch of passwords (can the installing of the Twitter app for iPhone and clicking the "send to phone" link be automated?)...it now becomes a lot of work to take that extra step...and when you've completed it...you still can't break into the Twitter account...How many phishers are stealing passwords just so they can learn a bunch of people's phone numbers? The ones that have that strategy...well, keep on doing that, because that's way more work than other channels for mass-gathering phone numbers.
Now, if the retort is, "well, there may be someone who an attacker REALLY wants to compromise, and the phone number is one more piece of the puzzle."...Then that's a different ballgame. Now you have an attacker who is not drive-by-random phishing, but is going after one person, and going after that one person hard.
So the situation where a victim gives an antagonist (say, the FBI, or NSA, or whoever you are investigating) their password...again, that is most definitely an edge case. And it requires a different systems design (by design, I mean, the details fallback procedures for cases when a user loses their phone and needs to recover it, and so forth).
I can see advantages for Twitter to show the phone number to someone who knows an email and the actual password: you may be someone with multiple phones, or have forgotten that your 2-factor-auth is assigned to a different phone/Google Voice...showing the phone number mitigates the confusion of the user who's wondering when the hell the code is coming, when in fact, the code may never come to the expected phone number.
So, how frequent is that situation compared to one where a user announces his password to the whole world? I'm guessing, quite frequent.
