secret with spaces are not encoded properly

[jrbalderrama]

Services like gitlab or firefox provides the secret key in the format "XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX" (group of chars separated by spaces). Currently, the pass-otp does not support this kind of key because it is not possible to insert a URI with spaces. Nevertheless, that key format is compatible with oathtool if you provide it between quotation marks:

$ oathtool -b --totp=SHA1 "XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX"

A solution might be to encode the URI replacing the spaces with %20 and decode the key before processing internally on pass-otp. In order to accomplish the code generation, the oathtool execution must encapsulate the decode key between the quotes.

[kousu]

I ran into this too by using append -s. The site I was using gave me a QR to scan and a secret to copy-paste like "bhjc xibb t32y t5ba oqar p57g je". This is pretty common across sites. Not thinking, I pasted it right in:

$ pass otp append -i site -s onlineservice.com
Enter secret for onlineservice.com: 
Retype secret for onlineservice.com: 
[master 21f148a8] Append OTP secret for onlineservice.com.
 1 file changed, 0 insertions(+), 0 deletions(-)
$ pass otp onlineservice.com 
152538

I spent a while before I realized the reason the code wasn't working was simply that the underlying secret was too short.

It'd be nice if there was some normalization on the otpauth:// URIs whenever they were edited. Spaces should be safe to remove, it should be safe to lowercase the whole thing, and maybe could the length be checked to be within some expected limits?