Secure Login initialization loop

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?

4 answers

1 accepted

1 vote
Accepted answer

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

Option 1 requires the user to disable JavaScript temporarily:

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

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

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

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 for further analysis.


Best regards,

Alexander Straube

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.

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?

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

The extended settings have default values. I have reset them to "Google defaults" anyway, and judging from the logs this has been executed. The login problem persists though.

I would therefore come back to your offer to send me a plugin version with extended logging. I will send you an email to the address above right away.



The results are exactly the same with the plugin version 1.3-BETA.

Please find the logs attached.



Here are the logs with the version 1.3.1-BETA:

Right after submitting the username/password form, the plugin obviously attempts to access the marketplace. This fails, because the system is in a DMZ that has no access to the internet. (What does the plugin want to load anyway?)

After this failed https request, another code is generated.

I end up in the QR image loop again, but the marketplace request only happened once.

It turns out that the code that is shown matches the first code that is generated per welcome screen/QR image.

So whatever causes a second code to be generated every time – that second code is written to the DB, but not shown to the user. When initializing the authenticator app with the second code, the login works.

I just found out that disabling JavaScript avoids showing the welcome screens, and it avoids generating the second secret.

This means I can initialize the authenticator successfully with disabled JavaScript.

The log in this case looks like this:

user needs to set up authenticator
Generating QrCode for user: test_user2
Secret key encoded in QrCode: THECODE
qrCode-Image packed into velocity context, rendering template

I guess that there's an asynchronous request for loading content into the welcome screens and JIRA requires an authentication for that request. While the username/password authentication is not necessary due to the session token, it triggers the secure login initialization again.

It's the request to


that is triggering that another secret token is generated. That path is not in the whitelist, and we probably don't want to whitelist user avatars (which are personal data).

Logging in works if the user has been logged in before with the same browser, because in that case the avatar image is cached already.

So you may be able to reproduce the issue when you log out, then clear the browser cache, then use another admin user to clear your user token, then log in again.

Personally, I would really prefer to see the username on the page where I shall enter the PIN. As admin, I have more than one JIRA account, and it would really be helpful to know for which user I shall enter the PIN.

What's definitely missing is a logout button in order to switch to a different user when I cannot or don't want to enter the PIN. At this time, I must manually remove the session cookie to achieve that.

Thank you @Jochen Suckfüll, we will validate your finding. If this is the only aspect causing this issue, I am confident we will be able to provide a fixed and tested version over the marketplace tomorrow. And it will be a pleasure to add the username and logout button to the PIN pages, as you suggested, with that release.

I am really happy we now, with your help, have the possible cause identified. Slowly it really felt awkward and distressing, not being able to come up with a solution.  So I am glad, the extended logging finally helped, in combination with you digging further into the analyses, where the second request comes from.


@Jochen Suckfüll, @Olav Andreas Antonsen could you both do me a favor and add /secure/useravatar to the URL whitelist in the plugin configuration in order to validate, this is the only reason for the issue?

In the meanwhile, I will prepare the new release, so we can get out the release to the marketplace today. Thank you in advance.


It looks like adding /secure/useravatar URL whitelist solves the problem.

This is my current content of the URL whitelist:



I can also confirm that whitelisting /secure/useravatar solves the issue. The proper fix would be to avoid the request to this avatar in the first place. We should keep the whitelist as minimal as possible.

@Alexander Küken Could this problem have been avoided by NOT generating a new secret key if a row for the current user was already present in the AO_xxxxxx_USER_CONFIG table? 

For the bugfix release today we will add that URL to the default whitelist, in order to provide a fast fix. Sadly we can not prevent the request to this URL. It is not a call the plugin does explicitly. It comes from Atlassian AUI as far as I can see.

And in a second step, we will modify the generation of the secret, so it will not be newly regenerated with every call. The coincidence is, I wanted to do that anyway. There was a release planned for January, with the support of hardware tokens. The 1.3-beta release we sent you, already contained some of the preparations for this, e.g. showing the SECRET under the QR code so the user can use desktop based authenticators, like Authy Desktop, which can not read the QR code, or programmable hardware tokens, like a Yubikey.

Both will already work with the 1.3 release, I will finish today. And the instructions for using Authy Desktop and Yubikey will be published at the beginning of January.

But we also plan the support for TOTP hardware tokens, with hard coded secrets. And for this, we need to make some changes to the Secure Login internal user management anyway. And one will be, preventing the regeneration of the secret, even if the pin is not validated yet. And I would like to do this together, instead of changing it two times.

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 

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. 

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.

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.

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

Dear Jochen,
Dear Olav,

we are seriously looking into that issue and every hint from you was precious. Our main problem right now is, we are not able to reproduce your issue. On all our systems the plugin behaves correctly, which makes it really difficult, to come up with a solution fast.

But we are on it and we will keep you up to date. And yes, we already double-checked the code. But the code looks good so far. In addition, there had been no changes at the QR code handling in the past two releases.

On additional question: which database you are using in your configuration?


According to the system information page, we're using the database type "postgres72", with a database driver "PostgreSQL Native Driver PostgreSQL 9.1 JDBC4 (build 903)" and the postgres version 9.5.5.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,234 views 5 10
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you