8 ms·

I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and appli

I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear on your finger. That way if someone steals your phone or takes it, you are protected. The entire thing uses a unique pub/pri keys for each site. Keys are backed up by shamir secret sharing distributed across your friends or providers you select. 100% of your keys are encrypted so I the provider can't see it, recover it or be forced to reveal it. Since each site has a key, one could do interesting things. E2E encryption for apps where they can't be forced to reveal a key. If you are using an App and want to send someone a message, the app can fetch the person's pub key, then an inbuilt editor outside of the App in our app will be used to compose the message and encrypt it. That way the App provider can't be forced to reveal the message, and they don't have keys either. Pretty much control in the hands of the user. The same approach can be used for a storage pod where you have a pod that stores your data that you encrypt and control. This is a good start, hopefully we can see the good ideas of this, AT protocol (account portability), keybase, etc all start to bear fruit. What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.

djbusby 3y ago
I love this approach.
hdiehdis 3y ago
i say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers. theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor. instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
- pphysch 3y ago
  > theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor. Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
  - sparkie 3y ago
    I recall Mozilla tried something similar around a decade ago, which was a good solution but didn't get any adoption. There's also been approaches like OpenID which were once popular, where you can have a single login, but they have the problem of third-parties aggregating the sites you visit. Who uses OpenID today? It's all been replaced by facebook or google login. Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both. They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
    - pphysch 3y ago
      > They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority. What does "authority" mean here?
      - sparkie 3y ago
        The user giving authority to access their information. Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face. Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
CharlesW 3y ago
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.
judge2020 3y ago
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
- krono 3y ago
  Call me a cynic but I'm convinced that won't be happening anytime before critical mass adoption of these companies' own solutions, and either defeated acceptance of this new norm or abject incomprehension by whomever remains. "All your base are belong to us"
  - booi 3y ago
    Yeah I fail to see why google would be incentivized to provide this functionality.
    - gowld 3y ago
      EU provides incentive.
      - deleted 3y ago
        [deleted]
      - dotancohen 3y ago
        To which law are you referring?
        tick_tock_tick 3y ago
        I think they are referring to the EU's aggressive data surveillance and zero expectation of privacy to government organizations. While the EU has been very pro customer to business privacy they are vehemently against anything that lets anyone hid anything them the government.
EGreg 3y ago
Contact me and let’s add it to https://qbix.com/platform https://qbix.com/platform and ecosystem so it is not captured by Big Tech corporations. We have a lot to talk about and exchange information. greg at the domain qbix.com
- gowld 3y ago
  > greg at the domain qbix.com I regret to inform you that someone has carelessly or maliciously leaked your deobfuscated email address, on the site https://qbix.com/resume.html https://qbix.com/resume.html
lxgr 3y ago
> use this to tether and lock you in to their platform. You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true. Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth. There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2. [1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#sctn-hybrid https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...
- dcow 3y ago
  You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.
  - lxgr 3y ago
    > the scenario where your password manager is running on the same device as the one where the user is performing the login Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1]. Hopefully, iOS will do the same. [1] https://developers.google.com/identity/passkeys/supported-environments https://developers.google.com/identity/passkeys/supported-en...
    - dcow 3y ago
      Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.
mawise 3y ago
What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right? Disclaimer: I own 2 NFC rings :)
rdsnsca 3y ago
Apple, Google and Microsoft are all supporting passkeys https://developer.apple.com/passkeys/ https://developer.apple.com/passkeys/ https://arstechnica.com/information-technology/2022/10/passkeys-microsoft-apple-and-googles-password-killer-are-finally-here/ https://arstechnica.com/information-technology/2022/10/passk...
- blackhaz 3y ago
  class ASAuthorizationSecurityKeyPublicKeyCredentialAssertionRequest Now I'm wondering what's the longest class name out there...
  - guessmyname 3y ago
    > Now I'm wondering what's the longest class name out there... The longest class names I remember are in the Java Development Kit (JDK) version 1.6, under the Swing+Nimbus namespace: com └─sun └─java └─swing └─plaf └─nimbus ├─... ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePanePainter.java ├─InternalFrameInternalFrameTitlePaneWindowFocusedState.java └─... There were threads in 2012 about them: • https://news.ycombinator.com/item?id=4549685 https://news.ycombinator.com/item?id=4549685 • https://news.ycombinator.com/item?id=4770861 https://news.ycombinator.com/item?id=4770861 Someone copied the code in this repository: https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE%20Development%20Kit%206u45/src/com/sun/java/swing/plaf/nimbus https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...
r00fus 3y ago
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device. That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
- waboremo 3y ago
  Can you explain how passkeys explicitly reaches that end goal, when all of that is already currently possible without passkeys?
  - jamilton 3y ago
    You can share passwords easily, I don't think you can trivially share passkeys.
    - quenix 3y ago
      You can trivially share passkeys with others, at least on all apple devices: https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16.0/ios/16.0 https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
    - snowwrestler 3y ago
      You don’t need to share them because you can enroll more than one for a given account. So for example if 3 people are sharing an account, you can enroll 3 passkeys for that account and they each have their own access. I don’t see any way that passkeys kill account sharing.
      - 3y ago
EthanHeilman 3y ago
MPK is really cool. > What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc. The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you. There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
Moneyyyyy 3y ago
At least Google does those things as an open standard. So it should be easy for everyone else to do their own.
witcH 3y ago
https://www.tokenring.com/ https://www.tokenring.com/
fersarr 3y ago
Cool idea about the NFC ring. Is there anything like that now? Any application?
- xaduha 3y ago
  There's https://store.nfcring.com/products/omni https://store.nfcring.com/products/omni, but chip it uses isn't the best, plenty of applets can't be installed on it. There are payment rings a plenty though, for just using them instead of contactless credit cards.
