
Launch HN: Cotter (YC W20) – Secure One-Click Phone Number Login - putrikarunia
Hi, HN!<p>We are Putri, Anthony, Kevin, Michelle, and Albert from Cotter (<a href="https:&#x2F;&#x2F;www.cotter.app" rel="nofollow">https:&#x2F;&#x2F;www.cotter.app</a>)<p>Cotter is an authentication SDK that lets users log in to your website&#x2F;app securely using phone numbers, without a password.<p>We built Cotter because authentication that works in the US doesn’t work in Southeast Asia, India, LatAm, and Africa. People there prefer to use phone numbers to log in because they don’t use email and good passwords are hard to remember.<p>We come from Indonesia. Over there, in order to reach more people, mobile apps make their login easily accessible to everyone, which has resulted in the removal of emails and passwords. They made SMS based authentication a standard across sign up, login, and transactions.<p>However, SMS-based authentication comes with a security tradeoff and costs both users and businesses millions of dollars. Scammers have figured out several ways to extract verification codes via social engineering, SMS forwarding, and SIM-swapping. One of us has lost money due to SIM swapping and we&#x27;ve seen family relatives lose their digital wallet balances from social engineering. It’s easy for these scammers to extract the verification code from their target. The victims of this misconduct tend to be ride-hailers, online merchants, and other people whose income depends on mobile apps, so this issue can hit hard.<p>To address this, we&#x27;ve built a secure authentication SDK that has the convenience of only using a phone number but does not have those security drawbacks.<p>Cotter is unique in 3 ways. First, integrating with Cotter is very fast and easy - developers can provide a full-suite authentication including login, SMS one-time password, Trusted Device, Biometric, and PIN in just a few lines of code.<p>Second, Cotter works across apps&#x2F;websites, just like Google Sign-In. Once the user’s phone number is verified in one app, the user doesn’t need to re-verify their phone number again in other apps - one user does not have to be verified over and over again.<p>Third, Cotter is secure. It works like Apple’s Trusted Devices where users can only log in from a Trusted Device. It also works from within your app (no third-party authenticator app). We are following the FIDO protocol for this. Cotter’s SDK generates asymmetric keys in your device, saves the private key in secure storage, and sends the public key to Cotter&#x27;s server. Apps can choose to secure the keys using Biometric&#x2F;PIN. Every time the app requests an authentication, either for a login or for a transaction, Cotter’s SDK will send a signature using the private key that the app’s server can verify.<p>How does Cotter make money? We charge $0.02&#x2F;API call + Standard SMS Rates.<p>We would love to hear more about your experiences authenticating users! What are your biggest pain points and what services do you wish existed to solve those? We are also happy to discuss how we can make Cotter better and more secure. Either comment here, or shoot us an email anytime at team@cotter.app.<p>Also, if you want to know more about integrating with us, you can check out our documentation at <a href="https:&#x2F;&#x2F;docs.cotter.app" rel="nofollow">https:&#x2F;&#x2F;docs.cotter.app</a>
======
tmpz22
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.

~~~
putrikarunia
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 :)

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

~~~
putrikarunia
Yeah, that makes sense. Thanks!

Any thoughts on our pricing?

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

~~~
putrikarunia
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!

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

~~~
putrikarunia
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!

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

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

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

~~~
putrikarunia
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)

~~~
kichik
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?

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

~~~
sleepychu
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?

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

------
rousyan
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!

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

~~~
putrikarunia
Awesome! Thank you for the support :)

------
nexuist
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!

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

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

~~~
putrikarunia
Thank you!

------
spamalot159
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?

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

------
erlendfh
What happens if you lose your trusted device?

~~~
putrikarunia
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!

------
motohagiography
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?

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

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

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

~~~
motohagiography
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!

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

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

------
destya
Hi Cotter,

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

~~~
putrikarunia
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/](https://www.cotter.app/).

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

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

~~~
putrikarunia
Oh, thanks for spotting it!

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

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

~~~
rojobuffalo
I only see the email option on
[https://dev.cotter.app/signin](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

~~~
putrikarunia
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!

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

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

What prevents a botnet attack from abusing this?

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

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

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

~~~
putrikarunia
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/](https://webauthn.io/))

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

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

~~~
prawn
I suspect they mean SQRL:

[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

~~~
sebastien_bois
Yes, "SQRL" \- excuse my typo

~~~
putrikarunia
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/](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).

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

~~~
putrikarunia
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)

------
notlukesky
Good luck! Are there any SMS limitations by geography?

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

------
leetrout
Cotter as in cotter pin? :)

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

~~~
bacotter
kerenn

