A few years ago I worked for a company which was sending many hundreds of thousands of Twilio SMS messages and observed a lot of undefined behavior at scale. Sometimes messages would be delivered twice, sometimes messages would take hours (or days!) to send, and sometimes messages weren't sent at all (even though we were charged for them). I received all sorts of "explanations" most of them naming various intermediaries in the pipe using opaque black lists and undisclosed rate limiting.

Is the SMS backbone in the US reliable during peak traffic (such as at a large sporting event or in an emergency situation) such that I can trust it as a single-point-of-failure for critical applications, and how does the US SMS backbone compare to that of other countries with less investment in their IT infrastructure? Finally, how vulnerable is SMS messaging to snooping by authoritarian governments compared to other forms of authentication?

FWIW this is definitely a project i'll be following, from the perspective that authentication can often be a "bounce-point" for new users of consumer applications and superior authentication strategies can translate directly to $ales.

Hi, yes we feel the problem with SMS and how delivery rate is often not 100%. If I may ask, what do you guys use the SMS for?

I'm not too sure how reliable it is during peak traffic, but I think probably best not to use SMS as a single point of failure. And yes SMS in other countries are more expensive and less reliable.

In our case, the SMS is not used to login users (we use trusted devices). This should reduce the reliance on SMS - only for verifying that the phone number is active. Our cross-app phone number verification also makes it so that if a user already entered SMS otp in just 1 app, they don't need to enter it again in other apps. Additionally, we're looking to integrate WhatsApp to solve this.

About snooping by government officials, I'm not really sure how this applies, but basically since we don't use the SMS OTP for logging in, there is no SMS code to be shared with government officials to allow them to login to someone's account. In our case, the logins would be based off a cryptographic key that is stored in the device's secure storage. As far as I know, this should be pretty safe according to the documentations, that keys cannot be extracted from the hardware.

Let me know if I'm not answering your questions :)

> Is the SMS backbone in the US reliable during peak traffic (such as at a large sporting event or in an emergency situation)?

(anecdata) i was at the first women's march in Washington DC the day after our current president's inauguration. in the midst of it, there was zero connectivity -- nothing could get through to the network. as you made your way towards the edges (several miles), SMS became usable far before voice calls.

