Show HN: NullAuth – A proposal for password-less authentication | Hacker News Reader

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

nullauth.org

13 pointsjeswin24 comments

Also see SQRL: 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.

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

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)

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.

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?

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

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.

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

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

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.

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

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

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}

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.

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

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?

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.

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.

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.

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.

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.

Keybase had something for that if I'm not mistaken

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>

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.

Reply on news.ycombinator.com