Radish alpha
h
rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
Radicle Heartwood Protocol & Stack
Radicle
Git
Add RAD_PASSPHRASE_FILE
Open did:key:z6MkfPoh...bGiY opened 10 months ago type=feature

It would be nice to be able to pass a file path for a passphrase, instead of injecting the passphrase directly into the environment. I’d be happy to implement a proof-of-concept patch if theres at least no blocking concerns. This would be a nice stop-gap to more complete authentication solutions. Any concerns?

z6MkgFq6...nBGz commented 9 months ago

Hey there, thanks for your contribution. Having this functionality in place would be very nice!

Did you start working on it already? There was someone else expressing interest on that matter: https://radicle.zulipchat.com/#narrow/channel/369873-support/topic/launchd.20and.20launchctl.20macOS.20plist/near/524507073

fintohaps commented 9 months ago

I’m wondering if there’s any other tools that also take this approach? It seems to me like it would make sense, but I’d like to look at any prior art.

z6MksSxJ...dYeW commented 9 months ago

Hi guys. I’m the guy who expressed interest in working on the issue. Cheers to @micro for letting me give it a shot.

To begin with, I know some Rust, but I admit that I’ve never contributed to an existing codebase before. So I’m being quite cautious, and I could use a bit of guidance. I’m not asking for any hand-holding, but I would appreciate any feedback on my thoughts concerning this feature:

For instance:

  1. When users first create an identity on the network, we could provide them with the option to create this file (call it “RAD_PASSPHRASE_BACKUP”) in a directory of their choosing, after which they would enter the passphrase. Should they choose to do this, we could offer them the further option to make reading from this file the default authentication method. In that case, the current methods would become fallbacks in case there’s something wrong with the file (see #4 and #5). A risk of making this the default authentication method, is that it may create a situation where certain users become so used to not having to enter their details that they forget their passphrases entirely. To address this, it may make sense to introduce a command that reveals the passphrase, but that is a security risk in itself.

  2. On one hand, it would make sense to encrypt the file by default, to prevent unauthorised access. The downside to this is that it could leave the user in a funny situation where they need to remember a password to access the original password.

  3. I don’t know what features currently exist that allow users to change their passphrases, but it would make sense for the contents of the proposed file to be altered automatically to reflect any changes. It would also make sense for the user to be required to enter their passphrase manually to authorise such changes. This would prevent a situation where an arbitrary individual can alter the contents of “RAD_PASSPHRASE_BACKUP” without the knowledge of the user, a possibility that highlights just how dangerous it would be to introduce a command that reveals the existing passphrase.

  4. Perhaps the file should be saved in a predetermined (and fixed) sub-directory of ~/.radicle. Allowing the user to save this in some other directory increases the risk of accidental deletion.

lorenz commented 6 months ago

Please see patches/cfbc8ab4edd0eddb24e56a7ce56a1a0f6d2d3d39 which implements something similar.