Voting for this as well. Insane that a product at this price point doesn't natively support 2 factor. I would rather not use a plugin or 3rd party to accomplish this.

Another would be to support proper integration with Duo Security. We worked around the lack of this built-in 2FA support by using Duo's LDAP authentication proxy. It was a pain to set up and the integration is poor (authentication just hangs until the login is approved via Duo, and the error messages if 2FA fails are meaningless), but it does mostly work.

Support for 2-FA could be implemented in several ways. To be constructive, here're some ideas:

• Optionally require 2-FA only if user is authenticating from a new device
• Support Yubikey
• Support Google Authenticator
• Support HOTP and/or FIDO U2F
• Support Push notification to your mobile app with the OTP

It's a really big disappointment that Atlassian doesn't support 2-FA yet. It's 2015 guys, seriously!

we are using Thycotic to protect access to confluence. It is laughable that atlassian still has not released anything re this. not even a roadmap! - i could be wrong and looking forward to being told they have!

Go2Group has 2 factor working with RSA and with CCA US / NATO CAC and PIV cards. AS well as other smart cards.

These are shrink wrapped products.

We are working on RSA certification right now.

For any cloud-based product, this should be a requirement - especially with the latest attacks being publicized. 2-factor may not be the only mechanism, but relying on a singular user/password scheme is not good enough.

In 2015 2FA-Support should be standard for any commercial product.

We got 2FA working with Crowd by moving our user directory into OpenLDAP and then using Duo's auth proxy to get Duo to do 2FA. This basically works but is not ideal, since there is no UI feedback for the 2FA (it just hangs until the login request is approved), doesn't support Duo sending a text message with an auth code, and users with a hardware token need to append their OTP to the password field. Here's our authproxy.cfg:

[ad_client]
host=localhost
service_account_username=cn=admin,dc=example,dc=com
service_account_password=ADMIN PASSWORD
search_dn=dc=example,dc=com
auth_type=plain
bind_dn=cn=admin,dc=example,dc=com
username_attribute=cn

[ldap_server_auto]
port=3389
client=ad_client
ikey=INTEGRATION KEY
skey=SECRET KEY
api_host=API HOSTNAME
failmode=secure
exempt_primary_bind=false
exempt_ou_1=cn=admin,dc=example,dc=com

This assumes that slapd is running on the same server as Crowd. You just switch Crowd's LDAP connector to connect to port 3389 (duoauthproxy) instead of 389 (slapd itself).

You can also use SSO with 2FA if VPN is not acceptable (again, this is my personal, temporary, suggestion until atlassian implement it in their products)

Ingomar, you misunderstood that. I don't work for atlassian, it's the work around I found acceptable...

The fact that Atlassian is pointing their clients which ask for 2FA to VPN is, well, not helping. Leave user experience aside, you may have a much larger population of Atlassian product users than VPN users. VPN is support intensive.

Found this:
When we make internal decisions we ask ourselves "how will this affect our customers?" If the answer is that it would 'screw' them, or make life more difficult, then we need to find a better way. We want the customer to respect us in the morning.

Laurent, you could temporarily secure access to atlassian by enforcing use of VPN to connect to atlassian which would require 2 factor authentication. I know it's not ideal, but would increase security

Now I must found a solution for my company or also my customer. So My choice is
Stop using atlassian product and explain to my customer why we change
get an existing Google App solution
or create mine

We are currently looking into Tokenizer which looks pretty cool.

The main issue with the Atlassian way is that everything needs to be implemented 3 timed (JIRA, Confluence, Crowd)

This would be very valuable to us. We're currently evaluating writing our own solution in house, but would greatly prefer to have a standards-based solution built by Atlassian.

Bert, thanks for that, do you have any plans implementing Google Authenticator in your solution?

We have made progress on two factor authentication for Crowd, Now supporting various 2 factor methods. See http://doc.go2group.com/pages/viewpage.action?pageId=33882973
We are support US Gov ID CAC PIV cards for SSO. Can adapt to others.