the day before, for the inauguration, the government had arranged for cell phone providers to install portable signal-boosting appliances to handle the increased number of people. (these were switched off before the women's march, but the hardware was still physically present.) i imagine places like large sports stadiums do something similar.

What type of businesses do you see this being a fit for? It seems like it could get pretty expensive at scale. IE. 100K logins a day is $720K/yr in costs. Unless I'm missing something. Depending on the business, that might be an expense that really doesn't make sense. Financial applications with funds at stake like crypto exchanges make sense, though.

Oh you're right, we didn't include this in the text. For businesses with high authentication volume, we offer pricing per MAU or a monthly subscription.

Thanks for pointing it out!

I'm glad that you mentioned $0.02/API call here, because it doesn't seem clear through the signup/configuration phase prior to adding funds. I suggest that you make it abundantly clear from one or more of those steps. Did I miss it?

Good luck to you.

Yeah, that makes sense. Thanks!

Any thoughts on our pricing?

Can you define an API call better? Is it any call made with your application/key? If so, how do you handle monetary DoS?

Yes, so an API call is an authentication request. To prevent monetary DoS, right now we're thinking of a couple of ways: We're considering to charge per user per month, this way apps/websites would not be charged per api call. We're also considering to have a rate-limit per account per device, and also limiting the number of unique phone numbers that can be registered from the same device on some period of time.

Any suggestions for this would great!

I honestly don't understand why this needs to be a service. Isn't it trivial to implement with an SMS API like Twilio? I could probably implement a random number generator -> SMS push -> store in my DB faster than I could read the docs of a 3rd party service like Cotter.

So what we provide is not an SMS OTP login. SMS OTP is insecure, that's why we recommend apps not to use SMS OTP as a way to authenticate users. The SMS OTP is only used as a way to verify that the phone number is actually active.

The main idea is that we are making phone number login more secure by using Trusted Devices to login instead of SMS OTP. Using trusted devices, users can only login from their trusted device, and would need approval to login from another device. Our goal is to make it easy and fast for developers to make a secure authentication flow using phone numbers by just using our SDK.

Also, Twilio might be pretty simple to use in the US, but the pricing for other countries doesn't make sense. So we also help by integrating with local sms providers.

How can you add new trusted device? Isn't it just sending SMS OTP again?

To add a trusted device, the new device will generate a QR Code, which then have to be scanned by a trusted device. So all logins and adding new trusted devices will still have to be approved by a trusted device. (Similar to how you login to WhatsApp desktop/web, you scan the QR code from your phone)

So what happens if you lose a trusted device? Or maybe it crashes, or the user signed-in with incognito originally, or anything like that? What's the recovery mechanism?

When you lose your only trusted device, then you would have to go through recovery methods, which is set by the website/app depending on what level of security they require.

For apps that prefer lower security, higher convenience, then possibly users can fall back to SMS OTP. For apps that require higher security, the app can revoke the lost device and either delete the account, or go through customer support to verify the user's identity and enroll a new device.

If you have 2 trusted devices and lost one, you can revoke access from the lost device.

Incognito shouldn't affect this because the trusted device works in mobile apps, not websites.

but haven't you said that the trust is cross app? Doesn't that mean I could make my own app with bare minimum security requirements and then use it to make a new trusted device using fallback SMS OTP (which you agree is insecure) and then hey-presto I'm trusted cross app?

Oh, yeah, sorry I wasn't clear on this. If App A allows fallback SMS OTP and App B doesn't allow fallback SMS OTP, then you will never be able to login to App B with just having your phone number verified.

Our product have 3 features:

- Cross-app phone number verification. The phone number is used only to check if the phone number is active. This is never used for authentication or logging in, and don't have anything to do with the Trusted Device. (For example, sometimes you would register to a website with email and password, and then somewhere in the flow they ask you to verify your email. This email verification has nothing to do with your password)

- Trusted Devices for authentication. The trusted devices are done using cryptographic keys that are generated upon registration. This keys are unique per app, per account, per device. No Cross-App trust here, we don't want any app to be reliant on any other app on authentication.

- Pin/Biometric as additional features.

So the cross-app is only for verifying the phone number. The trusted device is not shared across apps.

I think you just killed half of their idea.

I am from Indonesia. And I do think authentication is crucial for Indonesian market.

As you mentioned, scam is a big issue with SMS-based authentication. People do use sophisticated social engineering to capitalize on the lack of digital literacy from Indonesian people (digital transformation is just happening and education level is poor). And sometimes, their social-engineering skills are sophisticated enough to trap even the highly-educated people (the top 10%).

Hope you guys can bring innovation that matters to help Indonesian economy achieve its full potential!

I am also Indonesian. I am happy that their product is country agnostic. It's pure digital. Their product can be used in other countries as well.

Right now, most founders in Indonesia are too focused on Indonesian market. Yes, we have a large population, almost 300 millions. But we should strive to build digital product startups on which the product can be used in other countries. You know, startups like GitLab, DataDog, Slack, etc.

I wish them success.

Awesome! Thank you for the support :)

Yes, thank you for pointing this out!

Thank you for bringing up the problems with SIM swapping. You say that your SDK provides "the convenience of only using a phone number but does not have those security drawbacks" - can you explain how you do that? In particular, if I as your customer choose to use only the phone number option, how do you protect my customers from SIM swapping?

Good luck on your launch!

The security comes with the Trusted Device feature, where users can only login from a trusted device. This works like DUO, when there's a login attempt from a different device, the Trusted Device will get a prompt and the user can choose whether they want to approve the login.

We only use SMS otp during Sign Ups and not for login, even if someone gets your customer's phone number, they can't login into the account without a trusted device approving the login.

congrats on the launch.

it would be interesting to see how far this will go. similar solutions: fast.co, firebase auth, auth0...

larger companies are still building their own, taking 1month-> ~6months depending on how sophisticated and secure you want the solution to be.

