Gauth: Google Authenticator (Time-Based Two-Factor Authentication)

[jhnielson]

Great workflow.  Is there anyway to change the directory it uses for the .gauth file?  I would like to save it in the workflow folder so that it would stay synced across my computers.

 

Thanks!

[Acidham]

Suggestion: The SECRET is stored in plain text file what about to get SECRET from Keychain? I am not experienced in Python but google tells me that there are methods which read and write to keychain. 

[Rodion]

Hi, guys

 

I've got a question.

After installing and configuring this workflow sometimes I bump into such a problem

as some of OTP secret keys are considered invalid.

 

For example, OTP keys from GitHub, Bitbucket are working flawlessly but all the secret keys which have

approximately the same structure (eg. 6hpoq5olymscq4coy74iccod or 2didz2zrh3smhnutnvwfdvgg) are invalid though Google Authenticator,

SAASPASS https://saaspass.com/ and Authy read them with no problem.

 

Is there a workaround how to fix it?

 

Here are the steps for bug reproduction:

1) go to Alfred

2) type - gauth add surf, 6hpoq5olymscq4coy74iccod

https://www.screencast.com/t/FrLhVqqPt15

Result:

- invalid secret key

https://www.screencast.com/t/HShM3NDTQCt6

Screenshot from debugger 

My system: macOS High Sierra Version 10.13.4

Alfred v3.6.1 [910]

 

 

Thank you!

Edited April 28, 2018 by Rodion
added screenshot

[Acidham]

I am experiencing the same with Amazon Secret Key. Even if I add it to .gauth it will not show up in gauth for alfred

 

The key from Amazon looks like this: AC5B WYRK YWRK NSBU C42A 6IR2 BSGF YMMC BYUZ LLS2 B2GE IQ2Z RP4B

Edited June 6, 2018 by Acidham

[TomekB]

On 6/6/2018 at 10:28 AM, Acidham said:

I am experiencing the same with Amazon Secret Key. Even if I add it to .gauth it will not show up in gauth for alfred

 

The key from Amazon looks like this: AC5B WYRK YWRK NSBU C42A 6IR2 BSGF YMMC BYUZ LLS2 B2GE IQ2Z RP4B

 

I have fixed that by replacing key decoding in two places in gauth.py

 

        key = base64.b32decode(secret[0:8], casefold=True)
        key = key + base64.b32decode(secret[8:16], casefold=True)
        key = key + base64.b32decode(secret[16:24], casefold=True)
        key = key + base64.b32decode(secret[24:32], casefold=True)
        key = key + base64.b32decode(secret[32:40], casefold=True)
        key = key + base64.b32decode(secret[40:48], casefold=True)
        key = key + base64.b32decode(secret[48:56], casefold=True)
        key = key + base64.b32decode(secret[56:64], casefold=True)

As longer key seems to be not supported by b32decode.

Edited May 5, 2020 by TomekB

[glawrie]

On 3/28/2020 at 6:47 PM, TomekB said:

 

I have fixed that by replacing key decoding in two places in gauth.py

 

        key = base64.b32decode(secret[0:8], casefold=True)
        key = key + base64.b32decode(secret[8:16], casefold=True)
        key = key + base64.b32decode(secret[16:24], casefold=True)
        key = key + base64.b32decode(secret[24:32], casefold=True)
        key = key + base64.b32decode(secret[32:40], casefold=True)
        key = key + base64.b32decode(secret[40:48], casefold=True)
        key = key + base64.b32decode(secret[48:56], casefold=True)
        key = key + base64.b32decode(secret[56:64], casefold=True)

As longer key seems to be not supported by b32decode.

 

Thanks for posting.  Have tried to get this to work, but even after pasting in the alternative code I still cannot get Amazon OTP secret to be recognised.  If I add the amazon code that works in other OTP solutions direct ~/.gauth the amazon entry does not show up, if I try to add via Alfred (the Gauth Add thing) the workflow reports an error in the format of the submission.

Any ideas?

Edited May 15, 2020 by glawrie
Typo correction

[glawrie]

36 minutes ago, glawrie said:

Any ideas?

Sort of wondering about the line 62 in gauth.py

