Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#61

Post by zipline88 »

thekeyper wrote: post #58
zipline88 wrote: post #53

Does this use hyperledger aries? https://www.hyperledger.org/use/aries

We do not use Hyperledger Aries, but thanks for showing us. I have a blockchain background, and Keyri is somewhat inspired by blockchain concepts, but we've stayed away from blockchain-based solutions for privacy reasons. The pseudonymity of traceable blockchain transactions (in the auth scenario, authentication request transmissions) do not provide adequate privacy. Apologies if I'm misinterpreting Aries - perhaps i…

Thankyou for taking the time to respond, and congratulations on the launch!

Aries leverages, Decentralized Identifiers[1] with Verifiable Credentials [2]

the "ledger" is where the public keys are stored. eg it could be a permission-ed ledger, similar to SSL certs only known/ parties would publish their keys to the chain.

Example: Sovrin network [3]

Or could be permission-less, maybe focused more towards IoT/whatever

Example: ION Network [4] coming out of Microsoft.

The ledger is not a requirement to establish an identity as shown with the did:peer [5] method

Frankly I think the usage of blockchain was more to get on the marketing bandwagon at the time. Messaging is now moving from "blockchain" to "distributed ledger"

1 - https://www.w3.org/TR/did-core/

2 - https://www.w3.org/TR/vc-data-model/

3 - https://sovrin.org/

4 - https://identity.foundation/ion/

5 - https://identity.foundation/peer-did-method-spec/index.html

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#62

Post by thekeyper »

zipline88 wrote: post #61
thekeyper wrote: post #58

Earlier quoted context omitted.

We do not use Hyperledger Aries, but thanks for showing us. I have a blockchain background, and Keyri is somewhat inspired by blockchain concepts, but we've stayed away from blockchain-based solutions for privacy reasons. The pseudonymity of traceable blockchain transactions (in the auth scenario, authentication request transmissions) do not provide adequate privacy. Apologies if I'm misinterpreting Aries - perhaps i…

Thankyou for taking the time to respond, and congratulations on the launch! Aries leverages, Decentralized Identifiers[1] with Verifiable Credentials [2] the "ledger" is where the public keys are stored. eg it could be a permission-ed ledger, similar to SSL certs only known/ parties would publish their keys to the chain. Example: Sovrin network [3] Or could be permission-less, maybe focused more towards IoT/whatever…

Understood, thanks. I think the concept is excellent - truly a digital ID card that you can present with a simple cryptographic token, thus a real "proof of identity". Keyri is "proof of ownership of a trusted device", which, while being a narrower concept, we believe is more palatable from a go-to-market perspective, since companies prefer to proof identities in their own proprietary way.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#63

Post by zipline88 »

thekeyper wrote: post #62
zipline88 wrote: post #61

Earlier quoted context omitted.

Thankyou for taking the time to respond, and congratulations on the launch! Aries leverages, Decentralized Identifiers[1] with Verifiable Credentials [2] the "ledger" is where the public keys are stored. eg it could be a permission-ed ledger, similar to SSL certs only known/ parties would publish their keys to the chain. Example: Sovrin network [3] Or could be permission-less, maybe focused more towards IoT/whatever…

Understood, thanks. I think the concept is excellent - truly a digital ID card that you can present with a simple cryptographic token, thus a real "proof of identity". Keyri is "proof of ownership of a trusted device", which, while being a narrower concept, we believe is more palatable from a go-to-market perspective, since companies prefer to proof identities in their own proprietary way.

I agree, the worst part of the Aries project is the extreme egos associated with it - but i do really like the ideals.

Another example of over reach: Trust over IP [1]

Again congratulations of the launch, I am not advocating Aries but I am very interested. Especially the intersection of actual users (what you are doing) / pie-in-the-sky ideals

I wish you both the best :)

1 - https://trustoverip.org/

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#64

Post by tialaramex »

ignoramous wrote: post #46
tialaramex wrote: post #31

Earlier quoted context omitted.

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…

> 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... Isn't this a problem then with WhatsApp Web login too which shows a QR code (presumably not tied to any one account as the we…

> am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence?

FIDO2 isn't interested in this problem at all. From the point of view of FIDO2 the rpId ("Relying Party ID" the thing that distinguishes Apple from Facebook) is just arbitrary data selected by the application.

