Error running get totp

sam.doran
sam.doran
Community Member
in CLI

When running op get totp <uuid or name> I get the following error:

[LOG] 2018/03/06 14:38:42 (ERROR) Decoding of secret as base32 failed.

Has anyone else had this problem? This is the first time I've tried to get my TOTP from the command line, so I'm not sure if this was ever working for me. I am able to list and get other items, just no luck with op get totp.

Environment info:



1Password Version: 6.8.6
Extension Version: 4.6.12
OS Version: 10.13.3
Sync Type: Not Provided
Referrer: forum-search:(ERROR) Decoding of secret as base32 failed.

Comments

  • sam.doran
    sam.doran
    Community Member
    edited March 2018

    It seems this only happens with certain TOTP items, but not all of them.

  • sam.doran
    sam.doran
    Community Member

    I tested twelve logins with OTPs and eight of them work while four do not. The ones that do work have secrets that are 16, 32, or 64 characters in length.

    The four that do not work have secrets that are 26, 52, and 103 characters in length. Here are some examples with the secrets sanitized:

    otpauth://totp/Hover%3AHover?secret=XXXXXXXXXXXXXXXXXXXXXXXXXX
otpauth://totp/Amazon%3AXXXXXXXXX%40XXXXXXX.com?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&issuer=Amazon
otpauth://totp/Dropbox?secret=XXXXXXXXXXXXXXXXXXXXXXXXXX
  • rickfillion
    rickfillion

    Hrm... I wonder what's going on there. I've filed issue #369 in our bug tracker with those examples so that we can try to reproduce that on our end and figure out what's going on.

    Thanks for reporting this.

    Rick

  • sam.doran
    sam.doran
    Community Member

    Please let me know if you need any other info for troubleshooting. Thanks for opening an issue!

  • rickfillion
    rickfillion

    You're welcome. We're a little busy with some other projects at the moment so we haven't been able to look into this yet.

    Rick

  • rickfillion
    rickfillion

    Hi @sam.doran,

    Looks like those secrets you have aren't a multiple of 8 and we needed to add padding before trying to use Go's base32 decoder on them. We'll get that fixed.

    Rick

  • sam.doran
    sam.doran
    Community Member

    Woot! Thanks for figuring it out!

  • rickfillion
    rickfillion

    You're welcome. I'm glad it ended up being something simple like that.

    Rick

  • sam.doran
    sam.doran
    Community Member

    Just wanted to follow up and say this is now fixed in op version 0.4. Thank you so much!

  • rickfillion
    rickfillion

    That's great to hear. Don't hesitate to send more issues our way.

    Rick

  • sam.doran
    sam.doran
    Community Member

    I just discovered that one of my TOPTs doesn't get processed correctly. I've narrowed it down to the op command line tool not processing SHA256 or SHA512 TOTP properly. If I change the TOPT to use SHA1, I get the proper number back.

    The command line tools does will an OTP for SHA256/512, but it's the incorrect number and it does not match what is displayed in the 1Password app.

    Example data:

    # sha1, works properly
otpauth://totp/TOTPXXXXXXXX?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30

# sha256, returns incorrect number
otpauth://totp/TOTPXXXXXXXX?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30&algorithm=SHA256

# sha512, returns incorrect number
otpauth://totp/TOTPXXXXXXXX?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30&algorithm=SHA512
  • rickfillion
    rickfillion

    @sam.doran,

    Can you try "alg" instead of "algorithm"? I believe that's the proper way of doing that.

    Rick

  • sam.doran
    sam.doran
    Community Member

    I tried with alg and it still returns a different number than is displayed in the app.

  • rickfillion
    rickfillion

    I assume you're comparing the value between op and 1Password for Mac or 1Password.com? Looks like op is doing it wrong and expecting alg there and the other apps (those 2) look for algorithm. Consistency is hard.

    Rick

  • rickfillion
    rickfillion

    I've been able to reproduce this by creating two items with TOTPs:

    TOTPSHA512:

    otpauth://totp/TOTPXXXXXXXX?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30&algorithm=SHA512

    TOTPSHA512Alg:

    otpauth://totp/TOTPXXXXXXXX?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30&alg=SHA512

    When I run ./op get totp TOTPSHA512Alg, I get the result from TOTPSHA512 (on Mac). Which makes sense as the Mac is correctly setting the algorithm for that one, and I need the switched query parameter name on op to make it behave.

    We'll get this fixed up.

    You sir have the most varied OTP secrets I've ever seen. :)

    Rick

  • rickfillion
    rickfillion

    I've filed this in our tracker as issue 413.

    Rick

  • sam.doran
    sam.doran
    Community Member

    I assume you're comparing the value between op and 1Password for Mac or 1Password.com?

    Yes, that is correct.

    You sir have the most varied OTP secrets I've ever seen.

    I hope I'm not causing too much trouble. I do love 1Password and use it a lot. For everything. And I also am probably one of the only people who goes into the advanced TOPT options to pick the strongest cipher I can get. What can I say? I appreciate strong crypto. 8-)

    I did some more testing and it seems like op is calculating as if no algorithm was specified, and falling back to SHA1 (truncating the secret). I think that lines up with your findings. If I change algorith to alg, it's correct in op but incorrect in the apps. ¯_(ツ)_/¯

    In the following screen shot, for no algorithm I removed &algorithm=SHAXXX, for alg I changed &algorithm=SHAXXX to &alg=SHAXXX, and for algorithm I left it as it was generated originally.

    Thank you again for your help with this. I'm really getting a lot of use out of op and I'm looking forward to using it much more extensively in Ansible.

  • rickfillion
    rickfillion

    I hope I'm not causing too much trouble. I do love 1Password and use it a lot.

    No trouble at all. I was just poking fun. :)

    We've fixed the issue and it will be in the next release.

    Rick

  • sam.doran
    sam.doran
    Community Member

    That's awesome! Thank you so very much. I truly appreciate it.

  • AGAlumB
    AGAlumB
    1Password Alumni

    Likewise, thanks for bringing this up! Proverbial needle in the hashstack. ;)

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    Oh. I think I know what is wrong. I'll go and look at that issue that @rickfillion filed.

    I remember looking at this when we first spec'ed out TOTP internally. The problem, as I recall, is that Google Authenticator silently ignores the algorithm and always uses SHA1. So the world is stuck with a references (and widely deployed) implementation behaving differently than the specification. Some implementations follows Google Authenticators practice and others follow the spec, and everyone is confused.

    It appears that we picked one way (I can't recall which) in one place and another way in another place.

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    Oh. Never mind. It was a much simpler bug. (I really should have looked at our internal tracking before commenting).

    There still is the general problem that I described with Google Authenticator silently ignoring the algorithm. As a consequence a number of services create SHA1-based codes instead of SHA256.

  • rickfillion
    rickfillion

    You're welcome. We're a little busy with some other projects at the moment so we haven't been able to look into this yet.

    Rick

This discussion has been closed.