secret = secret.ljust(int(math.ceil(len(secret) / 16.0) * 16), '=')

The secret I'm getting from Amazon (that works in other authenticators) is 52 chars long - which means that secret after this step has 12 `=` symbols at the end - maybe this not playing nicely with your staged processing of the key (as the final step in the revised approach receives '========' as the input in the amazon case).

Or maybe it is OK... but regardless, if anyone has thoughts on how this might be fixed I'd value the input.

Edited May 15, 2020 by glawrie
Sort out formatting

[TomekB]

On 5/15/2020 at 1:16 PM, glawrie said:

Sort of wondering about the line 62 in gauth.py

secret = secret.ljust(int(math.ceil(len(secret) / 16.0) * 16), '=')

The secret I'm getting from Amazon (that works in other authenticators) is 52 chars long - which means that secret after this step has 12 `=` symbols at the end - maybe this not playing nicely with your staged processing of the key (as the final step in the revised approach receives '========' as the input in the amazon case).

Or maybe it is OK... but regardless, if anyone has thoughts on how this might be fixed I'd value the input.

 

Ignore the fix I posted above it's not relevant. The issue was caused by secret which were not multiple of 8. So the actual fix is to replace `16.0` and `8` in the line you posted to `8.0` and `8`

 

secret = secret.ljust(int(math.ceil(len(secret) / 8.0) * 8), '=')

This will fix the padding for the keys which length is not a multiple of 8, such as Amazon.

 

With 16.0 and 16 the script was adding too many "=" to the secret which was causing an error with b32decode.

Edited July 6, 2020 by TomekB

[glawrie]

Gauth workflow has stopped working on my system following update to macOS (12.3). Have tried reinstalling the workflow but without success. Gauth add sort-of works - in that you are prompted for a new secret - but nothing happens if you then enter any data. Normal use of guath simply doesn't happen - the option appears in Alfred as you type Gauth... but when you hit space after the keyword you get bounced to entering text for search-engine search.

Using Alfred 4.6.4 [1293] - Gauth was working fine with this version before macOS update, so currently suspicion is that it is the macOS version that is behind issue.

 

Anyone got any insights? Anyone see the same issues?

[s3frank]

Yes I have the same issue since I upgraded. I think it is because Apple dropped Python v2 with that update and the workflow uses that.

I followed these steps and installed 2.7 again but it so far has not fixed the workflow for me 😞

 

https://www.alfredapp.com/help/kb/python-2-monterey/

 

I depend on this one a low in my workflow and would love it to get back to normal again.

[glawrie]

I did a bit of digging and turned on Alfred debugger: couple of issues

1. Some modifications are needed to the python scripts to work with Python 3
2. Alfred is reporting that it is not able to find python even though it is installed

I am not so good with Python and I have not tracked down all the issues between Python 2 and 3, but seems they are more complex than just runing 2to3 on the files.

For example line 20 of the file alfred.py

preferences = plistlib.readPlist('info.plist')

Needs to become

with open('info.plist','rb') as fp:
  preferences = plistlib.load(fp)

But to get beyond this requires getting Alfred to recognise that python is installed... not sure what modification is needed - on my system python is installed and typing `python gauth.py` into zsh triggers processing of the file via python - but the same from within Alfred fails.

If anyone has guidance on how to get Alfred to recognise that python is installed... that would be a helpful addition...

 

 

Edited March 16, 2022 by glawrie
Formatting!

[glawrie]

So one step forward, one back...

• Getting Alfred to find python is relatively painless, open the workflow in alfred workflow panel and click on the gauth Script Filter tile and change 'python' to 'python3', and then repeat this with the fourth of the 'run script' tiles in the second column.  On my system at least doing that gets Alfred actually running the python.
• Fixing the python scripts to run under python 3... haven't got that going yet.  Running 2to3 and fixing the file open lines simply push the fail to a later error.  Where I am currently is trying to work out what is causing this problem

• Quote

    File "gauth.py", line 198, in <module>
      main(action=alfred.args()[0], query=alfred.args()[1])

  which appears to be not passing meaningful information (so there is something wrong with the alfred.args values... )

 

[vitor]

@glawrie See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Google Authenticator Workflow.