Thank you!

This is really cool. I lived in Cambodia for a couple years and everyone has a phone number.

Question: are there any possible issues with multi-sim card phones? It seems like everyone had 2 sim cards over there. Could you somehow link them together?

That's awesome!

It shouldn't have any issues with multi-sim card phones. The phone number verification would work as if you have multiple Google accounts when trying to sign-in with Google. If you have 2 phone numbers, and have verified those numbers in any app that uses Cotter, then we can check that both numbers are verified on that device.

We don't link the phone numbers. It's up to the website/app if they would allow multiple phone numbers for the same account (like Github, you can have multiple email addresses).

What happens if you lose your trusted device?

There would be recovery methods that would be different for each company, depending on how secure they'd like it to be.

The least-secure but the most convenient way would be to fall back to SMS OTP to recover the account. If more security is required, companies can revoke access to the lost trusted device, and either delete the account or manually allow a certain device to enroll as a new trusted device after verifying the user's identity through a customer support team.

For a more balanced approach, we're considering requiring more than 1 trusted device, or have a friend recovery group to approve the account recovery on a new device.

But this is definitely something we're trying to improve. We'd appreciate any suggestions!

Worked on this problem almost a decade ago, pre-FIDO. Happy to share experience:

The threat model reduced to mobile malware that grabbed private/secret keys, and how the harvested keys could be used at scale. Banks didn't want it, because the net improvements on passwords were edge cases and it didn't have enough standards based compliance assurance to transfer liability to the user.

Things like smoother UX, and customers not having to manage a passwd db were the sell, but those weren't really anyone's problems at the time.

The key problem isn't authentication, it's identity assurance, which means user enrolment that can be "trusted" and then secure personalization of the credential with unique keys. If you are extending the telcoms user idenity trust model, it's sufficient for a few things, but not anything I'd bet a $10k account reimbursement on at scale. You can actually trust an oauth2 partner for identity assurance with some additional data sets.

Second, (first really) an AuthN method is only as secure as it's recovery process, and so the benefits of adding factors, keys, and protocols are just shuffling cards in the same deck.

Apple can do this because they have a secure element on their phones that can store trusted keys, derive new keys, and facilitate personalization. Android fragmentation means you can't rely on this storage on other devices, and you are reduced to the security of the android ecosystem, which is almost as bad as the windows ecosystem in the 1990s.

So how could something as awful as passwords be better than what you are proposing? They are backed by standards, compliance, and maturity, the risk of a compromise can be passed to the user, they do not provide a false sense of security, it's marginally harder to harvest them from a user base using malware than a stored key.

The only people who have done this well have had a separate hardware device (apple's secure element, yubikey's physical device with an SE, etc.) and Authy/Google authenticator and Duo, which are 2nd factor OTP token providers. The only way to provide value in security is to process in a separate, privileged domain. Without this, there is no security value to add.

The privileged source of "entropy," whether it's as analysis or key material, is the only value we can provide in security. It is literally exogenous assurance. There is no endogenous security.

Maybe I've read your product wrong, but it's so similar to problems I spent time on there are some inevitable blockers I can spare you having to waste weeks or months trying to sound out for yourselves, and perhaps you've found the customer who is ready to make these compromises in exchange for the purported benefits?

Hi, thanks for sharing your experience!

So firstly, I agree about how it's only as secure as the recovery process, in which case we give each website/app the freedom to decide for themselves, what level of security they want, compared to user experience.

Regarding Android's storage not being very secure: we are improving security mostly in the scope of social engineering. The type of users we are catering to are mostly people in developing countries who have a phone, no email, no laptop, and their problem is: 1) They either make bad passwords, or they don't remember passwords 2) If they don't remember the password, it will fall back to SMS OTP (because they don't use emails) 3) They are not going to download Authy/Google Auth or Duo. Because of this, most apps in these countries have made the authentication method to be super simple: Phone Number + SMS OTP, no passwords. Unfortunately, this type of user is also easily scammed to share their SMS OTP. So the biggest problem that we see here is social engineering and SIM swapping, and not as much on technical security concerns.

