Twitter Digits | Hacker News Reader

Twitter Digits

digits.com

105 pointsuptown47 comments

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.

My favorite feature of SMS authentication is when I get locked out of accounts because I'm traveling and using a different SIM.

https://www.gauthify.com/ - phone, email, sms, and ga?

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.

Have to amend my statement...if the attacker can intercept the SMS in real time, then it is an effective attack:

1. Attacker knows victim's phone number and attempts login

2. Attacker intercepts SMS as it is sent to victim

3. Attacker completes their login process with the SMS code

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

This probably leads to a great user experience.

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.

SMS deliverability is only ~98% in the US. It drops down near 50% in some countries.

https://www.twilio.com/sms/deliverability

Near 50%? It's 38% in Vietnam.

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.

A fairly large edge case is that it wont work on a cellular iPad at all since you can't receive SMSes out of the box.

I hope the SDK detects iPads and offers some kind of alternative login mechanism.

They just text you a code. Totally works with feature phones etc.

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

Why sms confirmations instead of emails?

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.

I saw a few minutes of the presentation. The presenter argued that some percentage of world's population does not use email, but everyone has a phone.

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.

Exactly, some carries drop sms on different occasions and you never know the status.

Also I would argue if you target ppl who don't have email you shouldn't require any authenticated accounts.

Really, they made that argument? So when I'm logging into some website, I'm not going to have access to my email? Bad logic.

I have met many younger people (especially outside the US) that do not have email. They see email as a tool for old people to communicate.

A good comparison would be "So when I'm logging into some website, I'm not going to have access to myspace?"

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.

> "So when I'm logging into some website, I'm not going to have access to myspace?"

Which is even less likely.

Using that logic the confirmation should be sent by whatsup or as a facebook message instead.

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.

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.

EDIT: The documentation is kind of hard to find: https://dev.twitter.com/twitter-kit/ios/digits

If assets (CSS/JS) aren't loading for you, try this: https://dev.twitter.com/products/digits

The site is remarkably clear & comprehensible even without the CSS. Progressive enhancement wins again!

Eurrgh. It's been thirty years since SMS was hacked up, and we still can't get rid of the damn thing...

http://gyrovague.com/2014/06/27/how-sms-set-back-the-mobile-...

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.

Transactional SMS doesn't come under DND, so there's no restriction on that.

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

They're twitter - they probably don't mind.

Plus - for a sign-in solution - I think a standalone domain is probably more important than getting one for "just another app."

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.

Is this simply twitters oauth / single sign in service?

----

This is another story I've read today about twitter rebranding services they provide into their own brand.

Does anyone know of any competing/more established libraries that offer similar features?

Here: https://passwordless.net/ (It's for Express + NodeJS)

Open source, you can use whatever you want to get the code to the user. It's from Mozilla.

Unfortunately I think the biggest advertised feature is the ability to authenticate users by phone number which this doesn't do.

It does and it's designed for it. Found this example online: https://github.com/rbudiharso/smsauth-example Basically you can use any delivery mechanism with it you'd like

My apologies. This wasn't obvious from the main project page.

Google authenticator?

https://code.google.com/p/google-authenticator/

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

So... can I please just use Touch ID? Awesome.

Reply on news.ycombinator.com