Edited March 16, 2022 by vitor

[glawrie]

Hi @vitor - thanks for the heads up on this: will provide a good short-term fix.  Is there a wider reason why the effort is on maintaining Python2 rather than migrating the workflows to use Python3? From what little I have read it seems that moving to Python3 would be a better long term solution... but maybe I missed something.

[vitor]

1 minute ago, glawrie said:

From what little I have read it seems that moving to Python3 would be a better long term solution

 

It absolutely is.

 

1 minute ago, glawrie said:

Is there a wider reason why the effort is on maintaining Python2 rather than migrating the workflows to use Python3?

 

Plenty of them. Converting Workflows to Python 3 is considerably more work, thus takes way more time and requires a lot of testing just to reproduce what the Workflow did. Plus I dislike Python, so I don’t use it much and am not up-do-date with all the language features. Converting a ton of Workflows I don’t use from one language I dislike to another language I dislike wouldn’t be a pleasant or productive use of time. If I were to take on these conversions, there wouldn’t be time to do all the ones people are asking for. And even if there were, not all developers continue to be active to accept a pull request, meaning forking the Workflow and maintaining something I didn’t start. Disadvantages all around.

It’s way more beneficial and makes way more sense for me to cast a wide net and provide the stop gap solution for most things to work again in the short-term. That allows others (like yourself with this Workflow) the time to develop the long-term ports which will eventually replace the temporary fixes I’m posting. The GitHub repo is explicit:

 

Quote

It contains existing third-party Python 2 Workflows tweaked so you can keep using them until they are updated by their developers or you switch to an alternative.

 

The ideal scenario is one where that repo is no longer necessary. In the meantime, its existence eases the transition.

[dhahn]

With the latest MacOS 12.3 update, ~/.gauth file somehow disappeared, and I am not sure I can regain access to it.

[m4Aark]

For those having issues with Mac OS 12.3, its because apple have removed python 2. Follow the steps below to get it back working.

1) brew install pyenv
2) pyenv install 2.7.18
3) ln -s "${HOME}/.pyenv/versions/2.7.18/bin/python2.7" "${HOMEBREW_PREFIX}/bin/python"
4) install the updated alfred workflow with the link below

https://github.com/alfredapp/updated-third-party-python2-workflows/raw/main/Workflows/Google Authenticator.alfredworkflow


 

[Acidham]

i tried these steps but I don’t have permission to create symlink in /usr/bin due to Apple’s SIP.

[m4Aark]

4 minutes ago, Acidham said:

i tried these steps but I don’t have permission to create symlink in /usr/bin due to Apple’s SIP.

Are u using terminal or iterm2 to run the commands?

[Acidham]

iterm2

[m4Aark]

18 minutes ago, Acidham said:

iterm2

remember to give iterm2 full disk access, otherwise you will be encountering issues on the 3rd pointer that you do not have permission to create the symlink.

Edited March 27, 2022 by m4Aark

[Acidham]

 I mentioned it...it is not permitted due to Apple's SIP: 

ln: /usr/bin/python: Operation not permitted

 

Edited March 28, 2022 by Acidham

[vitor]

4 hours ago, Acidham said:

is not permitted due to Apple's SIP

You’re supposed to install the symlink in ${HOMEBREW_PREFIX}/bin/python, not /usr/bin/python.

 

@m4Aark correctly mentioned that above. Though they did not mention two important steps which may be necessary first: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and eval "$(brew shellenv)". These are all covered in the KB article.

[Acidham]

@vitor yep right but this installs symlink in /usr/local/bin but shebangs in python2 workflows are set to #!/usr/bin/env python which points to /usr/bin/python 

 

btw how can I format code lines in the forum here?

[vitor]

1 hour ago, Acidham said:

but shebangs in python2 workflows are set to #!/usr/bin/env python which points to /usr/bin/python

env points to whatever is in your environment; that’s the point of using it instead of a full path. It’s why export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" works, as I’ve explained. And that’s why these Workflows need tweaks. @m4Aark pointed you to the updated version, the instructions above are correct.

 

1 hour ago, Acidham said:

how can I format code lines in the forum here?

There’s no setting for it, I auto-stylise them via MarkdownTransform.