[HN Gopher] Launch HN: Cotter (YC W20) - Secure One-Click Phone ...
       ___________________________________________________________________
        
       Launch HN: Cotter (YC W20) - Secure One-Click Phone Number Login
        
       Hi, HN!  We are Putri, Anthony, Kevin, Michelle, and Albert from
       Cotter (https://www.cotter.app)  Cotter is an authentication SDK
       that lets users log in to your website/app securely using phone
       numbers, without a password.  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.  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.  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'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.  To address this, we've built a secure
       authentication SDK that has the convenience of only using a phone
       number but does not have those security drawbacks.  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.  Second, Cotter works across
       apps/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.  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's
       server. Apps can choose to secure the keys using Biometric/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.  How does Cotter make
       money? We charge $0.02/API call + Standard SMS Rates.  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.  Also, if you want to know more about
       integrating with us, you can check out our documentation at
       https://docs.cotter.app
        
       Author : putrikarunia
       Score  : 34 points
       Date   : 2020-03-10 19:15 UTC (3 hours ago)
        
       | mcstafford wrote:
       | 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 wrote:
         | Yeah, that makes sense. Thanks!
         | 
         | Any thoughts on our pricing?
        
           | dylz wrote:
           | Can you define an API call better? Is it any call made with
           | your application/key? If so, how do you handle monetary DoS?
        
       | notlukesky wrote:
       | Good luck! Are there any SMS limitations by geography?
        
         | putrikarunia wrote:
         | 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.
        
       | cxmcc wrote:
       | 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.
        
       | 100-xyz wrote:
       | Good job. Something that can also be used in the US.
        
         | putrikarunia wrote:
         | Yes, we hope that people in the US would also use this. It also
         | works for email if people are more used to it.
        
       | nexuist wrote:
       | 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 wrote:
         | 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.
        
       | matz1 wrote:
       | Your site doesn't seem to allow login with just phone number ?
        
         | putrikarunia wrote:
         | 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 wrote:
           | 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
        
             | putrikarunia wrote:
             | 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!
        
       | erlendfh wrote:
       | What happens if you lose your trusted device?
        
         | putrikarunia wrote:
         | 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!
        
       | spamalot159 wrote:
       | 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 wrote:
         | 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).
        
       | kevin_thibedeau wrote:
       | > How does Cotter make money? We charge $0.02/API call + Standard
       | SMS Rates.
       | 
       | What prevents a botnet attack from abusing this?
        
         | putrikarunia wrote:
         | 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!
        
       ___________________________________________________________________
       (page generated 2020-03-10 23:00 UTC)