5 ms·

Show HN: NullAuth – A proposal for password-less authentication

13 points by jeswin 9y ago

skibz 9y ago
Hi! I wanted to check out the browser extension that is mentioned, but the site is returning 404. Mostly, I wanted to find out whether the extension is using WebCrypto for the key generation, signing, verification, etc, and how the private key is being stored. Can you please elaborate on this?
- jeswin 9y ago
  As I mentioned on the top, it isn't ready yet. I just wanted to put a spec out there for discussion. I also wanted to take ideas on implementation, such as what you just provided. I'll keep you posted on progress, if your email is in your profile. Hoping to have everything (plug-in and serverside examples) ready in a week or two.
  - skibz 9y ago
    Sorry, I missed that. I love the idea. It reminds me of something I read on HN a few years back where somebody proposed using SSH auth for web authentication.
  - skibz 9y ago
    Also, forgot to mention: If you were to use WebCrypto, it ought to be possible to securely (with respect to cross-origin policy) store a user's private key using IndexedDB.
    - jeswin 9y ago
      Being able to transfer private keys between devices owned by a user might be a necessary feature. Otherwise accounts will be tied to a single device. Not sure what would be a good way to do this though.
      - skibz 9y ago
        Absolutely, yeah. WebCrypto has support for keypairs that can have the private key data extracted (there are limits, though, which I cannot accurately remember) from the JavaScript object in which they are contained. So it ought to be possible to extract the key data, encrypt it (also using WebCrypto) and sync it (somehow) to another device.
      - joantune 9y ago
        Keybase had something for that if I'm not mistaken
    - jeswin 9y ago
      The other option will be to generate a new key pair on the new device, and then add the public key to an account via an already registered key. Add key for <user@website> at <utcmillisecs>: <new_public_key_goes_here>;<sign>
      - jeswin 9y ago
        Or maybe just do it with a UI, after logging in with the original key. However, That would restrict the user to adding new devices only from trusted machines. Again, having a command ("Add key ..." as in parent message) for this would make this feature accessible to password/key managers.
jimnotgym 9y ago
I am always interested in proposals for getting rid of passwords. However I am not smart enough to review the technology without the domain experts on HN breaking it down for me
NuSkooler 9y ago
This sounds interesting... Integration with the major password managers would help adoption I'd think.
fiatjaf 9y ago
Nice, but where do you keep your private key? Why storing and syncing a private key or multiple private keys is better than storing and syncing a complex password or multiple complex passwords?
- jeswin 9y ago
  Syncing private keys seems like a somewhat risky thing to do. I'm leaning towards generating a new key and something like this: Add key for <user@website> at <utcmillisecs>: <new_public_key_goes_here>;<sign_with_current> Also see: https://news.ycombinator.com/item?id=15943546 https://news.ycombinator.com/item?id=15943546
fiatjaf 9y ago
I have another suggestion: keep a public database of linked accounts: someone@gmail.com == someone@twitter == someone@keybase. Let people append to their set of linked accounts only if they prove to control at least one of the accounts in the set plus the account being added. How do you prove you control something? I don't know.
- niftich 9y ago
  You mention Keybase as one of those accounts, but isn't this one of the goals of Keybase? See: https://keybase.io/docs/command_line https://keybase.io/docs/command_line
  - fiatjaf 9y ago
    No, Keybase uses these social network proofs to verify the ownership of the public key so you can encrypt messages to it, like what a "web of trust" would do in traditional public key directories. Since they need public proofs, email will not be supported, for example. Also, they're very slow[1] in adding more providers, or perhaps they don't want more providers. But yes, I think the database Keybase is building can be used for a login system somehow. [1]: https://github.com/keybase/keybase-issues/issues/518 https://github.com/keybase/keybase-issues/issues/518
