
Show HN: NullAuth – A proposal for password-less authentication - jeswin
https://www.nullauth.org/
======
borplk
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
This is an excellent effort. Let me see what I can learn from it. Thanks for
the link.

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

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

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

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

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

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

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

