In today’s environment, even diligent users can become victims of cybercrime – and Atlassian customers aren’t immune. One of the top Cyber Threats of 2020 was once again phishing and social engineering for username and passwords. Stolen account usernames or passwords are often sold or traded on the Dark Web and private criminal forums. Bad actors use this information to enable data theft, manipulate projects, or delete critical information.
According to Microsoft, multi-factor authentication (MFA, 2FA) can block 99.9 percent of account compromise attacks. So your first step, if you haven’t already, is to make sure your account is MFA-enabled. Our documentation explains how to do this step by step.
Customers without MFA need additional protection from an account takeover. We now act on intelligence that data from breaches has been sold or traded on the Dark Web or private forums by invalidating stolen username and password combinations. We call this service Credential Invalidator.
Introducing Atlassian’s Credential Invalidator service
The Credential Invalidator service ingests and processes username and password combinations from data exposed through either user error or third-party breaches – not breaches of Atlassian systems. The service looks for information used for Atlassian IDs (for example, if a user inadvertently shares their Atlassian ID on a phishing website and that data is shared). Any Atlassian ID credentials identified in those datasets are labeled breached. Once that happens, the affected account owner will need to reset the password via a recovery link before they can access the account.
When someone tries to log in with breached information, they’ll receive the following message:
Via the change your password link, the user can reset their password and receive a recovery link in their mailbox.
This will render the stolen Atlassian ID credentials useless for cybercriminals while users simply have to configure a new password. If the user has an MFA-enabled account no action is taken since MFA prevents account takeover.
Retro threat intelligence analysis
Before building the Credential Invalidator service, we analyzed the breach data to calculate the accuracy of username and password combinations that were being sold or traded. The table below shows the different states of the username/password combinations.
| Valid | 77% |
| Invalid or MFA-enabled | 19% |
| Email verification required | 3.5% |
| Expired password | 0.5% |
FYI
The valid credentials were marked as breached after our retro-analysis in May 2021, to ensure passwords were rotated.
Since 77% of breached user passwords were found to be valid, it was clear to us that automated protections were warranted. We’ve now turned on breach notification for all user accounts.
Keeping Atlassian ID accounts safe
Even if users don’t know their Atlassian ID has been compromised, we act when Atlassian receives new intelligence. This cuts off yet another way cybercriminals can abuse stolen Atlassian ID credentials. As we like to say in the security team:
Trust is a product we deliver as a company. And that product is never finished.
It bears repeating: for each account you manage, make sure to enable MFA! The Atlassian documentation page describes how to do this, step by step. It offers additional protection and saves you from having to create a new password. In the meantime, Credential Invalidator has you covered.