Add support for OTP URIs

[robinkrahl]

Google Authenticator introduced the otpauth URI scheme to share OTP data (secret, OTP algorithm, HOTP counter, TOTP time window, issuer, …). A minimal example:

otpauth:https://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP

A complete example:

otpauth:https://totp/ACME%20Co:[email protected]?secret=HXDMVJECJJWSRB3HWIZR4IFUGFTMXBOZ&issuer=ACME%20Co&algorithm=SHA1&digits=6&period=30

We could implement this as:

• an extension (Discussion: Advanced functionality #50)
• a new otp subcommand (otp set-url)
• a new input format for the secret for the otp set subcommand (i. .e nitrocli otp set 1 acme "otpauth:https://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP" --format url)

I prefer option 3. The downside is that the user always has to set a name and cannot reuse the label or issuer from the URL, but as we have a very short character limit for the name, that’s probably the better solution anyway. Also, we might need a dependency for URL parsing, but I think that’s acceptable.

[d-e-s-o]

Thanks for bringing this up, Robin. Does support for this feature have priority for you? While I am not opposed to options two or three but, if possible, my suggestion would be to postpone the decision until we have a better idea of the extension mechanism and can evaluate possible implementation choices in light of it.

[robinkrahl]

Yeah, we can wait with implementing this.

[robinkrahl]

As we now have extension support, we should have another look at this issue. If we go for an extension I suggest this syntax: add-otp-url URL [--slot SLOT] [--name NAME].

[d-e-s-o]

Yeah, I think given the way extension look, this should fit in nicely. And conceptually it should be rare enough a feature that not including it in the main application makes more sense. The only suggestion I have is naming it otp-add-url (or otp-url-add). I think that may improve discoverability because things in the OTP realm are easier recognizable when they all start with otp.

[d-e-s-o]

Do you still have a use for this, @robinkrahl and would be interested to prototype? The truth is, I am not eager to implement stuff that I don't use (but open to including it), and I have never encountered such URLs in the wild (not saying they don't exist, just that I am not frequenting services that use them); so I don't see myself implementing such support.

[robinkrahl]

While raw OTP URIs are indeed rarely used, OTP QR codes are quite common and also use this URI format internally. (I think both GitHub and Gitlab use them, for instance.) So yes, I’m still interested in this feature.

There is an old prototype, nitrocli-otp-qr, that 1) takes a screenshot with imagemagick, 2) parses the QR code with zbarimg, 3) parses the URL and 4) calls nitrocli, but transforming that into a PR is not a top priority for me at the moment.