On Tue, Feb 14, 2017 at 7:21 PM, Thomas Harning Jr. <[email protected]> wrote: > Awesome enhancement! One suggestion that I have would be the ability > to store the OTP in the URI format (ex: > https://github.com/google/google-authenticator/wiki/Key-Uri-Format ) > ... although looking deeper, I cannot seem to find any other > references that use it. > > The nice bit about the key URI format is that it bundles all the OTP > details in an optional way with defined defaults and helps keep all > the OTP details in one place.
That makes a lot of sense. In fact, it should be trivial to append an otpauth:// URI to any existing password entry, and to simply match the first occurrence of such a URL when decoding. > I envision that if the parameter format was standardized well, this > would be a very useful addition to the mobile phone implementations - > perhaps with a setup where the password was stored AND the OTP > generator with the option to capture the OTP URI at import / edit time > (although this is well beyond the scope of this pass extension). If we store plain URIs, then I'd imagine the standard "pass insert" functionality would suffice. > If I find time, I'll try to track down a useful URI decoder mechanism for > bash, This is the main rub. If people blindly insert something decoded from a QR image, for example, decoding could be vulnerable to script injection. Although it could be useful to display a warning prompt on insert (which would require one to use the extension to insert OTP URIs). Anyway, I've found this URI parser for Bash: http://wp.vpalos.com/537/uri-parsing-using-bash-built-in-features/ Does this look reasonable? I can change the extension now, which is probably a good idea before too many users insert OTP secrets in the old format. _______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