Knowing this problem, our aim is to provide what Authy/DUO does from within the client's app, so users don't have to download a separate app. Also, we are not really providing 2FA. We are trying to make the first factor of phone number login more secure (by not using SMS OTP).

I'm not sure if I cover all of the concerns you pointed out, but this is definitely a great discussion.

Fair. The related developing country stuff I did involved a major credit card's competitor for mPesa and other sms minutes payment schemes in Africa, with tokenization for payments. These are not unsophisticated markets.

The people who pay for this will be the people who are protected by it, so the main use case could be around reducing support costs of password resets or something similar. End users don't reliably care enough as a group, and Relying Parties only see costs. The developing country angle invites scrutiny, as it's not a source of unsophisticated users, in fact if you want amazing hackers, go somewhere small hacks pay off massively because of currency differences.

So the user story needs fleshing out. A good example might be, an app for women in developing countries to prevent their husbands from stealing their phone minutes and/or wages, which has some horrific failure modes, but this is what we're into. The developing'ness piece needs a deeper story than "the poor."

So who steals the SMS OTP in these countries? Arguably if it's social engineering (or just threats) a duress key that mitigated the harm someone could do with the stolen OTP would be a better solution. What is the SMS OTP protecting? Is it bank accounts, what else?

For a security product, you need a) something worth protecting, b) a specific person who cares about it because they literally risk starvation without it, c) an adversary who wants it for a specific reason, and d) a set of controls that make that adversary find a cheaper thing to want.

What's your a-d? Is it compelling? (If your a. is a password, it's not.)

I'm asking because this is really interesting, and I also have a tool for generating these a-d models because they are called threat/risk assessments, which are basically inverted/sad-path business models where things go wrong, but it also generates criteria for security solutions. Nothing the a-d questions don't answer though.

Enterprise customers will ask you dumb versions of these questions that will waste a lot of time. You don't need to answer these here, but consider the exercise.

This is a very interesting way of thinking about this. I guess this would be our biggest concern if we are specifically a security product.

I think I was too focused on answering your question regarding security :). Basically, yes we do offer security, and the security we offer prevents social engineering. But that is not the only point of the product.

SMS OTP is used in general as a way to authenticate, on any kind of app, because it's the only seamless option to reach these types of users. And since SMS OTP is more expensive than our pricing and requires integration with several local providers for a good delivery rate, these developers can simply use Cotter because it's easier to integrate, it works across apps so it reduces friction and SMS cost, and it provides security from day one.

So the value is not only about the threat/risk assessments but it's just a better alternative to SMS OTP logins. Our goal is to make our product faster, cheaper, and better than their current options to authenticate users.

Let me know what you think about this! And thanks for talking about this, it really got us thinking.

As something whose value is focused solely on reducing the cost of SMS OTP, without a net increase in security assurance, which shifts the compromise risk into another threat (from sim swap to malware), aimed at developers who aren't equipped to reason about security and people who are sensitive to SMS fees, it's a narrow solution that could be one of those, "it shouldn't work but it does," things (like mPesa).

Your risk will come from security people in enterprises who know this stuff and will hamper and derail your sales. The opportunity will be in small app developers who get sudden traction, and relying parties will accept the risks of the authn method in exchange for access to that user channel.

I can see why someone would take the chance on investing in someone building rope bridges in developing countries, where engineers would say it's wrong for every conceivable reason, but someone is going to own those routes whether the bridges are rope or steel suspension and there is first mover advantage.

As you can see, security people will likely not be your allies in this, which is fine, but that's the heads up. Presuming you have a channel to those developers in 3rd world markets, I could see how YC might want exposure.

If nothing else, it's a case study and a useful example of how VCs see risk vs. how engineers see risk.:)

Good luck!

How do you address the issue of device sharing?

When I was overseas I worked with prepaid phone cards. The locals would share the same phone, plug in their card code, make their calls, then pass the phone on. As I understood it, the phone owner reaped the benefits of acquiring the unused minutes.

Not sure if this is still an issue. But even a "budget" Android phone (sub $100) is a luxury in developing countries. So I'm sure device sharing is still something to consider.