joantune 9y ago
A couple of things: What happens when/if your private key is compromised? All accesses will be compromised All accesses need to be rekeyed Some factor that's unique to the service would help to minimize this, something of an unique extension to the public/private key, something like two keys for the service, the general one and the other one (this is something other than your password, so the server would still need no password) Tooling is key . Not only being able to manage all those public/private keys but also backing them up and make sure that they aren't lost. Or perhaps using email or other channel to reset them Keybase could probably be an excellent tool to manage such key. This is still a tad raw, and somehow user experience isn't factored in. We have a very powerful computer with fingerprint recognition in our pockets, why do we still need to type in passwords? (think WhatsApp web login)
- jeswin 9y ago
  User experience hasn't been factored in and tooling is key here. Tooling could (perhaps) be such that the user would never need to see the key pairs; tooling would manage them. That everyone always has a mobile phone in their pocket is a big opportunity; it could hold gatekeeper software that's with you wherever you are. > What happens when/if your private key is compromised? We'd need to revoke the keys and that would be hard to do manually. But with tooling, eventually easier than logging on to a website and changing passwords.
borplk 9y ago
Also see SQRL: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm A ton of work has already been poured into it. In particular around the area of "user convenience" features (recovery, reset, forgot/lost, low friction day-to-day usage, etc) and preventing phishing and MITM attacks.
- jeswin 9y ago
  This is an excellent effort. Let me see what I can learn from it. Thanks for the link.
timvdalen 9y ago
This looks really interesting, but I'm wondering how you came up with the spec for the command language. It seems a bit arbitrary and since this meant to be used in a machine-to-machine context and for security, wouldn't a binary protocol make more sense (which would get you smaller transfer size and resistance all sorts of string-based terminator attacks)?
- jeswin 9y ago
  I was aiming for the command to be human readable and easy to parse. Transfer size isn't a major concern imho since commands will be very short in length. But I admit I haven't thought very much about how it could be attacked. Do you see potential holes here? The syntax is: {command} with key1=val1, key2=val2, key3=val3;{signature}
  - timvdalen 9y ago
    I don't see anything obvious, but a string-delimited system is more vulnerable in general (especially if the spec grows). Consider for instance that the escaping of comma's wouldn't be necessary in a binary protocol.
danielblazevski 9y ago
The multiple device part seems tricky to improve on. I don't see how this approach can be tweaked to make it easy for non-technical people to access on multiple devices. It seems like you have to define a new device on a existing logged in device before using the new device. Is there a way around that? If I want to log into an app for the first time at work and forgot to define a new device name at home where I already can log in, I wouldn't be able to do so from what I understand.

13 points by jeswin 9y ago

Hi! I wanted to check out the browser extension that is mentioned, but the site is returning 404. Mostly, I wanted to find out whether the extension is using WebCrypto for the key generation, signing, verification, etc, and how the private key is being stored. Can you please elaborate on this?

jeswin 9y ago
As I mentioned on the top, it isn't ready yet. I just wanted to put a spec out there for discussion. I also wanted to take ideas on implementation, such as what you just provided. I'll keep you posted on progress, if your email is in your profile. Hoping to have everything (plug-in and serverside examples) ready in a week or two.
- skibz 9y ago
  Sorry, I missed that. I love the idea. It reminds me of something I read on HN a few years back where somebody proposed using SSH auth for web authentication.
- skibz 9y ago
  Also, forgot to mention: If you were to use WebCrypto, it ought to be possible to securely (with respect to cross-origin policy) store a user's private key using IndexedDB.
  - jeswin 9y ago
    Being able to transfer private keys between devices owned by a user might be a necessary feature. Otherwise accounts will be tied to a single device. Not sure what would be a good way to do this though.
    - skibz 9y ago
      Absolutely, yeah. WebCrypto has support for keypairs that can have the private key data extracted (there are limits, though, which I cannot accurately remember) from the JavaScript object in which they are contained. So it ought to be possible to extract the key data, encrypt it (also using WebCrypto) and sync it (somehow) to another device.
    - joantune 9y ago
      Keybase had something for that if I'm not mistaken
  - jeswin 9y ago
    The other option will be to generate a new key pair on the new device, and then add the public key to an account via an already registered key. Add key for <user@website> at <utcmillisecs>: <new_public_key_goes_here>;<sign>
    - jeswin 9y ago
      Or maybe just do it with a UI, after logging in with the original key. However, That would restrict the user to adding new devices only from trusted machines. Again, having a command ("Add key ..." as in parent message) for this would make this feature accessible to password/key managers.

jimnotgym 9y ago

I am always interested in proposals for getting rid of passwords. However I am not smart enough to review the technology without the domain experts on HN breaking it down for me

