nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Secure Login initialization loop

Jochen Suckfüll

We are currently evaluating the Secure Login plugin (v1.2.2) on JIRA Server 7.1.1.

Most of the users are not able to confirm the initial PIN. Instead, right after entering the PIN and clicking the "Check PIN" button, they are again lead through the introductory popups and presented with a new QR image.

It seems as if the system is not accepting the PIN. We already verified that the system clock is synchronized, and the clock on the mobile device (with FreeOTP) is correct as well.

(We are testing the add-on for Confluence at the same time, and that works perfectly in that regard, with the same mobile device.)

The users who reported this have not been on that test system before, so this cannot be caused by old cached content or old cookies.

From the time when the user is presented a new QR code, an admin can see that a code is set for the user (by attempting to delete that code from the profile page), even before the user has entered a PIN for the first time.

However, the user's PIN is not accepted.

Is this a known issue?

Is there anything we can do to trace this down?

jira-log-securelogin-1.3-BETA.txt

jira-log-securelogin-1.3.1-BETA.txt

atlassian-jira.log

jira-log.txt

Accepted answers

Jochen Suckfüll

As explained in the comments around here, there are two options to circumvent this issue:

Option 1 requires the user to disable JavaScript temporarily:

Disable JavaScript before submitting the username/password form.
Then initialize the authenticator.
Then enable JavaScript again.

Option 2 requires no user action, but removes 2FA for the avatar images:

The admin configures the secure login path whitelist to include /secure/useravatar.

All comments

unknown

Hi Jochen,

I just downloaded atlassian-jira-software-7.1.1-jira-7.1.1.tar.gz, installed "2-Factor Auth (2FA) Secure Login - JIRA" version 1.2.2 through Atlassian Marketplace and tried to log in with a newly created user. First and following logins work as expected. I tried FreeOTP and Google Authenticator and both work fine.

You could try to enable debugging output for Secure Login through JIRA Administration. To enable debugging, please navigate to JIRA administration -> Logging and profiling -> Configure logging level for another package, enter following information into the input fields and click "Add"

Package Name: de.syracom.jira.plugins

Logging Level: DEBUG

Please try to log in again and check atlassian-jira.log afterwards.You can also send the full log to SecureLogin.JIRA@syracom.de for further analysis.

Best regards,

Alexander Straube

Alexander Kueken

Hi Jochen,

in addition to what my colleague Alexander Straube wrote: we just released version 1.2.2 today. Perhaps you can downgrade to 1.2.1 in order to see if it behaves differently. In both cases the best way would be, to activate the debug logging, as Alexander suggested, and provide us with the results, so we can take a better look into the issue and help you with it.

Best regards,
Alexander Küken

Jochen Suckfüll

Thanks for the quick response. I had tried version 1.2.1 before and actually upgraded to 1.2.2. hoping that this would fix it.

The current setup is based on a very old JIRA version (probably major version 4 or 5), that has been upgraded.

(We didn't start using the secure login before, because it didn't support resetting the user tokens either in Confluence or JIRA.)

I'll follow your suggestion and activate the debug logging now.

Jochen Suckfüll

The attached log excerpt contains the entries from the installation of the add-on, and the lines that were created when I tried to initialize the authentication with the user test_jochen. These seem to be the relevant lines:

user passed on qrcode form with status: true

pin could not be validated terminating session and redirecting user to login

Neither the browser console nor the network traffic in the browser give more hints why the validatepin request fails. I verified again that the clock on my mobile phone is synchronized with the JIRA server with a difference less than a second.

When using WinAuth instead of FreeOTP, we sometimes get the message that the secret token string from the QR image is invalid, because it contains a binary zero character.

Is it possible that the QR image does not reflect the code that's been stored with the user?

unknown

Hi Jochen,

we've checked atlassian-jira.log and everything looks fine, except the pin could not be validated message. From our point of view this could be caused by a configuration issue in Secure Login plugin settings. As you already pointed out the add-on for Confluence works perfectly in that regard and both plugins share the same codebase.

Please check especially the values of Window and Timestep in Secure Login extended plugin settings. Values have to be greater 0.

Furthermore, my colleague @Alexander Kueken and I can provide you with a newer version of Secure Login for JIRA with extended logging for better debugging purpose. In this case, please tell us your e-mail address.

Best regards,
Alexander Straube

Olav Andreas Antonsen

We have the same problem using JIRA 7.2.4 and plugin version 1.2.2. Our workarround is to update the VERIFIED column in table AO_xxxxxx_USER_CONFIG to true and then distribute the SECRET_KEY to the user so the user can register the secret key manually in Authy.

Jochen Suckfüll

We have several hundred users authenticating via LDAP. Many of them have not logged in yet, so they don't have a Confluence account yet. Updating the DB manually is just not an option here, let aside that distributing the secret key compromises the security.

Olav Andreas Antonsen

The users secret_key is always distributed to the user through the QR code....

The problem is that the secret key given to the user through the QR code doesn't match the secret key registered on the user in the table AO_xxxxxx_USER_CONFIG.

When the user, after scanning the QR code, uses Authy (or any other app) to generate an OTP, the OTP is generated using a secret key that doesn't match the key in the database. This makes it impossible to perform a successful login.

Jochen Suckfüll

> The problem is that the secret key given to the user through the QR code doesn't match the secret key registered on the user in the table AO_xxxxxx_USER_CONFIG.

That is a very interesting finding.

@Alexander Küken: Maybe you can double-check the code to see which conditions might cause a second secret to be generated but not shown to the user and written to the DB.

Jochen Suckfüll

As explained in the comments around here, there are two options to circumvent this issue:

Option 1 requires the user to disable JavaScript temporarily:

Disable JavaScript before submitting the username/password form.
Then initialize the authenticator.
Then enable JavaScript again.

Option 2 requires no user action, but removes 2FA for the avatar images:

The admin configures the secure login path whitelist to include /secure/useravatar.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software