MagicMoonlight 3y ago
If your ring is your password then they'll just take your ring and your phone...
lofaszvanitt 3y ago
You patent your things, then disseminate. Your ideas will be burglarized, stolen, reintroduced and shown as an invention of someone else (who is a lapdog of given entity).

djbusby 3y ago

I love this approach.

hdiehdis 3y ago

i say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers. theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor. instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.

pphysch 3y ago
> theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor. Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
- sparkie 3y ago
  I recall Mozilla tried something similar around a decade ago, which was a good solution but didn't get any adoption. There's also been approaches like OpenID which were once popular, where you can have a single login, but they have the problem of third-parties aggregating the sites you visit. Who uses OpenID today? It's all been replaced by facebook or google login. Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both. They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
  - pphysch 3y ago
    > They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority. What does "authority" mean here?
    - sparkie 3y ago
      The user giving authority to access their information. Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face. Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.

CharlesW 3y ago

> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.

judge2020 3y ago

> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.

krono 3y ago
Call me a cynic but I'm convinced that won't be happening anytime before critical mass adoption of these companies' own solutions, and either defeated acceptance of this new norm or abject incomprehension by whomever remains. "All your base are belong to us"
- booi 3y ago
  Yeah I fail to see why google would be incentivized to provide this functionality.
  - gowld 3y ago
    EU provides incentive.
    - deleted 3y ago
      [deleted]
    - dotancohen 3y ago
      To which law are you referring?
      - tick_tock_tick 3y ago
        I think they are referring to the EU's aggressive data surveillance and zero expectation of privacy to government organizations. While the EU has been very pro customer to business privacy they are vehemently against anything that lets anyone hid anything them the government.

EGreg 3y ago

Contact me and let’s add it to https://qbix.com/platform https://qbix.com/platform and ecosystem so it is not captured by Big Tech corporations. We have a lot to talk about and exchange information. greg at the domain qbix.com

gowld 3y ago
> greg at the domain qbix.com I regret to inform you that someone has carelessly or maliciously leaked your deobfuscated email address, on the site https://qbix.com/resume.html https://qbix.com/resume.html

lxgr 3y ago

> use this to tether and lock you in to their platform. You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true. Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth. There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2. [1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#sctn-hybrid https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...

dcow 3y ago
You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.
- lxgr 3y ago
  > the scenario where your password manager is running on the same device as the one where the user is performing the login Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1]. Hopefully, iOS will do the same. [1] https://developers.google.com/identity/passkeys/supported-environments https://developers.google.com/identity/passkeys/supported-en...
  - dcow 3y ago
    Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.

mawise 3y ago

What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right? Disclaimer: I own 2 NFC rings :)

rdsnsca 3y ago

Apple, Google and Microsoft are all supporting passkeys https://developer.apple.com/passkeys/ https://developer.apple.com/passkeys/ https://arstechnica.com/information-technology/2022/10/passkeys-microsoft-apple-and-googles-password-killer-are-finally-here/ https://arstechnica.com/information-technology/2022/10/passk...

blackhaz 3y ago
class ASAuthorizationSecurityKeyPublicKeyCredentialAssertionRequest Now I'm wondering what's the longest class name out there...
- guessmyname 3y ago
  > Now I'm wondering what's the longest class name out there... The longest class names I remember are in the Java Development Kit (JDK) version 1.6, under the Swing+Nimbus namespace: com └─sun └─java └─swing └─plaf └─nimbus ├─... ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter.java ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState.java ├─InternalFrameInternalFrameTitlePanePainter.java ├─InternalFrameInternalFrameTitlePaneWindowFocusedState.java └─... There were threads in 2012 about them: • https://news.ycombinator.com/item?id=4549685 https://news.ycombinator.com/item?id=4549685 • https://news.ycombinator.com/item?id=4770861 https://news.ycombinator.com/item?id=4770861 Someone copied the code in this repository: https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE%20Development%20Kit%206u45/src/com/sun/java/swing/plaf/nimbus https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...

r00fus 3y ago

> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device. That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.

waboremo 3y ago
Can you explain how passkeys explicitly reaches that end goal, when all of that is already currently possible without passkeys?
- jamilton 3y ago
  You can share passwords easily, I don't think you can trivially share passkeys.
  - quenix 3y ago
    You can trivially share passkeys with others, at least on all apple devices: https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16.0/ios/16.0 https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
  - snowwrestler 3y ago
    You don’t need to share them because you can enroll more than one for a given account. So for example if 3 people are sharing an account, you can enroll 3 passkeys for that account and they each have their own access. I don’t see any way that passkeys kill account sharing.
    - 3y ago

EthanHeilman 3y ago

MPK is really cool. > What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc. The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you. There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.

Moneyyyyy 3y ago

At least Google does those things as an open standard. So it should be easy for everyone else to do their own.

witcH 3y ago

https://www.tokenring.com/ https://www.tokenring.com/

fersarr 3y ago

Cool idea about the NFC ring. Is there anything like that now? Any application?

xaduha 3y ago
There's https://store.nfcring.com/products/omni https://store.nfcring.com/products/omni, but chip it uses isn't the best, plenty of applets can't be installed on it. There are payment rings a plenty though, for just using them instead of contactless credit cards.

MagicMoonlight 3y ago

If your ring is your password then they'll just take your ring and your phone...

lofaszvanitt 3y ago

You patent your things, then disseminate. Your ideas will be burglarized, stolen, reintroduced and shown as an invention of someone else (who is a lapdog of given entity).