WebAuthn solves the problem by trusting the web browser to know which web site you're visiting. Specifically, the relying party (a web site you're trying to sign into) gets to pick a DNS name you'll authenticate against but the browser matches this DNS name against the HTTPS URL you're looking at, and rejects requests that don't match. The rpId is based on this DNS name, so a phishing site can't work.

e.g. You may think this page is from your bank, but your browser knows it's https://fake-bank.example/ and won't give it WebAuthn credentials for real-bank.example even though you firmly believe that's where you are.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#65

Post by gflacount »

zipline88 wrote: post #63
thekeyper wrote: post #62

Earlier quoted context omitted.

Understood, thanks. I think the concept is excellent - truly a digital ID card that you can present with a simple cryptographic token, thus a real "proof of identity". Keyri is "proof of ownership of a trusted device", which, while being a narrower concept, we believe is more palatable from a go-to-market perspective, since companies prefer to proof identities in their own proprietary way.

I agree, the worst part of the Aries project is the extreme egos associated with it - but i do really like the ideals. Another example of over reach: Trust over IP [1] Again congratulations of the launch, I am not advocating Aries but I am very interested. Especially the intersection of actual users (what you are doing) / pie-in-the-sky ideals I wish you both the best :) 1 - https://trustoverip.org/

Appreciate the detail. It's quite helpful. Thanks very much!

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#66

Post by e12e »

thekeyper wrote: post #54
mpenn wrote: post #48

What’s the process for when a user gets a new phone? I dread getting one because my keys depending on the phone completely disappear and have no transfer mechanism.

Two options, each configurable by the developer implementing the SDK: (1) When a user sets up their new phone using an iCloud / Google Drive backup of their old phone, the private keys will be already embedded in the relevant apps when they first open the app on the new phone. The developer can ask the user to decrypt the private key for the first session with a user-defined passcode (2) The SDK provides a QR backup…

So, if a user changes from Android to iOS or vice versa, there's no (automated) path for continued service?

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#67

Post by e12e »

thekeyper wrote: post #14
thesimon wrote: post #9

> 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 ke…

> 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? Y…

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

Is this rate limited by the phone for access to the secret key?

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#68

Post by thekeyper »

e12e wrote: post #67
thekeyper wrote: post #14

Earlier quoted context omitted.

> 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? Y…

>> 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 Is this rate limited by the phone for access to the secret key?

Yes, when developers enable passcode protection, the guess rate limiting is based on the OS default because it's accessing the same subsystem responsible for unlocking the phone itself.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#69

Post by thekeyper »

e12e wrote: post #66
thekeyper wrote: post #54

Earlier quoted context omitted.

Two options, each configurable by the developer implementing the SDK: (1) When a user sets up their new phone using an iCloud / Google Drive backup of their old phone, the private keys will be already embedded in the relevant apps when they first open the app on the new phone. The developer can ask the user to decrypt the private key for the first session with a user-defined passcode (2) The SDK provides a QR backup…

So, if a user changes from Android to iOS or vice versa, there's no (automated) path for continued service?

Correct, that's currently the case. Users can use QR code backup/restore functionality if enabled by the developer to switch between iOS and Android. That would have to be done app-by-app. We're working on our own cloud backup system to automate this.

I think such transitions between smartphone OSs already entail significant credential transfer issues, since saved passwords also do not automatically move between OSs.

You'd have similar problems if you used "Sign in with Apple" for an app on an iOS device and then switched to Android.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#70

Post by necovek »

gflacount wrote: post #55
oauea wrote: post #45

Earlier quoted context omitted.

Account sharing is never unethical. It's my account and I'll damn well give access to whoever I please. Services such as Netflix mitigate this by limiting the amount of concurrent use, which is fine.

That's a fair point for services that limit use based on number of concurrent devices/streams. There are, however, many services that explicitly state the account may only be used by a given single user and those providers will seek legal action if that user shares their account. This ultimately leads to significant pain for both the company and user.

Going from "there are...many services" to "sharing accounts is robbing companies" is what I am having a problem with. That per-seat pricing "because companies can afford it" is robbing customers instead!

Hey, you are selling on the internet, do not make up "costs" just to increase your revenue. I am fine with restricting simultaneous usage where there is an actual cost to it (eg. streaming) as long as that's clearly indicated (and as people have multiple devices these days, it should never be limited to one-at-a-time).

Post reply on HN