Getting started with login verification
blog.twitter.com
blog.twitter.com
You check the checkbox, and it sends you a text message. And then, rather than asking you to type in the message you received (you know, like any sane 2FA setup would do, to ensure it's working), it just asks you if you received the message. If you click "Yes", then it turns on 2FA. Without, you know, actually verifying that the user received a message.
People don't read dialog boxes. They're just going to click the blue button to get the popup out of the way. I expect there will be plenty of people who manage to lock themselves out of their accounts in the near future.
Literally every other 2FA activation everywhere goes something like this:
1. Set up verification
2. Enter the verification code that you see so we can be sure that what you have matches what we have
3. Yay, you're protected with multi-factor authentication and haven't locked yourself out of your account!
Twitter's setup is more like:
1. Check a checkbox and click a button
2. If you didn't actually read the message and verify that you received a generic text message from Twitter, you are now locked out of your account.
Let's not even touch the fact that they didn't add backup codes, Google Authenticator support, and that you have to be in range of a cell tower to log into Twitter with this on now. It's not like mobile number porting attacks have been used to compromise SMS-based 2FA solutions or anything, or that high-profile Twitter users are being targeted by spear phishing attacks.
It's better than nothing, but I'm really kind of put off by how much of an afterthought this seems to be.
Better yet: They don't have any concept of "trusted devices", so you have to do the 2FA dance every time you log in regardless of whether you've 2FA authed on that device before or not. This means that if you've lost your phone and your desktop session has expired, you can't get back in to turn 2FA off, again meaning that you're completely locked out.
Twitter must really be a disgusting mess architecturally; they have a decent number of competent employees, so it's hard to imagine things like this persisting otherwise.
On first login:
Login sends credentials, no cookie. Provider verifies credentials, doesn't have 2FA verification, sends 2FA challenge. Upon completion of challenge, provider sets session cookie + 2FA cookie.
On logout, the session cookie is destroyed, but the 2FA cookie is not.
On successive logins:
Login sends credentials + 2FA cookie -> provider verifies credentials, verifies 2FA cookie + timestamp, grants a session cookie.
This way, you can gain the power of 2FA (someone stealing my credentials won't be able to log into my account) without the hassle of it (people using stolen credentials won't be logging in on my own computer, so I can trust this computer to bypass challenges for 30 days), and you don't have to add any server state that is aware of any particular computer, save for some value which is tied to the cookie. For bonus points, the server maintains a list of 2FA cookie tokens, and allows them to be revoked, so if my laptop is stolen, I can log in on my desktop, revoke my laptop 2FA cookie, and the 2FA bypass won't work from it anymore. Slightly more work, nothing really significantly difficult, but substantial increase in usability without any real sacrifice of security.
(although, most of their hacking/account hijacking probably happens over non-mobile. If they had a way to improve web login security and strongly separate out mobile integration logins to use a weaker system, that would work too. Although I think it wouldn't be too hard to present to Twitter as a mobile client when you're really a fuzzer or attack script.)
'"SMS is not designed to be a secure communications channel and should not be used by banks for electronic funds transfer authentication," Stanton told iTnews this week.'
and:
'Today, Australians only require their mobile phone number and one of either their mobile account number or date of birth to move their mobile phone number from one service (or telco) to another.'
http://www.itnews.com.au/News/322194,telcos-declare-sms-unsa...
(There's an interesting discussion then where the banks say "you guys should fix that", and the Telcos effecively respond "our business is making it easy for our customers to do things like port numbers, not provide secure TFA channels for you without getting paid for it - not our problem…")
Didn't Twitter get their domain hijacked once using exactly that attack?
Wow.
This also means that I can either a) flood you with text messages, or b) trip some threshold that will prevent Twitter from sending you text messages. In either case, a clever attacker who has the username and password could use this to cause a lot of grief for an account holder.
(This is, by the way, yet another argument for device-based TOTP.)
And I imagine Twitter thought of the lost phone/sim card problem, is there really no set of preshared backup keys?
You get app specific passwords, but they're only good for an hour. By then, your app should have a token that is good indefinitely (and you can revoke from their apps list).
Based on the "..much of the server-side engineering work required to ship this feature has cleared the way for us to deliver more account security enhancements in the future.." I'd expect support for an OTP client soon.
I'm not using SMS on any of my 2-step-auth services because I don't want to be locked into owning that phone number (and worry about roaming charges if I travel).
Google Authenticator or similar apps are my first choice.
I really hate SMS-from auth, anyway. Now my cellphone-provider account is security critical, rather than my installation-of-a-secure-client-I-control. This is some protection against mass attacks on Twitter, but I use a long, unique, random string as my passphrase, so I'm not too worried about that.
Kind of sucks that Twitter has such light security compared to FB/Google/AWS. I guess they're substantially smaller, but this wouldn't be that hard for 1-2 good engineers to get right. If it weren't for the stupidity where Google/Apple/Twitter/Facebook/Amazon/etc. think they're at war with each other, this seems like something they'd be better off partnering/outsourcing.
If I had an app with the mobile client reach of Twitter, I'd use it as an opportunity to become a security/auth provider (using a public key scheme), though.
Not cool Twitter.
Anyone any ideas?