Startup #1: Killing off sim swapping
After a screeching landing on the tropical tarmac in Bali, I shuffled through the airport – and as I wanted to hit the ground running, I bought an Indonesian SIM card straight away. For the first few days, this was great – connection all over Bali is strong and surprisingly fast (you can even FaceTime from the beach). It was only when I sat down to work that the issues started...
A number of the online services I use would send me an SMS authentication code: roughly 6 digits that I needed to enter into the service to prove that I was me. But by using a new Indonesian SIM, I needed to swap the SIM card back over every time I needed to log in.
Now, if you ever done this, quickly you'll realise that SIM card trays are not even remotely designed for ease of access to the SIM. In the typical life of a phone (and what manufacturers expect), the user buys it, chucks a SIM card in and then at most will change phone network once in the life of the device.
The result? The user experience of the regular SIM-swapper looks something like: carrying around a SIM-card taped to a card and repeated attempts at prodding a fast-deteriorating safety-pin at the hole at the opens SIM-card door with occasional luck. It's a pretty shitty experience.
At the same time, a particularly creative form of hacking is on the rise. Now, it's trivial to find out which mobile network a phone number belongs to, and from this point, a would-be hacker can call up your mobile carrier, claim that they are you and that they desperately need a new SIM card sent out. Simply by intercepting that SIM card before it reaches you, they can access all of your SMS two-factor authentication codes... which means they suddenly have unfettered access to all your online accounts, including any business accounts associated with that number. It's pretty bad. The name for this type of hack? SIM-jacking.
The premise
So the idea for LoginCodesAnywhere was simple:
✂️ Break the link between the user's login mobile number and their physical SIM card.
🔢 Use a unique dedicated number... so a hacker wouldn't even be able to know what number to socially-engineer their way into.
☎️ A number not tied to a physical SIM, so no-SIM swapping needed - the user always gets the message, regardless of their current SIM card or where they are in the world.
It was also obvious that users didn't want yet another message inbox to have to regularly check and manage – so a key feature is that the service forwards messages on to a user-specified location.
It basically runs on autopilot – the user can set it up and not have to think about it again: it can forward authentication code messages to a user-defined number or email address (but a dedicated email account is highly recommended to maintain it being a separate authentication 'factor')
Build
This was also a perfect opportunity to start building my development skills with Django (I had just recently gotten to grips with Python).
As a result, this one took a while to build but having learnt the skills, they should be useful as I build the future products in my #20startups project.
Along the road of testing, I discovered some technical limitations: whilst the service worked great with major services (iCloud, Stripe, PayPal etc.), there were some which would refuse to work with a virtual number, such as Gmail, Facebook, Instagram. These services assume that getting a physical number is sufficiently high of a barrier to reduce spam accounts on their platform, and so use it as a proxy reference for new accounts. This meant that the service would likely always be somewhat limited – although for digital nomads and high-frequency travellers desperate for a solution, it still covers the base (particularly for access to business platforms).
Launch
After a brief test of the basic functionality with a few people at my Bali coworking space, I set it live! Rather than a big launch announcement, I went for more of a gradual soft launch, allowing gradual on-boarding to work out bugs (as 2-factor security is a sensitive and important area).
Instead I used Twitter for marketing – as so many digital nomads, remote workers, part of the maker community.
As this is also a hot topic at the moment, I also responded to relevant tweets - capturing those that were interested in the subject.
Each drove a small burst of somewhat targeted traffic to the site without any paid marketing.
Results
Launch:
LCA got 85 visitors in a single day, 575 in the first month and an average thereafter of around 6 new visitors per day. The two biggest referrers were Betalist and my own 20startups site. Average bounce rate was about 80% at launch, but with some tweaks to clarify the value proposition it improved, hovering around 60%.
Because of the almost immediate payment required for the service (despite two month trial period), less engaged visitors bounce fairly quickly, being hit with the payment barrier quite quickly. However, once a customer is in, the experience is sufficiently smooth and the utility high enough that only one customer has cancelled their subscription to date.
Evaluation:
Whilst the solution was neat, and definitely solved a very real problem for people, the solution wasn't fully able to deliver the value proposition of '2-factor authentication in the cloud'. Because of this, marketing it will always be a little complex: "it does this... but not for these".
This is also not a product I am deeply passionate about – it solves a real problem that I faced (and continue to face)... but it's a big responsibility to provide a service around authentication, and probably not one that I'd want to manage at scale.
Mobile numbers as a whole are extremely painful to work with (and to build a product around) - they are inconsistent and expensive, making them hard to scale smoothly. They are also subject to change, meaning that a service could change their policy around virtual numbers, or a mobile operator could change their arrangement, breaking LoginCodesAnywhere functionality.
I also think this will be a short-lived opportunity, with alternatives such as Yubikey and Google Authenticator fundamentally providing a better level of security than SMS 2-factor authentication. That said, there will no doubt be a long tail of services that straggle behind, continuing to use SMS 2FA for years into the future.
Opportunities
A more ideal solution would acquire numbers directly from mobile operators, perhaps being able to provide non-virtual numbers. This could then even integrate into specific platforms and then tumble the numbers on a regular basis, so that the mobile number is dynamic, reducing the attack surface.
Try it and let me know what you think: