| [HN Gopher] Launch HN: Keyri (YC S21) - Secure smartphone-based ...
___________________________________________________________________
Launch HN: Keyri (YC S21) - Secure smartphone-based passwordless
authentication
Hi HN, we're Zain and Grant at Keyri (https://keyri.co/). We make a
white label passwordless authentication SDK that companies can
embed into their mobile apps for instant biometrics-based
registration and login on any device. Keyri can be used for (1)
authentication by itself, (2) an auth option in addition to
passwords and OpenID, (3) step-up identity verification in high
risk-score scenarios. Passwords suck - they're terrible for
security and terrible for ease of use. 2FA solutions are clunky and
still insecure - for example, SMS-based 2FA doesn't work when you
travel abroad, and it can be defeated with phishing and SIM
swapping. They also allow users to share their subscription
accounts with others, robbing companies of revenue. Password-based
auth also enables the sort of bot activity that renders sites like
Ticketmaster and StockX unusable for real customers. 2FA methods
currently in the market represent a tradeoff between security and
ease of use. Secure 2FA methods like USB keys are a pain to use,
while easy 2FA methods like SMS passcodes are unsecure. Keyri
essentially takes the USB key concept and puts it in users' phones.
This is hard to do in a secure way while maintaining a seamless UX
due to the need for two-way communication to prevent phishing. Some
enterprise-focused smartphone-based passwordless solutions require
a Bluetooth or WiFi connection between users' phones and their
other devices to ensure security, which is obviously untenable for
rollout to mass audiences. Our system works securely 100% over
HTTPS and computer vision (beyond just reading QR codes). An
additional difficulty is that companies don't want to force their
users to download a third-party app. We solve this with our SDK
that allows companies to bake our passwordless auth capability into
their apps. Keyri replaces passwords with public key cryptography
plus biometrics. Instead of remembering and typing in your
credentials, authentication happens by just scanning a QR code (on
desktop web) or tapping a button (on mobile web and mobile native
apps). Thanks to biometrics and cryptographic functions happening
in the background, multi-factor authentication happens in one step
that takes less than a second. At registration, the Keyri SDK
generates a key pair, stores the private key in the phone's secure
enclave, and sends the public key to the relying party's (our
customer's) credential server. At login, the SDK first verifies the
user's identity via biometrics (Face ID etc.), then generates a
signed authentication request using the stored private key, then
sends that request to the relying party's auth server, which
authenticates the user by verifying the signature using the public
key it received during registration. The user's private keys never
leave their phone. There's a lot more cryptography, handshakes,
secret sauce, etc. that happen during the auth flow, but those are
incidental to the core concept outlined above. What's different
about us? 1. Keyri is available as a mobile SDK, allowing any
company to offer passwordless onboarding and WhatsApp-like QR code
login entirely within their own app without a long and tricky dev
cycle. 2. Keyri doesn't require any typing or setup / opt in. Other
passwordless solutions require typing out a username/email address
and/or connecting by bluetooth, specialized onboarding, etc. 3. Key
backup and recovery is handled automatically via the cloud (iCloud
/ Google Drive). Additional backup/restore options are available in
our SDK. 4. Privacy: unlike OpenID and some other passwordless
solutions, Keyri's server does not store or see any private keys or
any personal information. Our API simply facilitates the
transmission of public keys and encrypted signed authentication
requests. We charge companies based on how many unique users use
Keyri to log in to their web services in a given month. We can
provide our API in a self-hostable format for companies in heavily
regulated industries. Our auth endpoint code is open source, but
our API and mobile SDK are not. If you want to try the experience,
check out our live demo here: https://keyri.co/demo. Note that this
demo uses our standalone authenticator app, which is available for
companies that don't have their own mobile app, but our main
product is the white label SDK that incorporates the authenticator
app's full functionality (and then some) into our customers' apps.
As a long-time HN lurker, I know the community has expertise and
strong opinions on authentication. It would be great to get your
feedback, and I'd be happy to answer any questions. We're very
actively building out the system, so any ideas for bolstering our
system are welcome.
Author : thekeyper
Score : 39 points
Date : 2021-08-04 16:54 UTC (6 hours ago)
| tialaramex wrote:
| For the smartphone case, why would I want to pay for Keyri,
| rather than use WebAuthn (for the web) or the smartphone OS-
| provided FIDO2 feature that ships with the OS?
|
| https://developers.google.com/identity/fido/android/native-a...
| thekeyper wrote:
| Keyri makes less sense for smartphone-only applications. The
| primary case we solve for is applications that have both mobile
| and desktop web interfaces. Phones are already essentially
| considered trusted devices, whether auth there happened via
| password, SMS OTP, OpenID, FIDO2, etc. Keyri bridges the "trust
| gap" between the trusted smartphone in the user's hand and the
| untrusted desktop computer / smart TV / whatever other screen
| they're sitting in front of via our QR + CV + HTTPS system.
|
| Deploying WebAuthn / FIDO2 on desktop web/native apps is far
| more challenging given the standard's need for communication
| between the authenticator device and client device to happen
| via USB, Bluetooth, or NFC. USB is obviously out of the
| question for consumer-facing apps, and companies simply can't
| ask typical users to connect their devices via Bluetooth -
| setup and reliability are the UX issues with BT.
| tialaramex wrote:
| For the desktop scenario, the reason that "trust gap" exists
| is that the chain of custody is too murky and if Keyri solves
| that I didn't see how. Of course maybe that's your secret
| sauce.
|
| Specifically, how does the _phone_ know which web page its
| owner is looking at on their laptop when they scanned the QR
| code ? You need to arrange that it 's _not possible_ to take
| the QR code generated for you and present it to a sucker for
| them to scan instead so that you 're signed in as them and
| like I said, if Keyri does that then I don't see how.
| thekeyper wrote:
| Nail on the head. That's the problem that the secret sauce
| solves. Without going too much in to it (because I don't
| think it's a very defensible moat at the moment), the phone
| sees stuff on the screen other than the QR code, which bad
| actors cannot present to victims.
| [deleted]
| qzw wrote:
| So are you saying that even if the bad actors found out
| how the secret sauce works, they would not be able to
| spoof a legit page? In other words, is the obscurity in
| the CV part purely for competitive reasons, or does it
| also serve a security purpose?
| thekeyper wrote:
| Yes, even if bad actors figured out the secret sauce,
| they couldn't defeat it easily. It's possible, but if
| they hack you the way they'd have to hack you in order to
| defeat our CV element, you'd have much bigger problems to
| worry about. So yes, the lack of disclosure is for
| competitive reasons, not for security purposes.
| sabrehagen wrote:
| You referred to 'QR + CV + HTTPS system'. Is there more to
| the CV component than taking a photo?
| thekeyper wrote:
| Yes, there's more to it than just reading the QR code. As
| mentioned above, I don't think it's a very defensible tech
| differentiator right now (lots of better-funded
| cybersecurity companies out there), but in summary, the
| phone sees stuff on the screen other than the QR code.
| smoldesu wrote:
| The pricing page is very offputting to me. The first is free, but
| scaling starts and ends with "contact us"? Not the sort of thing
| I'd invest in, if I was in the market for such a thing. That's
| just my take though.
| gflacount wrote:
| That's a fair point and something we're definitely looking
| into. Ultimately, if you are interested in our SDK, we'll need
| to have an implementation conversation and can discuss pricing
| at that time, but it's definitely something we're considering
| updating. Thank you for the feedback.
| [deleted]
| heyjoke wrote:
| Terrible name!
| necovek wrote:
| I was immediately intrigued by the proposal, though I can't
| imagine ever wanting to rely on my phone to be identified (what
| if my battery dies? I left it in another room? hey, a customer is
| gone and that sale has not gone through).
|
| > They also allow users to share their subscription accounts with
| others, robbing companies of revenue.
|
| This made me question your motives: "robbing" is a very strong
| statement for something like sharing accounts -- even if you are
| in that extortionist camp that likes to get every last cent out
| of the customer, I wouldn't advertise it as widely.
|
| Why do you feel that companies should be worried about people
| sharing accounts with people they have enough trust in to share
| accounts (and devices like your phone) with?
|
| It's also the first time I read that OpenID requires somebody
| else to see your private keys, or to share any private data that
| you do not wish to share: can you elaborate on that?
| thekeyper wrote:
| Regarding your first point: phones are already intrinsic to
| authentication, whether it's through SMS OTP, TOTP, or push
| notification verification. Wherever you have 2FA enabled (other
| than email magic link), you are generally SOL if you lose your
| phone. We are well past the days when people would forget their
| phone at home, and most people have their phones within reach.
| That said, our early customers are deploying Keyri as an option
| in parallel to password-based auth, which, while not ideal, is
| a smooth way to transition their users to a better UX that just
| happens to be more secure.
|
| Regarding account sharing: agreed that the "robbing" language
| is harsh and should be toned down. That said, it is a problem
| that deserves a solution. For example, there are companies like
| data providers that charge businesses hundreds or thousands per
| month for access to their platforms, and they face massive
| account sharing issues from these businesses that can totally
| afford to pay for all of the seats they need but are not
| willing to pay because they don't need to - they can just share
| accounts among their employees. At the same time, I'd argue
| that any account sharing, even if it's for a $5/month streaming
| platform account, is unethical and a violation of TOS -
| companies should have access to tools that definitively prevent
| these violations. They currently already try to stop account
| sharing through IP logging, cookie tracking, etc., but those
| methods are not as reliable as changing the auth mechanism
| altogether to something like Keyri, in which credentials are
| not free-floating strings that can be passed from one person to
| another.
|
| Regarding OpenID: OpenID providers (Google, FB, etc.) don't see
| your private keys, but by registering and logging in on various
| services through them, you are giving those platforms yet more
| data about yourself. That is why these platforms provide OpenID
| auth services for free. This privacy threat is nebulous, but
| privacy-conscious people like myself don't use OpenID for this
| reason.
| throw03172019 wrote:
| iOS screenshots: "Log in Two Accounts"
| thekeyper wrote:
| Ah yes, thanks for pointing that out. The iOS app store listing
| is ancient and terrible. The Google Play store listing is a bit
| better, but still from a time when I was doing all the design
| work :)
| [deleted]
| [deleted]
| gabrielsroka wrote:
| Is it OpenID or OpenID Connect (OIDC)? (Does anyone still use
| OpenID?)
| thekeyper wrote:
| I used "OpenID" in the text as shorthand for OIDC. To be clear,
| Keyri is not OpenID / OIDC for preserving privacy and making
| the Keyri API a fail- and compromise-secure system.
| qecez wrote:
| Have you considered lnurl-auth?
|
| https://github.com/fiatjaf/awesome-lnurl#lnurl-auth
| ignoramous wrote:
| Congratulations on the launch, Zain and Grant.
|
| I've come across a decent share of passwordless solutions in
| recent times (like gazepass.com and sawolabs.com to name two of
| the recent upstarts in the space), while GRC's SQRL has been
| around a lot longer.
|
| The bane of passwordless auth systems is the whole ceremony
| around forgot-password / change-password flows (in this case, re-
| associating a new public/private keypair, on device loss, or on
| device change). Keybase solved the latter scenario by storing the
| _TripleSec_ -wrapped keypair with a user-supplied _password_ [0];
| though, in a system we designed for our use, we use OPAQUE
| (password-based) to keywrap the material [1], while Signal
| recently demonstrated a rather elaborate scheme (passphrase-
| based) for tucking away user secrets [2]. SQRL solved the former
| in a rather unconventional way by treating DHKE as a two-way hash
| function [3], while Keybase has (IIRC) various recovery scenarios
| due to the nature of their service.
|
| How does keyri.co handle these two scenarios? Backups don't help
| in cases where private-keys are compromised. Besides, some might
| even question the security behind backing-up private-keys to
| Google/Apple in the first place. I, personally, consider it an
| unacceptable compromise: Using an intermediary like evervault.com
| / scrt.network may be slightly better (or even MPC [4])?
|
| If I may, I'm kind of curious about the cryptography involved
| when the authentication is delegated via the QR code. We designed
| ours based on the Keybase KEX [5] secured over a CPACE session
| [6].
|
| Thanks.
|
| [0] https://archive.is/XosXO
|
| [1] https://archive.is/zmpxv
|
| [2] https://archive.is/3sTZR
|
| [3] https://archive.is/H72o2
|
| [4] https://archive.is/Ojz9U
|
| [5] https://archive.is/46VzS
|
| [6] https://archive.is/4F1lp
| thekeyper wrote:
| Thanks very much for the heavily referenced post. As an aside,
| I built the prototype of this last year in a vacuum without
| knowing any passwordless solutions other than FIDO2 systems. My
| cofounder disabused me of the notion that this was a totally
| novel concept. I'd never heard of gazepass or sawolabs before
| and now feel even less original :). That said, I think you
| recognize the differences between our system and those two, so
| I won't get in to those details unless you want me to.
|
| Agreed, device continuity is the #1 challenge for truly
| passwordless systems. The Google/Apple cloud backup system
| we're currently on is a compromise to deliver a seamless UX for
| mass audiences in the majority of device transition cases. As
| soon as a user sets up their new phone using an iCloud / Google
| backup of their old phone, they will have Keyri private keys
| already embedded in their restored apps. Developers,
| optionally, can require users to input a PIN/passcode in order
| to restore the keys following a backup restoration.
|
| For the minority of cases in which this cloud-backup-based
| device transition does not work smoothly, companies can offer
| customer support lines, which, as mentioned in another reply,
| will be far less busy than "forgot my password" CS lines,
| thereby making social engineering easier to detect.
|
| Again, while not ideal, as mentioned in another reply, the
| current solution is based on Keychain (iOS) / KeyStore
| (Android), which are rather secure and private, and compromise
| of those systems entails... a really bad day for the victim
| given they're associated with saved passwords, emails, text
| messages, photos, etc.
|
| And yes, we definitely plan to maintain our own cloud backup
| service. That is really hard to architect in a way that's both
| secure and frictionless, so we'll be designing that for some
| time. Evervault and scrt.network are great references - thank
| you.
| ignoramous wrote:
| Thanks! Btw, is _keyri_ short for key-ring? In my native
| tongue, Gujarati, it means " _Ant_ ".
|
| All the best.
| gflacount wrote:
| haha - you guessed it! Draft 0.1 was to be named Keyri
| while owning the .ng domain name to create Keyri.ng. We
| opted against the Nigerian domain but kept Keyri.
| wulltd wrote:
| Hello! Please compare this to Steve Gibsons SQRL login scheme.
| Are there any major differences or is this based on that project?
| It looks very similar on the surface
| thekeyper wrote:
| The general crypto scheme (auth based on signed requests) is
| the same as SQRL. Differences: (1) SQRL employs one identity
| that users use across multiple SQRL-enabled services. Keyri-
| enabled accounts are not portable/natively-shareable across
| different services like that - they are specific to the
| services users registered with (2) Users don't need to download
| an SQRL client on their desktop device. I see that independent
| developers have made iOS and Android clients, but Steve notes
| they currently lack certain important features (though I
| haven't investigated enough to know their deficiencies) (3) Our
| main product is an SDK that developers can embed in their own
| mobile apps
| dolni wrote:
| Do I understand your design right in that private keys are backed
| up to Google Drive or iCloud?
|
| Giving all my login information to a third party seems like an
| awful idea. How are the keys secured from Google and Apple?
|
| What is the contingency plan for logging in if your biometrics
| change? People lose fingers sometimes.
| thekeyper wrote:
| Private keys are backed up via iCloud Keychain (on iOS) and
| Android KeyStore (on Android). Both are encrypted systems and
| are the backbone of Apple and Google password managers,
| respectively.
|
| On the device, private keys live in the phone's secure enclave,
| usually backed by a hardware security module. When you get a
| new phone, these keys can only be restored when you set up the
| new phone from a backup of your old phone - thus, the security
| of the private keys in the Keyri system is on par with the
| security of Apple / Google password managers as well as
| smartphone cloud backups in general, which is pretty good.
|
| Other authenticator apps, like Google Authenticator, Duo, etc.
| use these same backup methods. Others, like Authy, maintain
| their own cloud backup systems.
|
| That said, I agree cloud backups are not ideal, but I think
| they're necessary to maintain a smooth UX for most users. Our
| SDK provides developers the option to disable cloud backups and
| instead enable QR code backups, which allow users to export
| their private keys onto a QR code that they can print out and
| keep somewhere safe, like where they keep their passport.
|
| In case biometrics fail, (1) we give developers an option to
| enable a PIN fallback. Some apps like Credit Karma do this
| today. (2) Companies can have their own "I lost my finger"
| customer support process and allow users to reset their
| credentials upon approval. I suspect that process will see less
| traffic than "I forgot my password", so it should (a) cut down
| on CS costs and (b) make it easier to detect social engineering
| attempts.
| thesimon wrote:
| > for example, SMS-based 2FA doesn't work when you travel abroad
|
| WiFi calling usually also supports texts over wifi.
|
| > then generates a signed authentication request using the stored
| private key, then sends that request to the relying party's auth
| server, which authenticates the user by verifying the signature
| using the public key it received during registration
|
| so as a customer, I need to keep track of all public keys of my
| customers?
|
| > Key backup and recovery is handled automatically via the cloud
| (iCloud / Google Drive)
|
| So in case I get access to a Gmail account, I can get full access
| to the customers account. Is the key protected by passphrases?
| thekeyper wrote:
| > WiFi calling usually also supports texts over wifi.
|
| True, but WiFi calling remains opt-in for most carriers (and I
| suspect it'll remain so given the incentives in play). I don't
| have stats on WiFi calling adoption, but anecdotally, most
| people I've asked (including my cofounder), have been SOL when
| traveling abroad and relying on SMS OTP
|
| > so as a customer, I need to keep track of all public keys of
| my customers?
|
| You only need to keep track of the one public key that your
| user generated for your service, no different than keeping
| track of their password. It's arguably easier to keep track of
| a public key than a password given you don't absolutely have to
| hash+salt a public key.
|
| > So in case I get access to a Gmail account, I can get full
| access to the customers account.
|
| Yes, if you manage to break in to a Google or Apple account
| (which is a lot harder than breaking into an account at just
| about any other company), you would get access to an
| individual's private keys, same as you would get access to all
| of their stored passwords, email OTP, email password recovery,
| text messages, photos, OIDC-connected accounts, etc.
|
| > Is the key protected by passphrases?
|
| Yes, developers can enable securing the keys with a user-set
| 4-digit PIN that the user must input upon key recovery. This is
| optional for developers.
| tialaramex wrote:
| > so as a customer, I need to keep track of all public keys of
| my customers?
|
| Yes. You probably want a reasonable limit. A customer might
| have ten phones, but if they have a _hundred_ phones they
| already know they 're a weirdo and you won't be the first one
| to tell them that. You will probably also want to have a way
| for customers to distinguish one from another, so that they can
| say "Oh I gave my old iPhone to my brother" and delete the
| unneeded credentials.
|
| The good news is that as their name might suggest, they're not
| secrets, so now you don't need to worry about anybody stealing
| them. If Keyri did even a halfway competent job of this they're
| useless to anybody except you.
| jeffbarg wrote:
| It's shocking to me that authentication the way WhatsApp /
| Discord do it is not a) commonplace and b) productized for
| developers. This feels like an obvious first step solution IMO -
| best of luck with the launch.
|
| Edit: having the standalone Keyri app work for apps that don't
| have a dedicated mobile app of their own feels like it would
| drastically increase the market size here. Auth0 / Cognito are
| woefully unequipped for most web app's authentication needs, so
| there's still a huge opportunity there.
| thekeyper wrote:
| Thanks. Yes, the concept is to productize the WhatsApp/Discord
| UX. Keyri differs from them on how it works behind the scenes
| for increased security and ease of integration. BTW - QR login
| is much more prevalent in China. Just about every major and
| minor tech platform there has QR login. I see that as a case of
| leapfrogging, and I hope we can accelerate its adoption in the
| West and other regions.
|
| Agreed that the standalone Keyri app has its place in our
| longer term strategy, especially when it comes to workforce SSO
| applications. We're currently targeting the consumer-facing
| web, and the roadblock we've heard from companies we've spoken
| to there is that it's easier for them to ask their users to
| "download the Google Authenticator app" or "download the Duo
| app" than it is to "download the Keyri app". It's a matter of
| our fledgling legitimacy at this point, though we hope to get
| to a point where users can accept and prefer the Keyri app
| (because the UX and security really are better than Google
| Authenticator / TOTP apps)
| jeffbarg wrote:
| Super interesting re: China. Curious if there are open source
| projects/libraries they build on or if most of that is built
| internally.
| thekeyper wrote:
| I don't have much inside info, but the contents of the QR
| codes on Alibaba, JD.com, and others differ substantially,
| so I suspect each is building their systems in-house,
| though in China, I would think there's more of an
| established playbook for building them given its
| prevalence. I haven't run across a dedicated
| library/package for this.
|
| In the West, WhatsApp and Discord have massively different
| schemes for QR login.
| 1cvmask wrote:
| Saas pass has a similar offering for developers for over 5 years.
| We need more such initiatives like yours to help raise awareness
| that there are passwordless options out there.
| gflacount wrote:
| Just checked out SaaS pass and it is definitely a robust "auth
| in a box" solution. Thank you, yes ultimately the goal is to
| eliminate account takeovers and consumer headaches - we think
| we have the ideal solution but also look forward to other
| players pushing the passwordless agenda forward.
| [deleted]
| ttul wrote:
| It seems as though every SaaS provider is already rolling their
| own authentication app - my iPhone is becoming crowded with them
| (Xero, Adobe, etc) - so the timing of Keyri is fantastic.
| gflacount wrote:
| Thanks very much! Yes, agreed, the number of authenticator apps
| is becoming annoying at best and arguably daunting - not to
| mention the prevalence of "sign in with ___" which has left
| consumers confused about whether they've leveraged Google,
| Facebook, Apple, Xero, Github, Discord, etc for each service.
___________________________________________________________________
(page generated 2021-08-04 23:00 UTC) |