This is a very interesting case. Thanks for pointing this out!

If I may ask, do these people also download apps in that phone, and then they log out every time they pass on the phone to someone else?

Good job. Something that can also be used in the US.

Yes, we hope that people in the US would also use this. It also works for email if people are more used to it.

Hi Cotter,

I'm interesting to explore further your products. Can we set time to have discussion with you? Thanks.

Hi! Yes, definitely. You can email us at team@cotter.app or start a private chat with us on the Intercom chat on our website https://www.cotter.app/.

We can setup a call in the chat/email if you'd like. Thank you!

Your site doesn't seem to allow login with just phone number ?

We provide both email and phone number authentication. We think that phone numbers works best for our target users, but for developers, we think that emails are more useful.

I only see the email option on https://dev.cotter.app/signin . Also, when I get to that page from another page on your site and cursor into the email field, the browser back button no longer works. it just refreshes the page even if I hit it a bunch quickly

You can choose whether you want your clients to login using email or phone number when you're integrating our SDK into your website or app.

For our developer account, we choose to use email login.

I'll look into the back button problem, thanks for letting me know!

"Quickly enable frictionless authentication for your platforms so you can focus [[on]] building your product." Looks like there's a typo on the first text we read.

Oh, thanks for spotting it!

> How does Cotter make money? We charge $0.02/API call + Standard SMS Rates.

What prevents a botnet attack from abusing this?

We're actually considering charging per user per month, which would solve the problem if it's the same user logging in multiple times.

For the case where people are using different phone numbers and keep on creating new accounts, right now we're trying to enforce a rate limit based on the number of unique phone numbers per session per some period of time, but looking into device fingerprinting as well.

Any suggestions would be great!

Although this company could certainly provide rate limiting services, a perfectly valid answer to this might be "you build the rate limiting yourself". You understand what a valid use case looks like better than this third party does.

Yes this makes a lot of sense! Thanks for bringing it up.

I just created a project and my balance is $0. Do i need to add to my balance to request for an api call?

so you mentioned the security revolves around "trusted devices". what would the cotter login experience be like for someone who locks down their browser? i.e., blocks cookies, resists fingerprinting, etc.?

The trusted device works with mobile apps, and it works by generating cryptographic keys and store in the device's secure storage. It doesn't involve the browser to identify trusted devices.

(Trusted device would work with browsers in the future when WebAuthn is more widely adopted. https://webauthn.io/)

Why should I use this over something else like, say, ~SRQL~ SQRL?

Hi, can you tell me what you mean by SRQL? is it "Sorted Relational Query Language"?

I think parent meant SQRL: https://www.grc.com/sqrl/sqrl.htm

I suspect they mean SQRL:

https://www.grc.com/sqrl/sqrl.htm

Yes, "SQRL" - excuse my typo

Got it, this is quite interesting, I've just read through some of the explanations on SQRL a bit, we're actually following a slightly different protocol, the FIDO protocol https://fidoalliance.org/how-fido-works/ instead of SQRL.

I can see that they're pretty similar, but please correct me if I'm wrong or not answering your question.

I guess the idea is that we make an SDK so developers don't need to do much to implement FIDO. They can just call one function from our SDK to perform authentication. (They don't need to implement the cryptographic keys generation, storage, signature verification, they don't even have to store the public keys, all handled in Cotter's server).

OK fair enough.

One advantage that drew my interest in SQRL (besides being free and open) is that it avoids having any secrets being kept by any service, making any potential leaks a non-issue.

Yes, this is also the case with FIDO. The private key is stored in the device's secure storage, and only the public key is shared to our server. So the private key is never shared anywhere and not kept by any service.

(This is also very interesting to me when I read about FIDO)

Good luck! Are there any SMS limitations by geography?

There isn't any limitations, but we're trying to integrate with local sms providers to offer better rates. We're also going to integrate WhatsApp soon.

Cotter as in cotter pin? :)

So we wanted the name Otter, but we can't get the domain, so we settled for C-Otter (sea otter). :D

kerenn