RFC 6238 is an open and well supported standard - I agree the other 2fa support is nice but I could definitely see rfc6238 being available by default and the rest being supported through plugins.

+1

I agree with Benjamin, this feature is really needed.

I am rather surprised that Atlassian products still do not support two-factor authentication, when the practice is rapidly becoming industry standard.

It would be almost a two-liner, wouldn't it?

 function GoogleAuthenticatorCode(string secret)
     key := base32decode(secret)
     message := floor(current Unix time / 30)
     hash := HMAC-SHA1(key, message)
     offset := value of last nibble of hash
     truncatedHash := hash[offset..offset+3]  //4 bytes starting at the offset
     Set the first bit of truncatedHash to zero  //remove the most significant bit 
     code := truncatedHash mod 1000000
     pad code with 0 until length of code is 6
     return code 

(Source: http://en.wikipedia.org/wiki/Google_Authenticator)

I implement Atlassian everything, but also MFA. Everyone is implementing MFA, office 365, azure, google, apple account etc. Atlassian products are enterprise tools with all kind of confidential info. How hard is it for someone to keylog/record your password? Look over you shoulder?

I would prefer this security feature over all the countless gimmick updates.

Two Factor Authentication (tfa) is now a standard across many online services from Facebook, LinkedIn, Github etc. Atlassian products need to support this!! http://twofactorauth.org

Internal security audit has identified Crowd as not meeting security requirements. Obviously, we'd prefer that 2-factor be added over switching auth platforms.

I hope there is a real progress for this feature. It is a blocking point for us to move sensitive data into the Confluence.

This is well-intentioned, I'm sure, but this is an issue relating to Crowd's ability to support two-factor authentication in general, not JIRA's or Confluence's, and thus saying 'use Authy' or 'use DUO' is not helpful:

• Crowd may be acting as the identity service for non-supported Atlassian or non-Atlassian products;
• Hosting identity service mechanisms outside the organization might be proscribed (thus, Crowd);
• Sending codes to personal devices may not be allowed;
• Tokens may already be distributed (cards, fobs) that cannot be externally managed.

Third parties have claimed to do it in the past on the Answers site in the past, so it is possible.

DUO-Security has a 2 factor plug in for JIRA / Confluence

From an enterprise perspective, most companies have already implemented their 2 Factor solution. For example RSA Authentication Manager along with various Web Agents. The only way currently to have any solution with Crowd is by applying the two factor request at the Apache or web server level.

Crowd has an opportunity here. It could be the single entry point to the Atlassian application stack, that could support SAML, RSA, CAC, etc... I thought that was the idea?

The smart card market for large corporate/government instances is almost certainly more than 1%, especially in locations where text messages are not allowed or dongles would be redundant.

It doesn't matter what the second factor is, however, if Crowd doesn't bother supporting it.

Holy ticket spam, Brett Taylor. I'd say the number of people looking to use smart cards are < 1% of those looking for two-factor. Most people these days are satisfied with something like Authy (https://www.authy.com/).

Go2Group has SSO for CAC and PIV for Confluence. See SSO CAC and PIV authentication in Marketplace.
https://marketplace.atlassian.com/plugins/G2G-CAC-JIRA
We can extend this solution past CAC and PIV, let us know what you are using. Ping us at sales@go2group.com

Surprised this isn't in yet? Add me to the long list of people awaiting such functionality/support.

This is an extremely necessary update for Atlassian to implement.

+1, it would give me more peace of mind if JIRA OnDemand supported two factor authentication, which I assume is dependent on Crowd support.

If you need a +1, here is my vote.

We've just switched from Google Accounts to Crowd SSO and that has meant the removal of 2-factor authentication (as Google doesn't support 2fa with SSO), and that is bringing in complaints.

