Jump to content

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


Recommended Posts

  • 9 months later...
  • 8 months later...

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]

2018-04-28_22-33-47.496.png

 

 

Thank you!

error-message.png

Edited by Rodion
added screenshot
Link to comment
  • 1 month later...

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 by Acidham
Link to comment
  • 1 year later...
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 by TomekB
Link to comment
  • 1 month later...
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 by glawrie
Typo correction
Link to comment
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 by glawrie
Sort out formatting
Link to comment
  • 3 weeks later...
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 by TomekB
Link to comment
  • 1 year later...

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?

Link to comment

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 by glawrie
Formatting!
Link to comment

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... )

 

Link to comment

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.

Link to comment
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.

Link to comment

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


 

Link to comment
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?

Link to comment
18 minutes ago, Acidham said:

iterm2


image.thumb.png.39806ee8f5c3b70a64d4bd6abb8a805e.png

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 by m4Aark
Link to comment
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.

Link to comment

@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?

Link to comment
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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...