Improvements to key sharing

[conradludgate]

Logging in on a new device is currently a bit awkward. You have to somehow get your encryption key from one device to the other.

You could store the key in a password manager (which does seem like the best option to promote)

Tangent...

Putting the key next to your password can be a security risk, although usually if they have your password manager, you have bigger worries. But anyway, maybe we could switch to a PBKDF? - this does reduce security considerably though if you have crap passwords, or someone cracks your password from the DB hash.

Another alternative for users without PMs could be some kind of LAN HTTP server that can acts as a share mechanism.

Scenario: Device 1 is logged in to the sync server, Device 2 is not.

Device 2:

$ atuin login --remote # feel free to bikeshed

Setting up remote login
From the device, run
atuin login --remote 192.168.1.123:8723 123456

This sets up a HTTP server listening on a random port, and shares a OTP.

Device 1 then the displayed command

$ atuin login --remote 192.168.1.123:8723 123456

This will make a HTTP request to that host

GET /

HTTP/1.0 200 OK

123456

Device 1 will confirm that the responded code matches the one provided on the CLI. This confirms that the connection is most likely correct.

Security...

We probably want some encryption for this communications, although it should be secure over LAN... I don't think TLS would work to solve MITM attacks since there is no CA to confirm the certs. Maybe the OTP could act as part of a DH exchange. This is probably over-engineering this though

Device 1 will then follow up by sending the username and key through that API.

Now that Device 2 has this data, it will prompt the user for their password to complete the login.

[ellie]

Yeah this definitely needs improving! I chose not to solve this problem earlier on 😂

I think we can get at least some of the way by making the key type-able and more memorable. Right now if you try and type the output of atuin key, you're not going to get anywhere. I think if we do something similar to bip39, we'd at least reduce the difficulty here.

I'm also wondering how many of our users are on a lan often, vs an install on their laptop, a VPS, work computer, etc etc.

[conradludgate]

Transfer to VPS seems easy enough through SSH. My flow was thinking of a work laptop brought home, next to their personal workstation.

Textual keys would definitely help though, if they need to be written down on paper and taken elsewhere

[ellie]

Transfer to VPS seems easy enough through SSH

True...

if they need to be written down on paper and taken elsewhere

I was thinking less in terms of writing down on paper, and actually for the case where laptops are next to each other. It's pretty trivial to copy something like

witch collapse practice feed shame open despair creek road again ice least

from one laptop to another, just via reading and typing

But obviously what we have right now is significantly harder

It'd probably get us 80% of the way there, for 20% of the effort, and also has minimal chance of us accidentally introducing a security issue

[conradludgate]

The mnemonics are not backwards compatible, however. So we will need to know the 'key encoding' used on file going forward.

But overall I'm happy with this for now

[ellie]

We can leave the files as they are, and use mneumonics purely as a frontend for them - then we don't need to worry about changing or updating files, and it's just a new input + display method

[beeb]

If using something like bip39, would the encryption key be derived from the mnemonic, or would the mnemonic be derived from the encryption key (which would then represent the entropy)? I'm thinking how to print the mnemonic when the user calls atuin key. The only way to retrieve a mnemonic is from the random entropy that was used initially to generate the mnemonic.

But the docs state:

Note: You shouldn’t use the generated entropy as secrets, for that generate a new Seed from the Mnemonic.

Which would require the mnemonic to be stored locally instead of the encryption key (which would then be generated from the mnemonic)

[conradludgate]

From looking at the code, our keys are 32 bytes, and tiny_bip39 supports 32byte entropy to be used as 24 word formats. So we could potentially use our existing key generation and use bip39 as a front end

[conradludgate]

Just tested it, adding bip39::Mnemonic::from_entropy(&key.0, Language::English) to the code, and I do indeed have a nice 24 word phrase!