Hi everyone
Thanks for your feedback on two-factor auth and I apologise that we have not been able to provide consistent responses to every one of you. Your comments do not go unnoticed - we acknowledge that this is an unresolved issue, and one that is a requirement for some of your organisations. This is on our radar of features/improvements to invest in (which you can imagine is not short). Unfortunately, I can't promise you a specific release time for this at the moment, as it is not planned for the short term. Once we have settled on a more concrete date or release for this, I will provide an update here.
Cheers
Helen Hung
Product Manager

You can have a look at this: http://doc.go2group.com/display/G2GLabs/Client+Cert+Authentication
This supports the two factor CAC card login for JIRA, Confluence and Crowd.
It could be extended to support biometrics, etc.

Is very telling that the atlassian product for integrated identity management and authentication does not support any two factor authentication and in 2011 they asked people to just code their own. As people are mentioning, there is a RFC 4226 HOTP for two factor. I think Crowd needs to support this.

FYI, Google two-factor authnentication uses RFC 4226 HOTP/OATH. Their Google Authenticator mobile app (and others like it) support RFC 4226 as well.

So no special hardware/tokens are needed, and no proprietary servers are needed. The actual calculation is very simple and just requires a SHA-1 hash computation.

Have you taken a look at partnering with crypto card for your two factor auth. Basically there would be a mobile app that generates a one time key for each time you login.

As this doesn't seem to be a priority for Crowd we've integrated OATH HOTP into Apache DS which is backing our Crowd installation. Works quite well and the effort is not too high. Basically all you need is an additional implementation of the Authenticator interface.

a thumbs up for OATH HOTP! We're planning on using OTP c200 time based tokens from http://www.gooze.eu/catalog/otp-tokens-oath-0 . Going to need this to work with crowd at some point.

I created a new request to do two factor Gmail style: https://jira.atlassian.com/browse/CWD-2746

I would suggest that two factor be done the way gmail did it:

– sms based
– can auth a single browser for 30 days from a two factor (two factor once, then one factor for 30 days from that browser)

Forget proprietary one-time password devices like SecureID, etc. There is an industry standard for this called OATH HOTP specified by RFC 4226. No need to talk to any other servers, just have Crowd execute the hash algorithm itself.

Some References:

http://en.wikipedia.org/wiki/HOTP
http://code.google.com/p/mod-authn-otp/

Hi Ivar,

Atlassian won't be adding 2-factor auth to Crowd in the near future. It would not be hard to add yourself; you'd need to customise/replace the login screen and add a plugin to call out to your secondary service.

If you have customers after this functionality, that's what I'd suggest.

Cheers,
Dave.
Product Manager.

Our customer is considering using Crowd for all 8000 employees.
This issue might be a showstopper as they are considering adding two-factor auth, maybe like RSA, SMS (text) or similar.
There is no fix version on this one. Can you provide some sort of status/roadmap?

Its becoming more and more important for Government organizations in the US. All parts of the government are being required to add something like the
US millitary Common access Card http://en.wikipedia.org/wiki/Common_Access_Card to systems.

I've found the two-factor tokens from Secure Computing to be the most secure and cost effective, and have rolled them out at one public company.

Oh, also, Entrust says their server is written in Java.

Another token provider is Vasco. They supply the tokens for PayPal, so I presume they are cheap.

I got some info back from Ironkey:

We have a PKCS#11 module that gets plugged into Firefox or a CSP in IE and an openssl engine for CURL all that will bridge between web services and the smartcard on the device. That way you can do mutual authentication / client auth from Apache or web services and match on the unique certificate common name. We also support OATH, RSA SecureID, Verisign VIP, WikiD and soon OpenID.

Thanks for setting this up, Donna.

My goal would be to use Entrust tokens, although any token (RSA, etc) is going to be tied to their server software, since the seed cryptokey is what allows them to keep people from buying tokens without the expensive server. So that means that Crowd will need to talk to different token servers.

I'd be open to alternative TFA, but token generators seem to be the cheapest, since not all machines have biometrics.

The other option that might be worth looking at is key like the IronKey.