Forum Discussion

clesan201305_11's avatar
clesan201305_11
Icon for Nimbostratus rankNimbostratus
Oct 27, 2014

Google Authenticator iRule Verification

Hi,

 

I've been following this article: https://devcentral.f5.com/articles/two-factor-authentication-with-google-authenticator-and-apm

 

To implement two-factor authentication with APM. After creating an access policy, data group and all the likes, I find that the APM is expecting a different code than the authenticator shows. I found out by printing the variables that I enter as a code, and the variables that the APM expects as a code, into the logs. The whole process itself works. The iRule is triggered, the username is found in the datagroup, and the calculations are made. It's just expecting a different code. For example, my code will say "781023", and the BIGIP will be expecting code "826015". I tested this with multiple different accounts and the same results all around. I'm wondering if Google just changed its algorithm a few years ago and the article became outdated, or if something in recent F5 versions has changed that changes the calculation algorithm. Has anyone done a recent implementation with this iRule without any issues? I quadruple-checked everything and added log entries to every part of the iRule. I know it's being triggered correctly, but it's just coming up with a different expected code than Google is.

 

In that article, there are 2 comments by people with the same issue on 11.5, so at least I'm not alone :-)

 

application delivery
BIG-IP Access Policy Manager (APM)
design
devops
google authenticator
iRules
security

9 Replies

Sort By
  • Binh_Luong_1782's avatar
    Binh_Luong_1782
    Icon for Nimbostratus rankNimbostratus
    Mar 03, 2015

    We have the same issue since we upgraded to 11.6 from 11.3. Each time we load the config we see: "/Common/Google_SoftToken_Generator_V3:33: warning: [use curly braces to avoid double substitution]" Maybe that's the reason the code calculation is different. We couldn't figure it out how to fix the code. So we just move Google Authenticator to another F5 box which is still on 11.3. I hope someone can look into the GA code and make it work for 11.6 otherwise we have to stop using it.

     

    My two cents.

     

  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus
    Mar 04, 2015

    The error could be caused by the slight difference between the way 11.3 and 11.6 parse Tcl.

    In my experience it's usually due to the use of the 

    expr
    command. Here's how I fixed one of the offending lines:

    Before:

    HTTP::respond 301 Location "http://www.domain.org/blog/$DstPath/[expr ([string length [HTTP::query]]>0)?"?[HTTP::query]":""]"

    After (note the added curly braces):

    HTTP::respond 301 Location "http://www.domain.org/blog/$DstPath/[expr {([string length [HTTP::query]]>0)?"?[HTTP::query]":""}]"
  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus
    Mar 04, 2015

    Here's another example:

    Before:

    set cookie_expire_date [clock format [expr [clock seconds] + $cookie_expire] -format "%a, %d-%b-%Y %H:%M:%S GMT" -gmt true]

    After:

    set cookie_expire_date [clock format [expr {[clock seconds] + $cookie_expire}] -format "%a, %d-%b-%Y %H:%M:%S GMT" -gmt true]
  • Binh_Luong_1782's avatar
    Binh_Luong_1782
    Icon for Nimbostratus rankNimbostratus
    Mar 06, 2015

    Hi Arie,

     

    No luck. I fixed all the expr with curly braces. But the F5 is expecting a different code than my Google code on the iPhone.

     

    Binh

     

    • Arie's avatar
      Arie
      Icon for Altostratus rankAltostratus
      Mar 06, 2015
      Are you still seeing the errors when you verify the config?
  • Binh_Luong_1782's avatar
    Binh_Luong_1782
    Icon for Nimbostratus rankNimbostratus
    Mar 06, 2015

    Nope, no more errors using the curly braces. But the Google code is still wrong. As I don't know the logic of the calculations, so not sure if the curly braces are correct are not.

     

  • Sam_Hall's avatar
    Sam_Hall
    Icon for Nimbostratus rankNimbostratus
    Mar 31, 2017

    I know this thread is old, but I just went through the same process trying to get the otp iRule working as normal without warnings.

    The problematic expr statements contain string concatenation used to generate hex values for bitwise operations. It wont work as expected if you simply wrap that in curly brackets, so I just break it up a little. For example this becomes this...

      set o [expr 0x$k ^ 0x5C ]
  set i [expr 0x$k ^ 0x36 ]

      set kh 0x$k
  set o [expr {$kh ^ 0x5C} ]
  set i [expr {$kh ^ 0x36} ]