so is this a truly passwordless system? that is, a password is never sent over the net at any point ever to an auth/enroll server? i've been working on an example of exactly that kind of system where it uses asymmetric keys to enroll and authenticate users. i'm aware of webauthn but it is heavily focused on crypto dongles which is vast overkill for most situations (say this site, for example). using WebCrypto to generate key pairs and signing login requests allows the server to just need to remember the public keys associated with a given user and an out of band (email, sms...) way to verify their possession of that method.
it's all pretty simple honestly, and it's something of a mystery why it's not gaining traction since webcrypto has been a round for a while now.
Interesting approach :) However, that does require some effort from users as they have to store their private key on their devices. In our system, users are authenticated through social login or through an OTP as described in the post.
js code makes it completely transparent to the user. in my example, you join by typing in a username and an email address then click join. you login by entering your username and clicking login. all of the complexity is under the hood, with the keys (wrapped by a local password if you want), stored in localStorage or indexedDB. it's not even particularly complex and pretty much resembles existing login code. the backend just verifies the key bound to the user and verifies the sig. i patterned the exchange after digest auth (rfc 7616). i came up with this years ago and documented it in rfc 7486 well before webcrypto and webauthn.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
so is this a truly passwordless system? that is, a password is never sent over the net at any point ever to an auth/enroll server? i've been working on an example of exactly that kind of system where it uses asymmetric keys to enroll and authenticate users. i'm aware of webauthn but it is heavily focused on crypto dongles which is vast overkill for most situations (say this site, for example). using WebCrypto to generate key pairs and signing login requests allows the server to just need to remember the public keys associated with a given user and an out of band (email, sms...) way to verify their possession of that method.
it's all pretty simple honestly, and it's something of a mystery why it's not gaining traction since webcrypto has been a round for a while now.
you can check out my example and code here: out.mtcc.com/hoba-bis
Interesting approach :) However, that does require some effort from users as they have to store their private key on their devices. In our system, users are authenticated through social login or through an OTP as described in the post.
js code makes it completely transparent to the user. in my example, you join by typing in a username and an email address then click join. you login by entering your username and clicking login. all of the complexity is under the hood, with the keys (wrapped by a local password if you want), stored in localStorage or indexedDB. it's not even particularly complex and pretty much resembles existing login code. the backend just verifies the key bound to the user and verifies the sig. i patterned the exchange after digest auth (rfc 7616). i came up with this years ago and documented it in rfc 7486 well before webcrypto and webauthn.