NuSkooler 9y ago

This sounds interesting... Integration with the major password managers would help adoption I'd think.

fiatjaf 9y ago

Nice, but where do you keep your private key? Why storing and syncing a private key or multiple private keys is better than storing and syncing a complex password or multiple complex passwords?

jeswin 9y ago
Syncing private keys seems like a somewhat risky thing to do. I'm leaning towards generating a new key and something like this: Add key for <user@website> at <utcmillisecs>: <new_public_key_goes_here>;<sign_with_current> Also see: https://news.ycombinator.com/item?id=15943546 https://news.ycombinator.com/item?id=15943546

fiatjaf 9y ago

I have another suggestion: keep a public database of linked accounts: someone@gmail.com == someone@twitter == someone@keybase. Let people append to their set of linked accounts only if they prove to control at least one of the accounts in the set plus the account being added. How do you prove you control something? I don't know.

niftich 9y ago
You mention Keybase as one of those accounts, but isn't this one of the goals of Keybase? See: https://keybase.io/docs/command_line https://keybase.io/docs/command_line
- fiatjaf 9y ago
  No, Keybase uses these social network proofs to verify the ownership of the public key so you can encrypt messages to it, like what a "web of trust" would do in traditional public key directories. Since they need public proofs, email will not be supported, for example. Also, they're very slow[1] in adding more providers, or perhaps they don't want more providers. But yes, I think the database Keybase is building can be used for a login system somehow. [1]: https://github.com/keybase/keybase-issues/issues/518 https://github.com/keybase/keybase-issues/issues/518

joantune 9y ago

A couple of things: What happens when/if your private key is compromised? All accesses will be compromised All accesses need to be rekeyed Some factor that's unique to the service would help to minimize this, something of an unique extension to the public/private key, something like two keys for the service, the general one and the other one (this is something other than your password, so the server would still need no password) Tooling is key . Not only being able to manage all those public/private keys but also backing them up and make sure that they aren't lost. Or perhaps using email or other channel to reset them Keybase could probably be an excellent tool to manage such key. This is still a tad raw, and somehow user experience isn't factored in. We have a very powerful computer with fingerprint recognition in our pockets, why do we still need to type in passwords? (think WhatsApp web login)

jeswin 9y ago
User experience hasn't been factored in and tooling is key here. Tooling could (perhaps) be such that the user would never need to see the key pairs; tooling would manage them. That everyone always has a mobile phone in their pocket is a big opportunity; it could hold gatekeeper software that's with you wherever you are. > What happens when/if your private key is compromised? We'd need to revoke the keys and that would be hard to do manually. But with tooling, eventually easier than logging on to a website and changing passwords.

borplk 9y ago

Also see SQRL: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm A ton of work has already been poured into it. In particular around the area of "user convenience" features (recovery, reset, forgot/lost, low friction day-to-day usage, etc) and preventing phishing and MITM attacks.

jeswin 9y ago
This is an excellent effort. Let me see what I can learn from it. Thanks for the link.

timvdalen 9y ago

This looks really interesting, but I'm wondering how you came up with the spec for the command language. It seems a bit arbitrary and since this meant to be used in a machine-to-machine context and for security, wouldn't a binary protocol make more sense (which would get you smaller transfer size and resistance all sorts of string-based terminator attacks)?

jeswin 9y ago
I was aiming for the command to be human readable and easy to parse. Transfer size isn't a major concern imho since commands will be very short in length. But I admit I haven't thought very much about how it could be attacked. Do you see potential holes here? The syntax is: {command} with key1=val1, key2=val2, key3=val3;{signature}
- timvdalen 9y ago
  I don't see anything obvious, but a string-delimited system is more vulnerable in general (especially if the spec grows). Consider for instance that the escaping of comma's wouldn't be necessary in a binary protocol.

danielblazevski 9y ago

The multiple device part seems tricky to improve on. I don't see how this approach can be tweaked to make it easy for non-technical people to access on multiple devices. It seems like you have to define a new device on a existing logged in device before using the new device. Is there a way around that? If I want to log into an app for the first time at work and forgot to define a new device name at home where I already can log in, I wouldn't be able to do so from what I understand.