diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Compromised credentials are a threat to your business and customers. Here’s how to reduce the risk.

Credential stuffing is a type of cyberattack in which a cybercriminal uses stolen usernames and passwords from one organization (obtained in a breach or purchased off of the dark web) to access user accounts at another organization.

Credential stuffing attacks are one of the most common causes of data breaches because[ 64% of all people](https://f.hubspotusercontent20.net/hubfs/3791228/2022%20SpyCloud%20Annual%20Identity%20Exposure%20Report.pdf) reuse the same password on multiple (and sometimes all) accounts. In fact, on Auth0's platform alone,[ nearly half of all login requests](https://auth0.com/resources/whitepapers/credential-stuffing-attacks) we receive each day are attempts at credential stuffing.

The opportunity for cybercriminals to use credential stuffing is only growing as more credentials are exposed through breaches; at present, literally billions of compromised credentials are circulating on the dark web. 

However, credential stuffing attacks are preventable if you implement the right cybersecurity measures. Below is what executives need to know about credential stuffing attacks and what can be done to reduce or prevent the likelihood that their organizations will be a victim of one.

> More in the following:
>
> - **[Credential stuffing whitepaper](https://auth0.com/resources/whitepapers/credential-stuffing-attacks)**
> - **[What is broken authentication](https://auth0.com/blog/what-is-broken-authentication/)**

## How Credential Stuffing Works

To execute a credential stuffing attack, cybercriminals add a list of stolen username and password pairs to a botnet that automates the process of trying those credentials on multiple sites at once. Large-scale botnet attacks can overwhelm a business' IT infrastructure, with websites experiencing as much as[ 180 times](https://auth0.com/blog/auth0-reveals-50000-credential-stuffing-attempts/) their typical traffic during an attack.

![Anatomy Credential Stuffing](https://images.ctfassets.net/23aumh6u8s0i/ohyMA4nbwQgkGF77RnSOs/b8997e017022790f156a985fb97c375d/anatomy-credential-stuffing.jpg)

Once cybercriminals find a site where a set of credentials works, they’ll have access to a user's account and personal data to do with as they please, which most commonly includes:

* **Selling access to compromised accounts:** This is particularly common for media streaming services. [Disney+](https://www.cpomagazine.com/cyber-security/new-disney-plus-streaming-service-hit-by-credential-stuffing-cyber-attack/),[ Netflix, and Spotify](https://www.engadget.com/2019/03/13/wickedgen-admin-arrested-stolen-passwords-netflix-spotif/) have all been victims of attacks in which hackers sold access to user accounts for less than the cost of a subscription.
* **E-commerce fraud:** Hackers can impersonate legitimate users at retailers' websites and order a high-value product, either for their own use or for reselling. This is a common (and for criminals, potentially lucrative) form of identity theft, which makes retail the most vulnerable vertical for credential stuffing, according to[ research from Akamai](https://www.akamai.com/newsroom/press-release/akamai-research-commerce-remains-top-target-with-over-14-billion-web-application-and-api-attacks).
* **Corporate/institutional espionage and theft:** While the above crimes have serious consequences for companies and their customers, this third form of attack has the potential to be most devastating for businesses. If an attacker successfully hijacks the account of an employee or admin, they could gain access to all sorts of sensitive personal information, like credit card numbers, social security numbers, addresses, and login credentials as well, all of which they can sell to the highest bidder.

## The Costs of Credential Stuffing Attacks

Although credential stuffing attacks often have a low success rate ([usually one to three percent](https://www.recordedfuture.com/credential-stuffing-attacks/)), their impact on organizations is often anything but small.

For example, the Ponemon Institute's ["Cost of Credential Stuffing" report](https://library.idgcommunications.net/idgcampaigns/documents/uploaded_data/d40/97b/1c-/original/the-cost-of-credential-stuffing_EN.pdf) found that businesses lose an average of $6 million per year to credential stuffing in the form of application downtime, lost customers, and increased IT costs.

Increasingly, regulators, as well as the public, are also holding companies accountable for credential stuffing attacks with stiff fines. Companies may be subject to legal action under data privacy laws such as [GDPR](https://auth0.com/docs/compliance/gdpr) if they fail to implement adequate security measures to prevent such attacks, fail to inform the public of a breach, or don't do enough to protect passwords.

For example, in 2018, the UK's [Information Commissioner's Office (ICO) fined Uber](https://www.computerweekly.com/news/252453244/ICO-fines-Uber-385000-for-data-protection-failings) £385,000 for "a series of avoidable data security flaws" that exposed the data of approximately 2.7 million UK customers. And in 2021, the French Data Protection Authority (CNIL) fined a data controller and its data processor €225,000 “for failure to implement adequate security measures to protect customers’ personal data against credential stuffing attacks on the website of the data controller.”

## Credential Stuffing Attacks vs. Brute Force Attacks

Credential stuffing is considered a type of brute force cyberattack. But in practice, the two are very different, as are the best ways to secure your systems against them.

Brute force attacks attempt to guess passwords by changing the characters and numbers (often in prescribed patterns or with commonly used base password phrases). To protect against them, you can limit the number of failed login attempts with[ brute force protection](https://auth0.com/docs/attack-protection/brute-force-protection), use a CAPTCHA, or require your users to use a stronger password.

However, a strong password won’t stop a cybercriminal from gaining access to an account via credential stuffing because the password is already known. Even CAPTCHA's or brute force protection’s ability to protect users is limited since users often[ change their passwords in predictable patterns](https://www.sans.org/security-awareness-training/blog/time-password-expiration-die) and cybercriminals have a breached password to iterate from.

## How to Prevent Credential Stuffing Attacks

Most people know password reuse is unsafe but choose to use the same password on multiple sites anyway because they have roughly[ 100 passwords to remember](https://tech.co/news/average-person-100-passwords). Password managers are an option, but [adoption rates are low](https://www.security.org/digital-safety/password-manager-annual-report/). So to prevent credential stuffing attacks, it’s up to organizations to take measures — such as removing passwords altogether — to ensure cybercriminals can’t use stolen credentials to access their users’ accounts. Based on [OWASP's Credential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html), below are several methods for doing so.

### Credential hashing

Credential hashing is the first step to protecting your user's credentials from theft. [Hashing](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) scrambles a user's password before you store it in your database so that in the event that it is stolen, a hacker won’t be able to use them (in theory, at least).

In practice, not all password hashing is uncrackable. As Rick Redman, a penetration tester at KoreLogic, [explains](https://www.wired.com/2016/06/hacker-lexicon-password-hashing/), “The strength of the hash is the insurance policy. It tells you how much time users have to change their passwords after a data breach before they come to harm... If it’s just SHA1, there is no window... If it’s bcrypt, you have time to run away and change all your passwords.”

So although hashing user passwords won’t prevent a credential stuffing attack, it will limit what a cybercriminal can do with those passwords once they’ve stolen them.

### Breached password protection

Breached password protection compares the password a person uses to log in against databases of compromised credentials (like[ haveibeenpwned](https://haveibeenpwned.com/)) to prevent credential stuffing in real-time. 

For example,[ Auth0's breached password detection](https://auth0.com/docs/attack-protection/breached-password-detection) can be configured to notify a user, block them from logging in, or request an additional authentication factor (MFA) if it suspects their credentials were part of a published security breach or if a login attempt came from a suspicious IP address.

### Bot detection

As mentioned earlier, attackers use bots to execute a credential stuffing attack. [Auth0's bot detection](https://auth0.com/docs/secure/attack-protection/bot-detection) feature is able to identify a bot attempting to authenticate with [a high percentage of success](https://auth0.com/blog/auth0-bot-detection-reduces-bot-attacks-by-79/). It provides protection against credential stuffing attacks with very little friction to legitimate users. When a bot attack is detected, it displays a CAPTCHA step in the login experience to eliminate bot and scripted traffic.

### Anomaly detection

Monitoring what is happening is always a good approach to intervene earliest and stop an attack. If you have visibility of your traffic, you can understand when you are under attack, and you can take action to mitigate attacks. In Auth0, you can use [Log Streams](https://auth0.com/docs/customize/log-streams) to monitor your traffic in near real-time. After creating and configuring a Log Stream, you will start seeing Auth0 events being ingested into your chosen monitoring service. Based on your monitoring service, you can build your anomaly detection dashboard by anayzing the [Attack Protection Log Events](https://auth0.com/docs/secure/attack-protection/view-attack-protection-events).

### Multi-Factor Authentication (MFA)

[Multi-factor authentication (MFA)](https://auth0.com/multifactor-authentication) is a highly effective way to prevent credential stuffing because it requires users to log in with another form of authentication in addition to a username-password combination. For example, this could mean biometric authentication such as a fingerprint, a one-time code sent to a device associated with the user, or an email sent to a secured account — none of which a cybercriminal will have access to.

Although the adoption of MFA has been slow due to concerns about its impact on customer experience, the increase in sophistication and customizability of MFA are helping it catch on. For instance, in February 2020,[ Google announced](https://siliconangle.com/2020/02/12/google-require-nest-users-use-two-factor-authentication-enhanced-security/) it would require Nest smart home users to use two-factor authentication.

### Continuous authentication

Continuous authentication systems use factors like biometrics or behavioral patterns to verify a user’s identity in real-time (while they use an application) instead of a password. As a result, credential stuffing attacks (as well as a number of other cyberattacks) are no longer a viable method for cybercriminals to gain unauthorized access to a user’s account.

### Passwordless authentication

[Passwordless authentication](https://auth0.com/passwordless/) can prevent credential stuffing altogether because it verifies a user with something they have (a device or another account) or something they are (biometrics) instead of a password (something they know).[ Passwordless](https://auth0.com/passwordless/) also creates a better login experience for users and saves organizations time and money from dealing with password resets.

## Passwordless Authentication Is Better for Businesses and Users

Not only does passwordless authentication eliminate credential stuffing attacks, but numerous studies and reports show that it is a[ more secure](https://auth0.com/blog/is-passwordless-authentication-more-secure-than-passwords/),[ more user-friendly](https://www.lastpass.com/solutions/passwordless-access/from-passwords-to-passwordless), and[ more cost-effective](https://www.weforum.org/press/2020/01/forgotten-your-password-not-having-one-will-make-you-safer-says-world-economic-forum) solution overall than traditional username-password authentication for both businesses and their users.

“Relying on passwords as the primary means for authentication no longer provides the security or user experience that consumers demand,” Andrew Shikiar, Executive Director of the FIDO Alliance, [explains](https://www.weforum.org/press/2020/01/forgotten-your-password-not-having-one-will-make-you-safer-says-world-economic-forum) in a joint report with the World Economic Forum. Adrien Ogee, Project Lead from the World Economic Forum, adds, “Better authentication practices are not just possible; they are a necessity.”

Auth0’s platform makes it easy to implement secure, user-friendly passwordless authentication using biometrics, social logins, and more. Learn how to eliminate the risks associated with traditional username and password authentication with Auth0’s Passwordless authentication platform[ here](https://auth0.com/passwordless/).

What Is Credential Stuffing? How To Prevent Credential Stuffing Attacks

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

HTTPS downgrade attacks compromise your web application security by switching to HTTP. Learn how to prevent them.



Using HTTPS in your web application is mandatory to guarantee trust and security. However, an attacker may try to downgrade that secure protocol into simple HTTP and grab or tamper with the exchanged data. Learn how this type of attack works and how you can prevent it.

## What is an HTTPS Downgrade Attack

Nowadays, most websites and web applications use HTTPS as their default protocol. This happened [thanks to the effort of browser providers and other supporters](https://www.eff.org/encrypt-the-web). Using a secure protocol like [HTTP over TLS](https://en.wikipedia.org/wiki/HTTPS) is a best practice for a few reasons:

- It guarantees **confidentiality** since data exchanged between the client and the server are encrypted.
- It ensures **authenticity** since the domain identity is verified by a trusted third-party ([Certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority)).
- It offers data **integrity** since any tampering attempt is detected.

In other words, by using HTTPS, you avoid typical *person-in-the-middle* ([man-in-the-middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)) attacks, where an attacker intercepts and possibly alters messages exchanged between the client and the server.

However, even if you enabled your website to use HTTPS, there are situations that an attacker can exploit to downgrade the secure protocol to the unprotected HTTP. How can this happen?

Suppose your website is using HTTPS, but you missed updating a link in one of your pages, say the following one:

``` html  
<a href="http://mywebsite.com/awesomepage">Awesome page</a>
```

This link uses plain HTTP. What happens if the user clicks that link and the HTTPS-enabled server receives a plain HTTP request? The typical approach is to redirect the client to use HTTPS, as shown by the following diagram:

![HTTP to HTTPS redirect](https://images.ctfassets.net/23aumh6u8s0i/2j1wM2BuZFlC4Sv8mttvmd/9623624757c57d369a593248d7a19b00/http-to-https-redirect)

However, an attacker may intercept that apparently harmless HTTP request and trigger the person-in-the-middle attack you are attempting to avoid with HTTPS. The following diagram shows how interception may occur:

![HTTPS downgrade attack](https://images.ctfassets.net/23aumh6u8s0i/1aPLFQvJvCirLdlhZPqc57/9e89921d3ec5899a640b62b91518c9b7/https-downgrade-attack)

From that request on, all messages sent by the client are transmitted via HTTP and manipulated by the attacker. One single HTTP request may compromise the whole communication security between the client and the server. For this reason, you should never mix HTTP and HTTPS protocol on a website.

To avoid this type of protocol downgrade, you should make sure that all the internal links in your website are relative or use HTTPS. This may be an affordable solution for small websites, but it is not feasible for a large website, especially if its content results from many people's contributions.

<include src="TweetQuote" quoteText="Ensuring security by simply forcing HTTPS as the default protocol is not so trivial."/>

## Using Content Security Policy

The HTTP [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) (CSP) header can help you force browsers to use HTTPS throughout your website. The `upgrade-insecure-requests` directive is designed for this purpose. By adding the following meta tag in the head section of all the pages of your website, any link using HTTP will be interpreted as if it uses HTTPS:

``` html  
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
```
Consider that the directive also applies to non-navigational links, such as scripts, stylesheets, images, and other media.

> **Note:** While major browsers support the `upgrade-insecure-requests` directive, it has never been implemented in IE11. Even if Microsoft's browser is now deprecated, it is still being used.

Alternatively, your server application can send the HTTP header to the browser. For example, in an [Express](https://expressjs.com/) application, you can send it through a middleware, as shown in the following code snippet:

``` javascript  
const express = require("express");
// ...other require...

const app = express();

app.use(function(req, res, next) {
  res.setHeader("Content-Security-Policy", "upgrade-insecure-requests");
  next();
});
// ...other code...
```

An alternative to manually setting HTTP security headers in your server application is to use a specific package. For example, in an Express application, you can use [helmet](https://helmetjs.github.io/).

> **Note**: By using the `upgrade-insecure-requests`, the HTTP fallback is automatically disabled. This means that if the requested resource is not actually available via HTTPS, the request will fail.

## Using HSTS

There are situations where the CSP `upgrade-insecure-requests` directive may not be enough. For example, this happens when a third-party website has a link to your website with the `http` scheme. Actually, the `upgrade-insecure-requests` directive tells the browser to use HTTPS for any further request originated by that page. However, the page itself is supposed to be requested through HTTPS. If it is requested via HTTP, the person-in-the-middle attack may still happen, and the attackers can manipulate the HTTP headers before they reach the browser. In other words, the CSP `upgrade-insecure-requests` directive doesn't eliminate the risk of having HTTPS downgraded to HTTP.

You need a way to tell the browser to use HTTPS to request **any** resource of your website, not just the resources linked to the current page. This is the purpose of another HTTP header: the HTTP `Strict-Transport-Security` header (HSTS). The following is an example of HSTS header received by a browser:

```
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

When the browser receives such a header, it records the page's domain and the expiration time expressed in seconds through the `max-age` directive. From now on, the browser will use HTTPS for any request sent to that domain, regardless of the specified protocol. This will happen until the expiration time elapses unless a new HSTS header is received. In fact, each time the browser gets a new HSTS header, the expiration time is updated.

In the example, besides the `max-age` directive, you notice the `includeSubDomains` directive. This directive tells the browser to apply the HTTPS request policy to any subdomain of the current page's domain. This increases the security of the whole domain hosting your website or application.

## Preloading Strict Transport Security

So, by using the HSTS header, you ask the browser to use HTTPS for any request to your website for a given time. With this instruction, the browser will ignore any attempt to make requests via HTTP, wherever they come from. However, there is still one possibility that could cause HTTPS downgrade: the very first access to your website.

Suppose a user has never visited your website. Now, suppose they manually insert your website URL in their browser's address bar by explicitly using the `http` scheme. Since this is the very first time the user makes a request to your website and their browser knows nothing about it, that request is vulnerable. Only after the first request with an HSTS header the browser knows that it always has to use HTTPS. An attacker may intercept the first request, and your website is compromised.

How can you instruct a browser to reach your website by always using HTTPS, including the very first time?

Well, you can request to add your domain to the [HSTS Preload List](https://hstspreload.org/). This domain list is maintained by Google and is hardcoded into Chrome as the list of sites that should be requested exclusively via HTTPS. Most major browsers also have their HSTS preload list based on the Chrome list.

You need [to meet a few requirements](https://hstspreload.org/#submission-requirements) to be included in the list. Among others, you have to add the `preload` directive to the HSTS header as in the following example:

```
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```

Once your domain is included in the hardcoded HSTS list of a browser, the browser will no longer make any requests to your website via HTTP.

## Web APIs and HTTPS Downgrade Attacks

So far, the discussion about HTTPS downgrade concerns browsers. What about Web APIs?

You may apply HTTP-to-HTTPS redirection and HSTS headers, but API clients usually don't follow the redirect, unlike browsers. So, the only practical approach is to deprecate the HTTP protocol and use only HTTPS, as recommended by [CIO.gov](https://https.cio.gov/apis/).

The main problem here is how to deal with possible HTTP requests. In case of migration from an HTTP-based API to HTTPS, you should apply a progressive transition involving the partners that have built clients for your API. Also, be explicit in the API documentation about using HTTPS. From a technical point of view, your API should return the 403 Forbidden HTTP status code to an HTTP request.

The following is a simple example of Express middleware that refuses HTTP requests:

``` javascript  
const express = require("express");
// ...other require...

const app = express();

app.use(function(req, res, next) {
  if (!req.secure && req.get('x-forwarded-proto') !== 'https') {
    return res.status(403).send('Please, use HTTPS');
  }
  next();
});
// ...other code...
```

In the code above, you check if the current request is using HTTPS (`req.secure`) or the original request used that protocol (`req.get('x-forwarded-proto') !== 'https`). The latter check makes sense if your API is behind a reverse proxy. If the request is not using HTTPS, the server sends a 403 HTTP status code as a response.

<include src="asides/AboutAuth0" />

## Conclusion

In this article, you learned how ensuring security by simply forcing HTTPS as the default protocol in your website or application is not so trivial. The person-in-the-middle attack may still happen in particular situations. However, you can leverage a few standard HTTP headers to mitigate this risk: the CSP `upgrade-insecure-requests` directive and the HSTS header with preloading. You also learned that a slightly more crude approach should be used for Web APIs due to the lack of standard clients that can apply security policies similar to browsers'.

To learn more, visits the [OWASP HSTS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) and the [CIO.gov HTTPS adoption guidelines](https://https.cio.gov/).




Preventing HTTPS Downgrade Attacks

ec1c9350c3d2306e7c42b9307bea93de?s=480&r=pg&d=https%3A%2F%2Fcdn avatar

ec1c9350c3d2306e7c42b9307bea93de?s=480&r=pg&d=https%3A%2F%2Fcdn

I like working at Auth0 because I’m interested in how to scale a startup and training the next generation of identity experts.

Strategic Operations and Technical Field Enablement Director

Yvonne Wilson

Learn how to plan for failures and changes in your identity project.

How To Have a Successful IDM Project (Part 2)

Almost 90 millions Facebook users were affected by a breach that compromised access tokens to the platform.



On September 25th, 2018, Facebook learned from its engineering team that [a security vulnerability compromised around 50 million accounts](https://newsroom.fb.com/news/2018/09/security-update/). While the investigation is still in progress, Facebook already has defined the attack surface and vulnerabilities that led to the attack along with identity data that was compromised.

A feature that allows Facebook users to determine what their profile looks like to other people, known as ["View As"](https://www.facebook.com/help/288066747875915?helpref=faq_content), had a vulnerability that was exploited by attackers. 

![Facebook View As feature.](https://images.ctfassets.net/23aumh6u8s0i/2fEamNAYfwNcwaU1rOpoBy/ee3e16c5e6b6b4c7573882479ea46e6a/facebook-view-as-feature)

Through this vulnerability, attackers were able to steal Facebook access tokens. An [access token](https://auth0.com/docs/tokens/access-token) is a credential that can be used by an application to access an API. Its main purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions. In this case, an attacker could have used the Facebook access tokens to take over accounts.

One of the ways that Facebook uses access tokens is to persist login. As Facebook mentions on their [Security Update](https://newsroom.fb.com/news/2018/09/security-update/), these tokens are the "equivalent of digital keys that keep people logged in to Facebook so they don’t need to re-enter their password every time they use the app." Thus, for this type of data breach, changing the user's password doesn't provide risk mitigation. Instead, the digital keys need to be changed. Once Facebook understood the origin and nature of the attack, the engineering team carried out the following actions to mitigate any damage to the platform and to users:

- Facebook fixed the vulnerability in the "View As" feature.
- Facebook has informed law enforcement about the attack.
- Facebook has reset the access tokens of the almost 50 million accounts that were determined to be at risk in order to diminish any risk to the user data and to ensure their personal and digital security.
- As a precautionary step, Facebook has also reset the access tokens for another 40 million accounts. These accounts used the "View As" feature in the past year.

As a result of these security measures, about 90 million users will have to log back into the Facebook platform. Other applications that use Facebook login are also impacted and will require users to re-authenticate. Facebook wants to remain transparent and direct in the acknowledgment and communication of this security breach. Once affected users log back into their accounts, they will receive a notification at the top of their News Feed with an explanation of what has happened and what actions were taken.

![Facebook security breach user notification](https://images.ctfassets.net/23aumh6u8s0i/6dPmOhI9JO2lMpeVzhexwe/a74063a6782f8882ed81ef1ba0a972a9/facebook-data-breach-notification-access-tokens)

[Source](https://fbnewsroomus.files.wordpress.com/2018/09/42647794_340201783392972_4207828087510925312_n.png?w=960&h=551)

As a final precaution, Facebook has turned off the "View As" feature to run a security review as part of their investigation. As the security investigation is on its early stage, Facebook has yet to determine if any of the compromised accounts had their data accessed or misused. The identity or location of the attackers is also unknown at this time. Facebook vows to keep users updated on the evolution of the investigation. 

On a statement on his personal page, Mark Zuckerberg, Facebook CEO, issued a statement [summarizing the nature of the data breach](https://www.facebook.com/zuck/posts/10105274505136221). Part of his statement includes the assessment that new tools need to be developed to prevent attacks like this from being successful:

> "We face constant attacks from people who want to take over accounts or steal information around the world. While I'm glad we found this, fixed the vulnerability, and secured the accounts that may be at risk, the reality is we need to continue developing new tools to prevent this from happening in the first place. If you've forgotten your password or are having trouble logging in, you can access your account through the Help Center."

To stay tuned on this developing investigation, visit [Facebook Newsroom](https://newsroom.fb.com/) or follow [@facebook](https://twitter.com/facebook) on Twitter.


<include src="asides/AboutAuth0" />


Early Look at Facebook Access Token Security Breach

justin-hinerman

Justin is a Software Engineer at Auth0, focusing on solving authorization challenges for customers. Before Auth0, Justin spent several years as an Identity Management consultant and architect. It was in this job that he came to appreciate the many challenges customers face when trying to implement identity. This knowledge informs his current work at Auth0, trying to make identity as simple as possible for our customers. In his free time, he enjoys spending time with his family, playing soccer, camping, traveling, and playing drums.

Software Engineer

Justin Hinerman

Auth0 now provides your own custom domain for login with a central authorization server.



## Using Custom Domains to Brand Central Authorization Servers

Authenticating with a provider through a central authorization server provides you with a standards-based, maintainable, and secure login approach. This type of login also provides single sign-on benefits and a modern user experience. You can explore the[ benefits of this architecture further in this blog post](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/).

For those who are not familiar with the concept, you may have noticed that you are always redirected to [accounts.google.com](https://accounts.google.com) when you log into Google sites such as Gmail or Youtube. Google has a _central authorization server_ that is used across all of their applications and third-party apps.

![Google central authorization server](https://images.ctfassets.net/23aumh6u8s0i/7CnL0OedgtBQGe3FxUbyfE/f94f36fcd0c31e2fccd6570b1d6c8fb7/google)

Auth0 provides this same capability out of the box, allowing you to unify login for your own brand and products. Enabling Auth0's central authorization provider, [Universal Login](https://auth0.com/docs/hosted-pages/login), is easy, straightforward, simple to configure, and can be customized to suit your brand.

Customers who prefer this experience to be served from their own domain, instead of `[your-account].auth0.com`, can configure their own custom domain in Auth0. This feature is available for all free-tier customers. Adding your own custom domain to an existing implementation only requires small code changes thoroughly detailed in our [custom domain setup docs](https://auth0.com/docs/custom-domains#step-3-complete-feature-specific-setup). Simple configuration can be completed within your Auth0 dashboard.

<include src="TweetQuote" quoteText="You can configure your own custom domain in Auth0. This feature is available for all paid customers."/>

## Benefits of Using a Custom Domain

### End-User Benefits

By using a custom domain for your authentication page, you keep your users interacting with you within the context of your brand, which helps you build brand loyalty. Users are not redirected to a third-party site that breaks the branding context. This prevents users from becoming confused about whether or not they are still running a transaction or operation with you.

For example, if your Auth0 domain is `northwind.auth0.com`, you can have your users to see, use, and remain on `login.northwind.com`.

<include src="TweetQuote" quoteText="Using a custom domain with Auth0 allows your users to feel confident that they are providing their credentials to the right party. Authentication happens within the context of your brand."/>

Auth0 support for custom domains allows us to do the authentication heavy lifting for you without compromising your branding experience.

### Customer Benefits

Brand loyalty from users is a pillar for the success of an organization of any size. One of the ways to build brand loyalty is by offering a consistent branding experience to users. It's important that your users always feel that they are interacting directly with you to avoid confusion or session abandonment.

From the security point-of-view, using [Universal Login](https://auth0.com/docs/hosted-pages/login) is the preferred way to handle end-user credentials. It allows you to have comprehensive control of authentication in one centralized place, as opposed to having individual applications handling credentials. Consequently, having your authentication services contained in one place will make your application architecture more maintainable. Applications are only given the access they need and authentication services can be scaled easily.

You can mitigate certain phishing attacks when your users expect to run transactions within your domain. Having that domain consistency will allow your users to easily and quickly reject phishing attempts.

Universal Login also offers you simplicity as an implementation advantage. You don't have to worry about integrating login user interfaces into different applications. When you use Auth0 Universal Login, you get all the features you need in the fastest possible way: redirecting to a common login interface. Adding custom domains to this workflow creates a seamless experience for your developers and end-users.

## Custom Domain Authentication Features

Core Auth0 features and flows support the use of custom domains:

* OAuth 2.0/OIDC-Compliant Flows (those using the `/authorize` and `/oauth/token` endpoints).
* Database and Social Connections.
* SAML Clients and Connections.
* A full list of features supporting the use of custom domains is available in the [feature section](https://auth0.com/docs/custom-domains#features-supporting-use-of-custom-domains) of our custom domains document. New features, such as enterprise connections, will be added to the list as they become available. Keep an eye on that space!

## How It Works

To [configure your custom domain with Auth0](https://auth0.com/docs/custom-domains#how-to-configure-custom-domains), go to your account settings, select Custom Domains, add your own domain, and follow the instructions.

![Auth0 custom domains tenant settings](https://images.ctfassets.net/23aumh6u8s0i/4sOb3yHNVMECyroBboPtTX/11e347f12d8b3ee97b028818e021cbfc/custom-domain-setup-auth0-dashboard.png)

You will need to complete a [verification process](https://auth0.com/docs/custom-domains#step-2-verify-ownership) for your domain that varies depending on whether you decide to use an Auth0-managed or a [self-managed certificate](https://auth0.com/docs/custom-domains/self-managed-certificates#step-2-verify-ownership).

Your existing integrations using your `[your-account].auth0.com` domain will continue to work. After migration to your custom domain is complete, users will have to log in again since existing sessions will no longer be valid.

## Custom Domain Self-Service

Different than other solutions, Auth0 not only gives you the option to use a custom domain, but Auth0 also empowers you with full control over setting up and using your custom domain for authentication. Flexible self-service options are available through our Dashboard for you to directly handle selecting, verifying, and implementing your custom domain. You don't have to wait on us for anything to complete this process. You are in charge.

## Using Custom Domains with Auth0

[Atlassian](https://www.atlassian.com/) is an early-adoption Auth0 customer using a custom domain. Atlassian is consolidating all of their B2B and B2C products under a central authorization provider at [id.atlassian.com](https://id.atlassian.com).

![Atlassian central authorization provider](https://images.ctfassets.net/23aumh6u8s0i/6gwmZK2fxPEmUWFZ1t4Tdf/85045a917ff13e7b2951a593aa836a03/atlassian)

Other Auth0 customers currently using custom domains with a central authorization server include [AGL](https://www.agl.com.au/residential), [National Life Group](https://www.nationallife.com/), and [News UK](https://www.news.co.uk/).

With the launch of custom domains with Auth0, your users will benefit from a first-class login experience, while keeping your brand through a trustworthy domain.

<include src="TweetQuote" quoteText="Using custom domains with Auth0 allows your users to benefit from a first-class login experience while keeping your brand through a trustworthy domain."/>

For more information, check out our [Custom Domains documentation here](https://auth0.com/docs/custom-domains).


Take a No-Compromise Approach to the Login Experience Using Custom Domains

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

Personal identifying information was compromised for 143 million Americans in a massive Equifax data breach from May to July, 2017.



## 143 Million Consumers Compromised in Equifax Data Breach

On September 7, 2017, consumer credit reporting agency [Equifax announced a data breach that potentially exposed personal data for 143 million US consumers](https://www.equifaxsecurity2017.com/). [Equifax](https://equifax.com) is one of the three largest American credit agencies, alongside [TransUnion](https://transunion.com) and [Experian](https://experian.com).

From mid-May through July 2017, criminals were able to access personal identifying information, including names, Social Security numbers, birthdates, addresses, and some driver's license numbers. In addition, credit card numbers for 209,000 US consumers were compromised, as well as dispute documents for 182,000 people. During the investigation, Equifax also discovered that limited personal information for some UK and Canadian residents had also been accessed. The hack was discovered on July 29, 2017.

Almost half of all Americans may have been affected by this data breach. **Your information may have been compromised even if you haven't signed up to use Equifax.** The data breach of a credit reporting agency (CRA) such as Equifax is particularly insidious because many consumers are _not aware_ that their data is stored with a CRA. [Equifax and other CRAs acquire their data](https://blog.equifax.com/credit/how-do-credit-reporting-agencies-get-their-information/) from credit card companies, banks, retailers, auto and mortgage lenders, debt collectors, and public records in order to generate credit scores. You don't need to have personally signed up with a CRA to have your data stored with Equifax!

## What Should I Do?

You _can_ check to see if your data has been exposed by visiting [Equifax's 2017 Incident Potential Impact website](https://www.equifaxsecurity2017.com/potential-impact/) and clicking the "Check Potential Impact" button. You can fill in your last name and last six digits of your Social Security number to find out if your data has potentially been leaked and receive a date to come back to enroll in free credit monitoring for a year. The [Federal Trade Commission also has detailed instructions available here](https://www.consumer.ftc.gov/blog/2017/09/equifax-data-breach-what-do).

Another thing you should do is actively check your bank and credit card statements regularly. If you see any suspicious or unusual activity, report it immediately to your financial institution. Don't become complacent and stop checking a week or two after a breach. Staying aware and vigilant with your accounts is important at all times. [Unfortunately, large data breaches have occurred many times in the past](http://money.cnn.com/2017/09/07/technology/business/biggest-breaches-ever/index.html), and in the digital age, we should be as prepared as possible to face more in the future.

In addition, you can monitor your own credit by requesting a free copy of your credit report from each of the three major CRAs once a year. If requests are staggered between the agencies, you can check your credit once every four months. Alternatively, you may wish to use services such as [CreditKarma](https://www.creditkarma.com/) to obtain free scores to monitor your own credit. You can also [freeze your credit](http://clark.com/personal-finance-credit/credit-freeze-and-thaw-guide/) if you choose. If you do this, make sure you freeze it with all three major CRAs, not just Equifax.

## Aside: Use Auth0 to Protect Your Users From Data Breaches

Auth0 provides [breached password detection](https://auth0.com/breached-passwords) that can be enabled simply and easily. The Auth0 security team maintains a database of third party breached credentials. This database is updated daily. On each login, user credentials are checked against the leaked passwords database. If a breach is suspected, the user is notified and cannot log in until they change the compromised password.

<video autoplay="" loop="" width="600">
  <source src="https://cdn.auth0.com/blog/breach/lock-2.m4v">
<img src="https://images.ctfassets.net/23aumh6u8s0i/3DpdlDPwLfrdGGb7RUQ6NU/d959326b776a71764727d5e3eae43c8a/lock"/>
</video>

Read about [Breached Passwords](https://auth0.com/breached-passwords) and [Anomaly Detection](https://auth0.com/docs/anomaly-detection) to learn more about how to protect users and their credentials with Auth0. You can also <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account and start protecting your users today</a>!



Equifax Data Breach Compromises 143 Million People

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Former Auth0 Employee

Ado Kukic

The CWI Institute and Google have successfully demonstrated a practical SHA-1 collision attack by publishing two unique PDF files that produce the same hash value.



---

**TL;DR** Researchers published a technique for causing SHA-1 collisions and demonstrated it by providing two unique PDF documents that produced the same SHA1 hash value.

---

[Secure Hash Algorithm 1](https://en.wikipedia.org/wiki/SHA-1) or SHA-1 is a cryptographic hash function designed by the United States [National Security Agency](https://www.nsa.gov/) and released in 1995. The algorithm was widely adopted in the industry for digital signatures and data integrity purposes. For example, applications would use SHA-1 to convert plain-text passwords into a hash that would be useless to a hacker, unless of course, the hacker could reverse engineer the hash back into the original password, which they could not. As for data integrity, an SHA-1 hash ensured that no two files would have the same hash, and even the slightest change in a file would result in a new, completely unique hash.

According to [Wikipedia](https://en.wikipedia.org/wiki/Cryptographic_hash_function), the ideal cryptographic hash function has five main properties:

* It is deterministic so the same message always results in the same hash.
* It is quick to compute the hash value for any given message.
* It is infeasible to generate a message from its hash value except by trying all possible messages.
* A small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value.
* **It is infeasible to find two different messages with the same hash value.**

In 2005, researchers discovered potential [vulnerabilities](http://www.darkreading.com/vulnerabilities---threats/researchers-warn-against-continuing-use-of-sha-1-crypto-standard/d/d-id/1322565) in the SHA-1 algorithm and by 2010 many organizations stopped it as it was deemed [insecure](https://www.entrust.com/understanding-sha-1-vulnerabilities-ssl-longer-secure/). The potential vulnerabilities had not been proven, until today, when CWI Institute and Google demonstrated a practical collision attack against SHA-1. The researchers were able to provide two unique PDF files that produced the same exact SHA-1 hash value.

> Auth0 can improve software security with the breached password detection feature. [This feature protects and notifies your users when their credentials are leaked by a data breach of a third party](https://auth0.com/breached-passwords). You can optionally prevent access until the user has reset their password.

![Data Integrity](https://images.ctfassets.net/23aumh6u8s0i/6C5jFby0JGDlbZ7q8iBkkr/d0d3957803a2ca66d39903e4b500b395/example)

<p><small>Source: <a href="http://shattered.io/static/infographic.pdf" target="_blank">shattered.io</a></small></p>

The team published a practical technique showing how to generate a collision bringing the fears that SHA-1 was insecure to reality. The technique outlined required years of research and immense computation resources. From the research published, it would take a cluster of 110 powerful GPU’s running computations 24 hours a day for an entire year to cause a collision or about 6,500 years on a single-CPU. So while this attack vector is fairly impractical, it is not impossible.

<include src="TweetQuote" quoteText="The SHA1 collision attack required 9,223,372,036,854,775,808 SHA1 computations."/>

This is a big deal because even though many organizations have stopped using SHA-1, underlying systems still often rely on SHA-1. Software updates, ISO checksums, PGP signatures, digital certificate signatures, git, and others still make use of SHA-1 for data integrity. If a malicious party were able to create a collision for a popular piece of software, for example, and distributed it on the web, they could infect many unsuspecting users causing all sorts of damage.

On the bright side, the typical user does not have to worry too much. Certification Authorities are forbidden from issuing SHA-1 certificates, and Google and Mozilla will warn users accessing HTTPS websites that use SHA-1 signed certificates. More and more organizations are using safer alternatives like SHA-256 for their cryptographic needs. Additionally, since the published attack vector has only been proven with PDF files, the team created a website, [shattered.io](https://shattered.io), which allows you to test your PDF files and see if they could have been compromised.

For most, security is not actively thought about, but for us at [Auth0](https://auth0.com), security is the only thing we think about. Ok, not the only thing, but it’s up there. In addition to embracing open authentication standards like [OAuth](https://tools.ietf.org/html/rfc6749) and [OpenID](http://openid.net/), we follow industry standards and best practices for security and when this popped up on our radar we just had to share it. Learn more about our security practices [here](https://auth0.com/security).

> [Auth0 offers a generous **free tier**](https://auth0.com/pricing) so you can get started with modern authentication.

For more info on the SHA-1 collision attack, be sure to check out [shattered.io](http://shattered.io/) and Google’s Security Blog [post](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html). If you are using SHA-1, please switch to a more secure hashing algorithm like [SHA-256](https://en.wikipedia.org/wiki/SHA-2).


"compromise"