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?
As explained in the comments around here, there are two options to circumvent this issue:
Option 2 requires no user action, but removes 2FA for the avatar images:
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG