Aegis: Proposal for standard data exchange format

[StoyanDimitrov]

There is an ongoing initiative to standardize the backup format of several other OTP authenticators.

I suggest Aegis joins that movement.

[alexbakker]

Is this the standard you're referring to? It looks to me like the standardization has already occurred among a few people and other apps are just expected to implement it now.

We'll consider adding support for this. Import support is fine, but the export option will be hidden under advanced, because our users would lose some information about their tokens using this format and we also don't want to encourage plain text backups.

[StoyanDimitrov]

That's the one.

It looks to me like the standardization has already occurred among a few people and other apps are just expected to implement it now.

I guess you're right. Poor wording on my side.

We'll consider adding support for this. Import support is fine, but the export option will be hidden under advanced, because our users would lose some information about their tokens using this format and we also don't want to encourage plain text backups.

While limiting having a common exchange format is a good first step.

[michaelschattgen]

I really like the idea of having a common exchange format but I don't like the proposed format itself. I see it is being mentioned that having a json-style format is not user friendly and requires more effort/code for the developers.

Limiting a new standard because it requires more work or effort for the developers is not a good reason in my opinion. I also don't expect the average user to manually edit their exports that often and I just can't see how editing a long "One-otpauth-per-line" variant is more user friendly (thus more readable) than a nice formatted json file as mentioned here by @mymindstorm

Many open source two factor authentication apps already support importing from json file so it should not be a complete rewrite of their import functionality.

Even though it looks like the decision on this format is already made, I'm not a fan of it.

[mymindstorm]

To be completely honest I'm not really a fan either and agree with your points. The author's arguments don't really hold any water at all, but the other developer kinda stepped in and implemented it before I could say anything. Though that does not mean the standard has no merits.

I really like the idea of having a common exchange format but I don't like the proposed format itself. I see it is being mentioned that having a json-style format is not user friendly and requires more effort/code for the developers.

Using a JSON based standard would probably have been simpler for our TypeScript application. Importing with the standard is pretty easy as you can just copy and wrap your QR scanner's (or otpauth:// link handler's) parser in a loop. Exporting is a bit more complicated, but it isn't too much of a pain to implement.

User-friendliness is not a valid factor to use when developing an interface for other programs. Users should not be editing these files in most cases. (and a URI format isn't that user friendly in the first place)

We'll consider adding support for this. Import support is fine, but the export option will be hidden under advanced, because our users would lose some information about their tokens using this format and we also don't want to encourage plain text backups.

In our application we also encourage using an internal format for most backups to keep encryption. Unless there's a widely agreed upon method to encrypt secrets I'd like to keep everything a simple as possible. I.e. just raw secret data with no metadata. There should be no information loss that takes away necessary info from secrets.

[chiraag-nataraj]

Just to join the chorus here, it _does_ seem odd that the rationale against having a JSON format (with more metadata) was decided against. I agree with @alexbakker that export should be hidden/advanced. I'd even go further and have something like a "Transfer" item which pops up a nice big warning about how it's only suitable for transferring secrets to other apps and that it should not be used for backup. Only once the user hits "I understand" would the file be exported.

[mymindstorm]

Just want to add, y'all already have a parser for URIs:

https://developer.android.com/reference/android/net/Uri
https://docs.oracle.com/javase/7/docs/api/java/net/URI.html

[alexbakker]

Import support is as simple as reading all lines of a file and calling GoogleAuthInfo.parseUri on them. The rest can be handled by the import infrastructure that's already in place. This would be a good first feature for a new contributor to tackle, I'd say.

[mdmower]

This is a tad off-topic – I'm still very much in support of importing otpauth:// Key-Uri-Format! – but for others who land here because they are looking for a simple way to import their collection of secrets in otpauth:// format, here's a handy utility to reduce the pain: stefansundin/2fa-qr . That single index.html file can be run using a local web server disconnected from the net, or if you like to live life dangerously, the developer makes it available online: stefansundin.github.io/2fa-qr/ . To their credit, there are no network requests made when you edit that form (as of this writing).

In my case, I was migrating from the long neglected Authenticator Plus and this was the quickest route. Export backup from Authenticator Plus, decompress Accounts.txt from the encrypted zip, turn each otpauth:// line into a QR code, and scan with Aegis.

[jidanni]

All I can say (#348) is please add abilities:

• Import of a clear text file of one otpauth:// per line
• Export to a clear text file of one otpauth:// per line

Along with all the other Import / Export choices.

[jidanni]

Currently one must master Aegis's format as the only way to import keys from a file (and not from some other app, via root.)

[jidanni]

Anyway Aegis should show its commitment to freedom vs. consumer lock-ins, by supporting as many export and import methods from plain clear text files. The first of which should be _one optauth per line_ format.

[michaelschattgen]

We would like to ask you to try stay at 1 message at a time @jidanni. Our GitHub issues are cluttering up. And if you forgot to mention something, please edit your original message.

[alexbakker]

I think you can actually already import a file with otpauth:// URI's if you select WinAuth, as it uses the same format. We should add a separate import option for plain text URI files to make that more clear.

Also, while I think the vendor lock-in argument is a bit hyperbolic. there's some truth to it. Perhaps we can add a URI file export option as well, behind a bunch of "loss of information" and security warnings. However, the primary export format should remain Aegis' own format. What do you think, @michaelschattgen?

[jidanni]

There is no documentation on the format of those exports. One even worries if there will be a CRLF vs. LF conflict, etc.

[jidanni]

(One also notes the Aegis Vault's "algo" should be "algotithm"... at least on import and export...
See https://github.com/google/google-authenticator/wiki/Key-Uri-Format.)

[alexbakker]

(One also notes the Aegis Vault's "algo" should be "algotithm"... at least on import and export...
See https://github.com/google/google-authenticator/wiki/Key-Uri-Format.)

No it shouldn't. The format of Aegis' vault is not modeled after Google Authenticator's URI format.

[alexbakker]

Aegis can now import this "standard" format using the "Plain text" import option.