

What I Learned After I Published My Twitter Password - danielhonigman
http://blogs.wsj.com/digits/2014/07/15/commentary-what-i-learned-and-what-you-should-know-after-i-published-my-twitter-password

======
x1798DE
I think this is just illustrating precisely the _point_ of two-factor
authentication, which is defense in depth. Right now, you have one factor
which means that anything that compromises that factor compromises _you_ , and
who knows what bizarre attacks someone can land once they've started
penetrating your defenses. By publishing your password, you're going back down
to a single factor (and in some ways it's worse than that, because who knows
what security policies are in place for most services - having half of a two-
factor pair here has clearly been interpreted as being someone "more
authenticated" than having NONE of a single factor).

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.

~~~
lotsofcows
"a world where everyone carries around a cheap hardware authentication module"

You mean you don't have ssh-agent and Google Authenticator on your mobile
'phone?

~~~
x1798DE
Well, what I mean is that we'd ideally have a situation where there are cheap
dedicated hardware modules which contain your private key, so that you never
have to trust your private key to a phone or a laptop. A phone can play that
role and likely will at some point, but I'd still like something that is
dumber than a phone, because I don't want the device itself to be able to
harbor malware. Plus, the idea of such an HSM would be that you carry it
around and then you can plug it in (or wirelessly connect it) to any system
you're using, and all that system would be able to do is ask it to use its
private key (which the system wouldn't be able to see) to calculate the
response to some authentication query. If you're worried that your terminal
might be compromised, you wouldn't really want to connect it to your 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.

~~~
lotsofcows
I agree with your point about modern 'phones being too easy to compromise
although I don't agree about the terminal being a specific vector - if I'm
concerned that the terminal is compromised, I'm not going to use it.

Also a good point re GA - I'm not sure why it uses symmetric keys. When it
first came out I'd have assumed it was for relative easy of data entry but now
that even bash trivially displays QR codes it's due an update.

------
orbifold
I think two factor authentification is just an excuse to confirm your real
identity, as it is much harder to obtain a fake phone number compared to a
fake email address. I bet internally someone using two factor authentification
is seen as more valuable to advertisers, since the phone number can probably
be tied to a credit card record and other information collected by banks and
other large real world companies. To 95% of twitter users it would probably be
completely inconsequential if their account were compromised, just create a
new one an let all your friends know.

~~~
oddevan
And to the last 5% that use the "Log in with Twitter" buttons in order to
avoid creating another (probably weak) password, 2-factor is invaluable since
it protects not just our twitter network but any accounts that it has been
linked to.

~~~
orbifold
Sure if you don't care that Twitter knows all the services you use, then that
is fine. It does make little sense to me to use Twitter as your main identity
provider.

------
gmjosack
The article mentions using Google Authenticator but I'd recommend Duo (Duo
Mobile on Android) as it lets you reorganize your accounts, assign icons to
various accounts, and only shows the token you care about via expanding with a
much larger font. Once I passed around 6 two-factor accounts Google
Authenticator became too hard to use.

~~~
tyilo
Have you tried Authy? How does Duo Mobile compare to that?

~~~
kylequest
Authy is much more complicated to setup compared to Duo. In my TFA app
experiments quite a few people had problems with the setup process (failing to
complete it in several cases). They were pretty technical people too, which
says a lot about Authy's usability...

~~~
chimeracoder
There are also a lot of security concerns about Authy that were raised a while
back. If you read the comments, it doesn't instill a lot of confidence in the
team to implement a secure platform of this sort[0].

Unfortunately, security is one of the few areas in which 90% isn't "good
enough" \- all you need is one point of failure for an entire system to get
compromised.

[0]
[https://news.ycombinator.com/item?id=4921684](https://news.ycombinator.com/item?id=4921684)

------
tempestn
Lots of good points there, but this seemed a bit odd: "...it’s worth managing
your passwords, as inconvenient as that can be." Personally I find it much
more convenient to use a password manager than to try to remember what
username (or was it an email address?) and password I used for every obscure
thing I've ever had to log into. Even if you tried to use the same password
for everything, completely ignoring how bad an idea that would be, I think a
good password manager would _still_ be more convenient, since there are often
restrictions on usernames and passwords that prevent you from using the same
thing. (For example, my bank boneheadedly requires an alphanumeric password of
exactly 6 characters...)

------
iLoch
I really hate Twitter's TFA approach and have it disabled for security
reasons. Primarily, if someone gets access to your cellphone network account
(Sprint, ATT, etc.) they can receive texts on your behalf. So if your Twitter
password happens to be the same as your ATT password, you're out of luck. 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.

~~~
sehrope
> So if your Twitter password happens to be the same as your ATT password,
> you're out of luck.

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.

~~~
dictum
> Why would you have both passwords be the same? That makes no sense. All
> passwords should be different.

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.

------
Scoundreller
This may not be the ideal place to ask this but here it goes:

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.

------
kyle_t
I was completely shocked when I read this yesterday morning while drinking my
morning coffee. The best outcome that could arise from the author disclosing
his password is him receiving hundreds of texts that day. I understand the
point he is making, but still a very risky move.

~~~
josu
As long as his Twitter account was isolated[1], the only risk was losing
control of his twitter account for a few days. And given the fact that he
published an article previously saying that he was going to give away his
password, I don't think that he would run into much trouble even if they used
his twitter account for malicious purposes.

[1]This is, the twitter account wasn't being used to log into other services.

~~~
tempestn
You assume that losing control of his twitter account couldn't have unforeseen
consequences. I'm sure the author didn't expect that he would end up having to
change his phone number. It's not at all implausible that there could have
been further repercussions.

------
owenversteeg
Good article. In both this and the previous articles, the author seemed to
know what he was talking about, gave actual security advice, and ran an
interesting experiment.

------
EA
Up until last fall, a hacker could social engineer their way into an AT&T
account.

OP's Twitter account is only as secure at his cell phone service account.

------
danielweber
ISTR someone building a site out there that let you play with Google
Authenticator on your own without messing with your Google account. Did I
imagine that?

~~~
sweis
Like this TOTP debugger? [https://google-
authenticator.googlecode.com/git/libpam/totp....](https://google-
authenticator.googlecode.com/git/libpam/totp.html)

It used to generate a QR code for you to scan, but that's apparently broken.

------
tabrischen
How does SMS based 2FA work when you're overseas? Will you still be able to
receive it and will it incur international charges?

~~~
kryptiskt
It should work, but some networks are really bad at delivering messages,
dropping them or delaying them by hours.

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.

------
matthiasb
My company makes this password manager:
[http://www.cloudentr.com/](http://www.cloudentr.com/) Give it a try! You can
secure all your passwords using your mobile phone as second factor of
authentication.

~~~
sweis
I could not find any technical details from Gemalto besides this blurb, which
doesn't inspire confidence:

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

~~~
matthiasb
sweis,

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.

------
danso
OK, the key newsy takeaway:

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

~~~
x1798DE
>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.

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

~~~
danso
OK, I see that the flaw was that the phone number was revealed to a user when,
after installing the Twitter for iPhone app, wanted to specify that the code
be sent via text to a phone number...And the Twitter app reminds the user --
who again, has successfully entered the password -- what number the message
goes to.

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.

~~~
x1798DE
The threat model isn't "what if someone tells everyone their username and
password", it's "What if someone gets your username and password". I think
most of the time people have _one_ number they connect to, and everything else
will be fringe cases. If you're worried they'll forget what phone number it's
sent to, you can do the same thing you do with other verification/reset loops
- "Enter your e-mail address and we'll send you an e-mail with the phone
number you used". It might not always be the best authentication method, but
at this point almost all authentication falls back to "I control the e-mail
address that I controlled when I started the account" at this point anyway.

Plus, at the very least you could just reveal the last 2 digits of the phone
number upon request. That's still side-channel data leakage, but at least it's
much more contained.

