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.

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

Awesome! Thank you for the support :)

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.

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?

Yes, thank you for pointing this out!

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.

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!

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

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)

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.

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

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)

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

Thank you!

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

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!

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.

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.

Yeah, that makes sense. Thanks!

Any thoughts on our pricing?

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

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!

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!

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!

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.

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.

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