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