Digits sounds like a good idea in theory, but relying on SMS for password security is like relying SMS for anything. Even if SMS were secure on its own (meaning traffic was encrypted - which it isn't anyway) you still have the problem of people gaining access through a person's cellular provider account. AT&T for example, will allow you to send and receive SMS from your account on their website - an account which is accessible after "verifying" that you own the account by entering your mother's maiden name or dog's birthday (more or less). Point being, this is no more secure than sending my password in plain text to my email.
You are assuming that the SMS is like a password and the phone number is like a user name, and that's all an attacker would need to log into the app. However, it doesn't have to be designed that way. There could be another value tying the phone number and SMS to the specific app login attempt, in which case intercepting just the SMS is not sufficient.
Sure, build your app with dependency on software from Twitter, because looking back their relationship to developers has been so great until now, and surely they won't abandon this project after two years...
However, if this catches on, SMS sniffing over the air is going to really pick up! :p
SMS messages are often carried over GSM control channels, generally unencrypted over the air.
Even when they are encrypted, it's only A5/1 (already broken).
Just have the login form submit a token that is associated with the SMS token so you can verify the person sitting in front of the login form is the person who also got the SMS code. Similar to common CSRF protection techniques.
For example, the SMS contains a short token. The login form has a (non-visible) 128-bit random guid. When the form is submitted, both tokens are sent to the server and the server verifies that they are both correct.
It doesn't matter how secure the SMS is, it's only one part of the secret. If it's intercepted, the attacker won't be able to guess the guid. Alternatively, if someone is at a login form and trying to guess the short code, just limit each guid to a small number of attempts before expiring.
SMS for this just plain sucks. I do not want to expose my cell phone number to Twitter or any other third party just for a simple app login.
I also will not accept, that someone else (hint hint) sees the comms flow (metadata) from Twitter to my cell phone, let alone the content in there. SMS is leaking like hell. I have more trust in HTTPS than in SMS.
Very surprised to see the Netherlands at 90%, New Zealand at 86%, Sweden at 88%, Japan at 84%, and Australia at 79%. Seems incredibly low for countries with reasonably high quality telecom infrastructures.
New Zealand, Australia, and to a lesser extent Sweden all have vast areas with very low, near zero population densities. Could that be impacting the deliverability?
Absolutely. Outside of the metro areas you start to lose service. Smaller towns sometimes lack service altogether on some providers. Anywhere bush/mountain you'd be very very lucky to get service (of which there is a lot).
FWIW, Digits exposes your phone number to the app:
> A successful Digits account creation will return a stable userID to attach or match with your user record, and an oAuth token for the device. A verified phone number is also returned for convenience, but the user’s number may change at any time and should not be used for authentication.
Also, I understand this might be an edge case, but I don't always have the ability to receive SMS. This can happen in places without cell service (but with WiFi). More importantly, it can happen when traveling abroad and using a data-only SIM, which is especially bad if you get asked to re-login due to the location change.
I think they're providing this so they can make money off the information they get about users and what services they authenticate with.
It makes no sense to use SMS for a login. We know it's not secure and we know it's both slow and unreliable. As an alternative, 3rd parties can already use e-mail authentication for free. Any username/email could normally be linked in an account profile to a phone number to authenticate with, so numbers shouldn't be required for the login part. But if they use a phone number, those are globally unique and tied to a real person, and it works for people who don't have data plans.
So 3rd parties get a universal login that doesn't require a password or a data plan, they get to avoid captchas, and they get the expensive SMS transport for free. The trade-off is they hand over to Twitter who all their users are, and their users might have to wait a while to login as they try and re-try to re-send the auth token.
Hopefully they'll still support you logging in with an e-mail instead of a phone number, so you can have more than one identity for any of the services you use to auth this way (including Twitter itself).
Email: pros: links instead of confirmations code. You can always get it if you have internet (even when switching simcards if traveling). You don't need to rely on anybody infrastructure.
There are parts of the world where people don't use email like we do. Here we tend to keep few email addresses and we typically don't mind signing up using a primary email address. In other places, they trust no one regarding email so they use throwaway email addresses. This makes it hard when someone comes back to the services as they don't know which email they signed up with.
If you a like Twitter and trying to cross-reference people's email/phone from others address book to get people to follow each other, the throwaway email accounts are worthless compared to more stable phone numbers.
Ehh, I don't think that means email is dying for younger people. I'm 20 and email is essential for a lot of things. Everyone I know (which is a fairly broad scope of people) has email and uses it. Everyone gets email at some point, too - so the only challenge is making younger people realize the ubiquity of email earlier on.
Counter-point: It's hard to track SMS after a few carrier hops, especially in third world countries. There is no guarantee on delivery to recipient unlike email.
Am I the only one who's excited about this? I was in the middle of rolling out my own SMS authentication (US-only) but now -great timing, Twitter!- I will definitely take a look at this.
I'm actually curious to see how they're reaching all those countries. SMS deliverability in India (where I'm from) is highly restricted for such uses. We have a DND (Do Not Disturb) directory that most people are registered on. This means that most people can't get marketing SMSs OR transactional messages of any kind. On top of that, you cannot receive messages after 9 PM. I had trouble implementing a Nexmo API once because of it. Now, I know you can override these rules in India with government approval. I'd totally use the Digits API if Twitter has this sorted out.
was a standalone (and expensive one would think) domain needed for this?
<Shrug>
Also, only thing I gathered from this was hey, what's that football app pictured there. Onefootball? looks good! hehe
I have a question, does it let you read your sms, then type it in? Or does it force you to have the SIM in the device, and insists on detecting the authentication SMS on its own (like WhatsApp does)
For the right service, this will be great. But I am very, very hesitant to give out my phone number to anyone, so I will find other ways of signing up for accounts that use this.
At Nexmo we've been powering similar solutions for a lot of apps through our SMS API. However, we've just released a higher-level API that leverages our SMS / Voice APIs to make this kind of number verification easy to implement. Ours includes multiple deliveries and channels (falls back to a voice call if needed). We're looking for early adopters, would love to have you take a look: https://docs.nexmo.com/index.php/verify
