Getting started with login verification(blog.twitter.com)
blog.twitter.com
Getting started with login verification
https://blog.twitter.com/2013/getting-started-login-verification
12 comments
Wait, SMS does not have a delivery guarantee, right? How can they implement a reliable 2FA system on asking the user if they received a text or not?
They can't. That's my point. If they would text you a code and ask you to enter it, then they can infer successful delivery. They don't do that, which means that you can turn on 2FA against a phone number you don't own and completely lock yourself out.
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.
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.
To be fair - you do need the Twitter account password to do that - and if an attacker already has that it's too late to protect anything. So you're down to protecting against people who 1) bother going in to enable TFA, 2) type their mobile number in incorrectly, then 3) click through the "did you get a text from us" without reading it. Sure, making them type in a code you texted them would reduce _a_ category of problems, but I suspect it's a reasonably small category (I'd quite likely have felt OK to accept that problem in order to rush something out quickly with the intent of "fixing it" in the next week or two, but then I've never run anything at Twitter-scale, and I suspect a tiny percentage of users with problem adds up to a _lot_ of support time very quickly there.)
I think if they had a concept of devices to permit "trusted devices", they'd also have a way to do "has already seen this notification on one device, so don't display it as new on other devices".
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.
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.
Not really; you can just set a cookie that indicates that the device is trusted for 2FA. It's no more damaging than a session cookie if hijacked, can be protected by TLS, and doesn't require any special server state.
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.
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.
For webapps, yes, but I'm not sure how they could do it that easily with iOS integration. I'm pretty sure Twitter views iOS/Android as much more important than web.
(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.)
(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.)
You don't typically lose sessions on mobile devices, though. Repeating the 2FA cycle on them isn't nearly so inconvenient as it is in a web browser.
My local (Australian) telecommunications companies say you _can't_ sure SMS as a "secure" channel:
'"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…")
'"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…")
"It's not like mobile number porting attacks have been used to compromise SMS-based 2FA solutions or anything"
Didn't Twitter get their domain hijacked once using exactly that attack?
Didn't Twitter get their domain hijacked once using exactly that attack?
So, experimentally, I've discovered that this makes Twitter accounts subject to DOS attacks. Codes are taking ~70 seconds to arrive right now for me. If I have your username and password, I can just keep logging in with them and having it generate new codes, which invalidates any previous codes. As long as I keep attempting to log in, you will be prevented from logging in since the latency to receive the SMS code is greater than the time it takes me to attempt another login, thereby invalidating the code that will be received.
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.)
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.)
But, this grief is still less than the grief if they'd go through if they didn't have Two Factor Authentication enabled, no? Yes, DOSing and SMS spam sucks, but not nearly as much as having your account successfully hijacked.
Certainly, but you can have 2FA and not have a DOS vector if you provide TOTP.
No Google Authenticator support though. No list of backup passwords either. So if I lose SMS access on my phone, but still have my phone, I still can't get into an account from a new device.
I'm very disappointed they don't have Google Authenticator (or maybe some custom HOTP/TOTP app) support.
And I imagine Twitter thought of the lost phone/sim card problem, is there really no set of preshared backup keys?
And I imagine Twitter thought of the lost phone/sim card problem, is there really no set of preshared backup keys?
I'm guessing they just wanted to get this out the door quickly.
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).
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).
How much more time would it have really taken them to get TOTP out the door? I mean, a toy implementation only takes a few minutes... I get that the scale is completely different and they would need to audit all of their systems, but how long have they been working on this already? I can't imagine they only got the idea that maybe 2FA is a good idea last month. They probably have spent months on this already; had they wanted it from the beginning, would TOTP have really delayed anything?
Exactly. I really can't see a full-blown SMS system taking less time to integrate than TOTP.
Seems like this is just an early run to test usage of 2 factor authentication. In my opinion, twitter has different access patterns than Facebook and Google especially with lots of company/product shared accounts.
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.
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 wonder why they decided to send codes over SMS that we have to manually type into a browser instead of a one-tap push notification to the Twitter app on the phone? Or Google Authenticator?
SMS is a great option since it supports people with feature phones. But, IMO, SMS should be a fallback, rather than the primary option, since it is network-reliant and subject to a number of attacks that app-based authentication is not subject to.
Couldn't agree more.
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'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've been waiting for the SMS for 45 minutes to no avail :( I wonder if it's just load problems on their side.
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.
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.
Urgh, I add 2FA then it asks to let people find me by phone number and I have to untick a load of "text me when..." stuff.
Not cool Twitter.
Not cool Twitter.
I'm just gonna put this out there, could the reason they would not implement Google Authenticator be simply because some suit didn't want people thinking Google+ was in charge of their authentication or something? I hope not, but of all the companies Twitter seems like it would be too 'brand sensitive' or some crap.
Twitter's using short codes that Google Voice doesn't support. It'd be nice if they had an alternate phone number they could text/verify from.
Thanks for the warning. I disabled Verizon texts so I can only get them through Google Voice now.
So... how do I protect my 2nd Twitter account? You can only associate your mobile number to 1 account. How will these social media companies protect the many accounts that they manage? While this is a good first step, it's a major fail. They didn't think through how Twitter is actually used and instead just put a band-aide on a problem.
I wonder how to approach this if one has to manage multiple Twitter accounts... for example for several brands
Anyone any ideas?
Anyone any ideas?
I can't see that option in my account
It's not rolled out to everyone yet apparently, I just enabled it on my account.
What if someone steals your phone?
And has your twitter credentials? Then you are SOL, same as with most other TFA systems out there.
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.