37590801?s=460&v=4

Howdy! 🤠 I do technology research at Auth0 with a focus on security and identity and develop apps to showcase the advantages or pitfalls of such technology. I also contribute to the development of our SDKs, documentation, and design systems, such as <a target='_blank' rel='noopener noreferrer' href='https://github.com/auth0/cosmos'>Cosmos</a>. The majority of my engineering work revolves around AWS, React, and Node, but my research and content development involves a wide range of topics such as Golang, performance, and cryptography. Additionally, I am one of the core maintainers of this blog. Running a blog at scale with over 600,000 unique visitors per month is quite challenging! I was an Auth0 customer before I became an employee, and I've always loved how much easier it is to implement authentication with Auth0. Curious to try it out? <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 account</a> ⚡️.

Staff Developer Advocate

Dan Arias

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and mitigate password attacks like hash tables

Adding Salt to Hashing: A Better Way to Store Passwords

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Juan Cruz Martinez

This Valentine’s Day ditch passwords and fall in love with passkeys, the future of authentication!

This Valentine’s Day story is a love story, but like many love stories, it starts with a tragic breakup. Just yesterday I was writing a [breakup letter with passwords](https://auth0.com/blog/a-farewell-letter-to-passwords), it wasn’t easy, but necessary. Our relationship was going nowhere, and long gone were the days of butterflies and passion.

With my heart cautiously open, I decided to take a leap of faith. I'm embarking on a new love story, one built on trust, convenience, and affection, a relationship where I feel safe, where I can be myself, my face, my fingerprints, and not a random string.

My new love is passkeys, and maybe it’s again those butterflies in my stomach doing the thinking, but what’s not to be loved about passkeys?

As I write these words down, I want to celebrate what passkeys bring in for me, to our relationship, to my online identity, and to my protection:

- **An Unbreakable Bond**: Passkeys, through the magic of public-key cryptography, forge an unbreakable connection between me and my data. It’s like a padlock secured by something uniquely mine, like my fingerprints, my face, or one of my secure devices.

 A bond so strong that it can resist brute-force attempts, a bond so unique that it is breach safe, and a bond so close that it is phishing resistant.
- **Effortless Access**: I remember the frantic searches, the cold sweat dripping down my forehead as I desperately tried every password combination? With passkeys I can say goodbye to such anxieties! using a simple tap, a fingerprint, or a facial scan. Just like effortlessly unlocking my partner’s heart with a shared understanding.

- **Always By My Side**: No more worrying about forgotten passwords or locked accounts. Passkeys work across different platforms and devices, ensuring I’m always connected to my loved ones, just like an invisible link that keeps us together.

- **Sharing is Caring**: I can easily share my passkeys across my devices without compromising security. Passkeys offer seamless login experiences across devices and secure and convenient ways to grant access, just like sharing experiences in a healthy relationship.

- **Uniquely Yours**: Since I can’t reuse a passkey, they are unique per online service and account. When I create a new passkey, it’s tied to that specific domain.

I’m sharing my love story, in hopes it will inspire others. If you ever felt like me, and you think it’s time to ditch passwords and move on, [learn and adopt passkeys today!](https://a0.to/passkeys_blog).

<include src="LearnPasskeysCTA"/>

Reasons to Fall in Love with Passkeys

My farewell letter to passwords and why our relationship is not working anymore.

A Farewell Letter to Passwords

bonfida

Establishing your identity in a permissionless and censorship-resistant way using Solana. We give the power back to our users

Bonfida.sol

What about a single username for all the dapps that you have to sign up for? No passwords, no emails, just your SNS domain. One that is uniquely yours across Web3.

It’s no secret that an average internet user makes use of an array of emails, passwords, and username combinations spread across different apps to ensure logins. A process that prevails to be a logistical effort.

Today, however, we’re changing the game for Solana developers, their dapps, and users - to make the Solana “login” experience(s) a dream.

We present to you a tooling built by Bonfida and Auth0: **Sign-in with SNS** (SIWSNS). SIWSNS is a new authentication method for .sol domain name holders. A method that allows a domain holder to live interoperably, control their digital identity and build Web3 profiles under a single name across every dapp they interact with.

Following a few simple steps, developers are able to harness the power of Web3 domains and automatically populate the identities of users interacting with their projects. One that is secured by the technology of public-private keys and guarantees consistent identities across the space. Besides the security of this method, we are accelerating the onboarding process for users and enabling already existing personalities to nest themselves in the new projects they delve into. Carrying over their potential following.

This makes for a much simpler experience - where practically no information is required. Ultimately reducing the barriers to entry and stimulating a better and more convenient Web3 experience.

[View the Marketplace page for SIWSNS for developers.](https://auth0.github.io/marketplace-integrations/#/marketplace-integrations/preview/889/details/siwsns)

## A Better Experience for Solana Users

Domain names are unique. This means only one `[king.sol](https://king.sol/>)` and only one `queen.sol` can exist in our space. No, you don’t have to worry about signing into a dapp and not being able to use the same username you have on another.

Sign in with the Solana Name Service Powered by Auth0

Nabeel-Saeed

Nabeel is a product marketer focused on all things security and identity. He has contributed to publications like Wirecutter, Information Age, and Professional Security. He has also been a guest speaker at the Bay Area Cybersecurity Meetup, and delivered talks on IAM across the US, Canada, Israel, and Singapore. He is passionate about helping build secure auth experiences that amaze users and delight businesses.

Product Marketing

Nabeel Saeed

Secure apps and protect users with enterprise scale account takeover protection

It’s 2022, yet passwords still remain the [most common form of authentication](https://www.idrnd.ai/5-authentication-methods-that-can-prevent-the-next-breach/) online. Like it or not, they are not going away anytime soon. Even if they’re becoming riskier than ever. The very fact that there are so many more applications that users have to register for and log in to makes password reuse across multiple sites even more likely for all but the most security-conscious users. No wonder that the threat of account takeovers (ATOs) [nearly doubled in 2020](https://www.techrepublic.com/article/account-takeover-attacks-spiked-in-2020-kaspersky-says/).

Breaches impact everybody. The average email address is now associated with [130 online accounts](https://www.linkedin.com/pulse/b2b-identity-software-deep-dive-clement-vouillon/?trackingId=C11skBW3qNhNTv25nHkiEQ%3D%3D). Chances are that a significant portion of your users are using the same or similar usernames and passwords as they use on other sites. So when a password gets leaked in a data breach, that same password, or a slight variation thereof, has a high chance of being successful at multiple other online accounts that the user owns. Even if your own site hasn’t been breached, there’s still a good chance that your users' information may be compromised due to a leak that occurred elsewhere. 

![Improve Detection Response](https://images.ctfassets.net/23aumh6u8s0i/KbvD9MBeJw2z9YfGaC2Rv/567a40c8cb1cf8cdf565aa3827030351/Credential-Guard_crop1.jpg)

With [Auth0 Credential Guard](https://www.auth0.com/breached-passwords#credential-guard), you can protect your applications from bad actors logging in with stolen credentials. You can alert the user about their compromised password, challenge the user using an additional factor, or block access by forcing a password reset. Typical breached password detection relies on breach data released to the public. From the time when a breach happens to when it’s announced, there is a gap (typically months) during which your users and business remain at risk. Credential Guard eliminates this gap: a team of dedicated security experts infiltrates criminal communities and gains access to exposed data as soon as breaches occur. With this advantage, you can better protect your users and secure your applications by resetting stolen passwords sooner.

## Improve Detection Response

A typical account takeover attempt is performed using bots that hit login screens that use credentials obtained in data dumps that follow breaches. These indiscriminate attacks account for [90% of ATO attempts](https://spycloud.com/resource/targeted-vs-automated-ato/), yet only inflict 20% of the losses that business incur due to breaches. Targeted attacks, on the other hand, are disproportionately costly, even though they are far fewer in number. These attacks use sophisticated and clandestine methods of obtaining passwords, using these compromised credentials to inflict damage long before there is any traceable record of the breach. Traditional breach detection services that use scanners and scrapers to identify leaked credentials are therefore of no use when it comes to these types of attacks.

Credential Guard counters this threat with a team of security experts that infiltrate the dark web to mine out the exposed information before criminals can monetize it. This unique capability allows us to identify ATO risks months, even years before breach data is made public. Given importance of timeliness in identifying targeted attacks, companies can secure their applications during login by detecting and resetting stolen passwords as soon as breaches happen

![Expand Reach Globally](https://images.ctfassets.net/23aumh6u8s0i/5lO6E741lPvTK11haSvP5Z/1c5d39145aa0fbc1741f624bb50041c9/Credential-Guard_crop2.jpg)

## Expand Reach Globally

Breached passwords are not only a threat to the companies’ applications but also their users. As mentioned above, users reuse passwords across multiple sites, so it’s not just an account that’s at risk but their entire online identity. 

Credential Guard automates the detection and remediation of breached passwords across more than 35 languages and 200+ countries and territories for global account protection.

## Improve Security Posture 

We all have heard ad nauseum about the trade-off between user experience (UX) and security. Human psychology tells us that we make choices based on perceived threat. When a threat goes from being abstract to real, we’re much more likely to take it seriously and adjust our behavior to account for it. The same user that scoffs at stronger authentication methods when there is no perceived risk might enthusiastically sign up for the same measure if the choice is presented at a time when the alternative was to lose control of their account. Companies can alert a user that their password has been leaked in a data breach, and then offer to improve their security posture enrolling in MFA, without risking conversion, impacting UX or retention.

![Secure Your Login Box, Protect Your Users](https://images.ctfassets.net/23aumh6u8s0i/1sJJusx7kMMHjOgw5Bv4zY/c889e692d0bb0be2a2d35a230f0fa4bc/Credential-Guard_crop3.jpg)

## Secure Your Login Box, Protect Your Users

As security enthusiasts, we know that passwords worry both users and app owners alike. Yet they persist, and will likely do so for the foreseeable future. Using Auth0 Credential Guard, companies can stay ahead of criminals trying to exploit breached passwords. It protects companies as well as users’ online identities, which are increasingly bound up with a single, widely used password. While password protection is no silver bullet, making password protection part of a strategy to improve authentication choices, companies can reduce chances of being breached by [up to 89%.](https://www.verizon.com/business/resources/reports/dbir/) 

Learn more about implementing Credential Guard [here](https://auth0.com/docs/secure/attack-protection/breached-password-detection).

<include src="asides/AboutAuth0" />

Detect Breached Passwords Faster with Auth0 Credential Guard

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

New feature adds a dedicated security team and support for multiple languages to prevent fraudulent access with stolen credentials

**BELLEVUE, Wash. – February 9, 2022 – [Auth0](https://auth0.com/)**, a product unit within [Okta](https://www.okta.com/) (NASDAQ: OKTA), today announced the general availability of [Credential Guard](https://www.auth0.com/breached-passwords#credential-guard), a new security feature that helps enterprises prevent account takeover attacks by detecting and resetting stolen passwords faster. Credential Guard upgrades Auth0’s existing breached password detection with a dedicated security team, and support for more than 35 languages and 200+ countries and territories to reduce breach detection time.

Credential Guard gives application builders the tools to help secure their apps and to help protect their users from bad actors logging in with stolen credentials. Auth0’s breached password detection enables organizations to automatically screen for stolen passwords, and alert the user, prompt for additional verification, or block access by forcing a password reset. Credential Guard adds even more visibility and speed with a dedicated security team that infiltrates criminal communities to gain access to otherwise unavailable breach data.

Auth0’s security team conducted an internal test on 100,000 random usernames, and found that the ability to detect breached passwords (breach detection efficacy) increased by a minimum of 250% when using Credential Guard compared to an automated detection solution alone.

“The goal with Credential Guard is to help organizations detect breaches as soon as they happen, to reduce the risk to the business and its users,” said Shiv Ramji, Chief Product Officer at Auth0. “Traditional web scanners and scrapers rely on breach data being made public, which can be months or even years after the initial breach. Credential Guard enables security teams to shrink that gap, and better protect their customers’ digital identities on a global scale.”

Account takeover attacks with stolen credentials, targeting everything from sensitive healthcare data to loyalty points, are one of the most common and costly cyber threats. Verizon’s 2021 [Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/) (DBIR) found that 89% of web application breaches involve some sort of credential abuse (use of stolen credentials or brute force). Reusing passwords across sites increases the risk of an attack and makes it more difficult for organizations to prevent fraudulent access to user accounts. With Credential Guard, organizations can secure their apps and protect their users during the login process by detecting and resetting exposed passwords before they fall into the wrong hands.

Credential Guard is available as an Enterprise Add-on for existing Auth0 customers. For more information, please visit the [Auth0 blog](https://auth0.com/blog/detect-breached-passwords-faster-with-auth0-credential-guard/).

<include src="asides/AboutAuth0" />

## About Okta

Okta is the leading independent identity provider. The Okta Identity Cloud enables organizations to securely connect the right people to the right technologies at the right time. With more than 7,000 pre-built integrations to applications and infrastructure providers, Okta provides simple and secure access to people and organizations everywhere, giving them the confidence to reach their full potential. More than 14,000 organizations, including JetBlue, Nordstrom, Siemens, Slack, Takeda, Teach for America, and Twilio, trust Okta to help protect the identities of their workforces and customers.

### Media Contacts

Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 

### Investor Contact

Investor Relations 
[investor@okta.com](mailto:investor@okta.com) 

 
<div class="alert alert-info alert-icon">
 These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments nor all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials. Information regarding Okta's contractual assurances to its customers can be found at <a href="https://www.okta.com/agreements/">okta.com/agreements</a>. 
</div>

Auth0 Credential Guard Detects Breached Passwords Faster to Prevent Account Takeover

auziros:mckenzie-mayer

Customer Identity (CIAM) Product Comms lead, driving collective storytelling across Okta and Auth0. Making technology accessible for everyone.

Customer Identity Product Comms Lead at Okta

McKenzie Mayer

Global travel marketplace uses Auth0 to eliminate passwords and block suspicious login activity for millions of customers

**LONDON – 13 January 2021** –[ Auth0](https://auth0.com), a product unit within[ Okta](https://www.okta.com/) (NASDAQ: OKTA), today congratulates its customer, [Skyscanner](https://skyscanner.net), the global travel marketplace, on receiving the 2021 European Identity and Cloud Award for Customer Authentication, presented by [KuppingerCole Analysts AG](https://www.kuppingercole.com/). The winning customer identity project, designed to put travelers first with a simple and secure user experience, helped Skyscanner eliminate nearly all passwords for millions of customers, while blocking suspicious login activity that could signal an attack.

“Skyscanner’s mission is to lead the global transformation for modern and sustainable travel. This includes leveraging Auth0’s modern identity platform to give our customers a complete booking experience, while keeping their data secure,” said Brett Bunting, principal product manager at Skyscanner. “It is an honor and a privilege to receive this award from KuppingerCole, as we work to make booking travel safe and friction-free for everyone.”

Using the Auth0 platform, Skyscanner’s development team introduced [“passwordless” authentication](https://auth0.com/resources/whitepapers/passwordless-authentication), along with intelligent security features to detect and stop malicious attempts to access user accounts. Travelers can now sign up for a Skyscanner account simply and securely with just one click using either a one-time password (OTP) delivered via email, or Google One Tap, which prompts users to log in with their existing Google account. 

Skyscanner was also among the first to use Auth0’s Attack Protection suite to defend against breached passwords, suspicious IP addresses, and bots and scripted attacks, without adding friction for legitimate customers. Travel and retail brands are targeted most by brute force attacks, followed by organizations in the industrial services, government, and technology sectors, according to [Auth0’s 2021 State of Secure Identity Report](https://auth0.com/resources/whitepapers/state-of-security-identity-report). 

“Eliminating passwords and replacing them with strong yet adaptive and frictionless multi-factor authentication is the approach we as security experts have been promoting for years, and yet successful projects of this kind are still quite rare,” said KuppingerCole Senior Analyst Alexei Balaganski in his laudation at the award ceremony. “All this makes the project we honor today even more impressive, considering its sheer scale: Skyscanner serves millions of users from all around the world, seamlessly supporting a broad range of authentication options and protecting its customers and own infrastructure from cyberattacks.”

For the list of 2021 European Identity and Cloud Award winners, please visit the [KuppingerCole website](https://www.kuppingercole.com/eic-2021-awards).

<include src="asides/AboutAuth0" />

Skyscanner Wins KuppingerCole Customer Authentication Award with Auth0

kaycie-east

As PR Manager, Kaycie supports public relations and global communications efforts for Auth0 in the AMER region. When not promoting the Auth0 brand, Kaycie can be found hiking, traveling, or searching for the next best bite to eat.

PR Manager, AMER Region

Kaycie East

New feature removes the need for passwords and offers unique progressive enrollment features, paving the way for the ultimate user experience.

**BELLEVUE, Wash. – June 15, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of [Auth0 WebAuthn Passwordless](https://auth0.com/passwordless), an authentication feature that enables end-users to seamlessly log in with a biometric identifier — such as facial recognition or a fingerprint — as a convenient and secure alternative to a traditional password. Removing the need for long, complex passwords, Auth0 WebAuthn Passwordless provides a frictionless experience for end-users while reducing the significant password management burden for companies. 

<include src="WebAuthnMeCTA" group="B"/>

Today’s abundance of applications and systems have never had more access points, leaving organizations and their end-users vulnerable to attacks. A reliance on passwords as a primary means of authentication, combined with users’ tendency to re-use passwords across applications, presents a number of security, user experience, and cost issues. According to a [2021 Data Breach Investigations Report by Verizon](https://www.verizon.com/business/resources/reports/dbir/), compromised passwords are responsible for 84% of breaches. Passwordless authentication mitigates these challenges and offers increased security and trust for applications, devices, and services providers; faster and smoother login experiences for their end-users; and cost savings by eliminating the need for password management support. 

“Despite ongoing guidance around proper password creation and repeated warnings against password reuse, consumers crave convenience and continue to use the easiest and most convenient path for application access,” said Shiv Ramji, Chief Product Officer at Auth0. “A passwordless future is largely being driven by two primary forces — security and convenience. Companies want to secure the vulnerabilities that come with passwords, and they also want to offer their users a better digital experience. Auth0 WebAuthn Passwordless is a modern option for organizations looking to attract and retain users.”

With Auth0 WebAuthn Passwordless, users can authenticate with Web Authentication-powered (WebAuthn) biometrics, the official web standard for passwordless authentication as published by [W3C and used by FIDO](https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/), for first-factor authentication. This form of authentication eliminates security weaknesses based on password reuse since passwords are not required. Additionally, Auth0 WebAuthn Passwordless is an ideal option for companies looking to build and provide an authentication experience supporting conversion and retention of users who want more choice and less friction in their login experience.

Auth0 WebAuthn Passwordless eliminates the need for users to enter username and password credentials and enables simpler login with a biometric identifier such as facial recognition like Apple Face ID or a fingerprint scan on a mobile device or laptop. The biometric data remains stored on the device, alleviating privacy and security concerns for end-users. The feature also allows end-users to progressively enroll devices one at a time, as they use them, without needing a centralized portal, giving them the flexibility of having multiple passwordless authentication options — an advanced, unique capability that maximizes end-user adoption and enables a faster transition from passwords to passwordless, benefiting both end-users and organizations.

More detailed information on Auth0 WebAuthn Passwordless can be found here: [7 Things You Need to Know About Passwordless Authentication](https://auth0.com/resources/whitepapers/passwordless-authentication) (whitepaper) and on [Auth0’s blog](https://auth0.com/blog/freedom-from-passwords-with-auth0-webauthn-passwordless). 

[Auth0, recently acquired by Okta](https://auth0.com/blog/okta-acquisition-announcement/), provides a modern identity platform that helps organizations meet the security, privacy, and convenience needs of their users. Please visit [The Auth0 Identity Platform](https://auth0.com/identity-os) to learn more.


<include src="asides/AboutAuth0" />
### Media Contacts
Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 

Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 WebAuthn Passwordless Offers New Levels of Ease and Security for Modern Authentication

arthur-bellore

I’m a tech content creator. I enjoy breaking up seemingly complicated topics into easy-to-understand pieces for people to read. When I’m not in front of a computer, you’ll usually find me reading books.

Cybersec Writer

Arthur Bellore

Why GPUs crack passwords much faster than CPUs

CPUs and GPUs have different architectures and have different use-cases.

CPUs are the “brain” behind most of our electronic devices and are good at doing lots of different things. They are very general-purpose processors, coordinating the wide range of tasks your computer will do.

GPUs, on the other hand, are much more specialized computing engines. They are designed to handle the processing of 3D images efficiently, but rendering graphics is pretty much computing loads of matrix arithmetic.

The types of computations that GPUs excel at are called parallel computations: tasks that can be broken up into smaller, independent computations and be performed simultaneously.

The concept can be visualized in this [1:30 minute video](https://www.youtube.com/watch?v=-P28LKWTzrI), where Mythbusters Adam Savage and Jamie Hyneman show a painter-robot they built to illustrate how parallel computing works.

Generally speaking, the more a task can be broken up into smaller independent pieces, the faster, the larger calculation will happen. And the number of pieces the original task can be split into is largely determined by the number of cores present on the GPU.

If you look at the number of GPU cores over the years, you will see that they have been increasing exponentially in the past few years. And while most CPUs top out at a few dozen cores, GPUs have thousands of cores. The latest high-end GPUs from Nvidia has more than 10,000 cores.

This unparalleled growth led developers to start exploring the capabilities of GPUs to more than graphical processing, in what is now known as “general-purpose computing on GPUs” (GPGPU).

To aid developers in making use of their GPUs full capacity and allow the CPU and GPU to process data bidirectionally, Nvidia created CUDA, a software platform that makes it easier for developers to build applications using APIs.

They are always collaborating with developers to refactor the algorithms used in their applications to make the most use of Nvidia’s hardware. The result is very good integration with widely-used applications, such as Adobe Photoshop CC, Adobe Premiere CC, and Autodesk Maya.

![Security](https://images.ctfassets.net/23aumh6u8s0i/32itEoNZjHq0aRwM52iGLS/7e87c99c5af5913d84af97ed2ddba5ef/security-sep1.jpg)

CUDA can be downloaded for free, but it requires an Nvidia GPU to work. There is also an open-source alternative, OpenCL, which is the primary framework for graphics processing on AMD GPUs. Nvidia supports OpenCL, but with CUDA being developed to run with Nvidia hardware in mind, it has better performance when run on Nvidia GPUs.

These platforms allow developers to make extensive use of GPUs in applications other than graphic processing that would highly benefit from parallel computing, and password cracking is one of them.
Password cracking is what we call an embarrassingly parallel task. An embarrassingly parallel task is a task that can be trivially broken up into smaller pieces, where the computations on each piece are independent of the results of their "neighbors'".

Consider a scenario where you want to add two 20x20 matrices by hand. You summon up 19 more friends and tell them that each one of you will be responsible for calculating the results of a single row, and then you’ll merge the results back together into a single matrix.

Since the arithmetic of each element in a matrix can be performed independently, you can carry on your own calculations without interfering with the calculations’ of your friends; all of you can make your calculations “in parallel.”

Password cracking is an [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel) task because it works under the same principle. I’ve written about how passwords are cracked in more detail, but here’s how it works in simple terms.

Say an adversary obtains a database with 1 million different hashed passwords that they wish to crack.

For simplicity’s sake, let’s assume:

* They know the application limits user passwords to 10 characters.
* They can only try to brute-force passwords (assume no dictionary, no masks, and no rainbow tables)



To crack all passwords, they’ll need to load a list of all hashes they’re trying to crack on memory, hash some character combination using the same hashing function that was used to hash the passwords on the list and see if it matches up with one of the hashes on memory.

They will have to repeat this for all character combinations, up to all 10 valid characters.

If they instruct the CPU to go through a list of all possible combinations, the CPU will calculate the hashes roughly linearly, – even though it's possible to make computations in parallel on a CPU, the number of cores are very limited when compared to GPUs.

However, the result of a single hash calculation doesn’t affect any other hash calculation, so we can speed up this process thousands of times by computing them in parallel. Not only that, you can increase the speed even more by utilizing a cluster with multiple GPUs.

Parallel computing has many other applications, many of which are extremely valuable to society, such as weather prediction for agriculture, public transportation, and identifying spam.

This is why Nvidia and other manufacturers have been investing heavily into this field in the past decade, and the trickle-down effect of these advancements will continue to affect password cracking.

## FPGAs and ASICs

Increasing the hashing speed by a factor of 100 by using GPUs is bad news for people who are trying to store passwords securely.

But not all hashing algorithms are vulnerable to GPU-accelerated attacks.

To make hashing algorithms more resistant to such attacks, developers try to make algorithms use a lot of memory as a way to increase the attack’s computational cost.

`bcrypt` is one of these algorithms.

When a computer is calculating a bcrypt hash, most of the time is wasted waiting for the next instruction to come from the slower memory to the faster memory (more on this in a bit) rather than computing the hashes.

FPGAs and ASICs, are two other types of computing devices that play a crucial role in parallel computing.

FPGAs, or [field-programmable gate arrays](https://en.wikipedia.org/wiki/Field-programmable_gate_array), are integrated circuits that can be reprogrammed for specific tasks after manufacturing. Its hardware can be optimized for a specific application.

This, in turn, allows for massive parallelism while using much less power, even though the clock speeds on these chips are much slower than those of modern CPUs.

ASICs, [application-specific integrated circuits](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit), on the other hand, are integrated circuits that are “fixed,” but are application-specific. The hardware is designed with one application in mind and can do nothing else, but they do what it was designed to do extremely well.

GPUs are, actually, an example of specialized ASIC chips. In the beginning, they were created to deal strictly with the kinds of computation a chip would have to deal with rendering tasks. It was only after some time, in the late 2000s, when CUDA came out, that they started to become more programmable.

![Security](https://images.ctfassets.net/23aumh6u8s0i/7tPHfTXvBIRVXHFhMHD0gz/571d90bda5d9080e34b4eebe6f8866e8/security-sep2.jpg)

The downside is that designing custom chips is expensive since you’ll have to eat the costs for research and development on top of the manufacturing costs.

To justify the investment for a manufacturer, there must be a large enough demand for chips like these. Alternatively the chips must aid in some kind of profitable activity to the buyer, so they can have a return on their money.

That’s why you’ve probably heard of Bitcoin mining ASICs. These chips can only do one thing: calculate double-hashes of SHA256, and there’s enough profit in mining Bitcoins currently, to justify its manufacturing.

Somewhere in the early 2010s, mining ASICs became the de _facto_ standard hardware of Bitcoin mining rigs, dethroning the clusters of multiple high-end GPUs because they were much more effective in doing that one thing.

## Can Bitcoin Mining ASICs Be Used to Crack Passwords?

As I said, ASICs are designed from the ground up with one task in mind, and in the case of Bitcoin mining rigs, that task is calculating double-hashes of SHA256.

Those rigs can’t do anything else but that. Unless the passwords your adversary is trying to crack have been double-hashed with SHA256, which is unlikely, those rigs are useless.

It’s an impractical (but not impossible, and may be a reality in the future as technology becomes more commoditized) attack model to have a rig like this for cracking passwords because the ASIC chip configuration might not match the parameters that the application developer used to store the passwords.

An adversary would need one ASIC rig set up for **each hashing function**, and for configurable functions such as bcrypt, **each probable parameter combination**. Not only that is hard to do from a development point of view, but the attack would also have to make sense financially.

## FPGA Rigs for Cracking Bcrypt Passwords

Even though FPGAs are less efficient than ASICs for a specific use such as calculating hashes of a specific algorithm, they make up for it by being cheaper and more versatile.

Let’s see how FPGAs can go beyond the limitations of GPUs when cracking bcrypt.

For general hashing functions, such as SHA1 and MD5, a GPU will probably farewell, since these algorithms don’t force memory bottlenecks as they weren’t intended for storing passwords.

To compute a bcrypt hash, the processor will have to constantly access instructions that are stored in memory. Each core has a fast, but small amount of memory (L1 cache). If there’s insufficient space on the L1 memory to compute the hash, the data will have to be stored on the slower, main GPU RAM that’s shared amongst all cores.

There is a cost to transferring this data, and this creates a huge bottleneck in the number of hashes per second a computer can calculate. Most of the time, calculating bcrypt hashes is wasted waiting for data to come from the main memory to the faster memory so that the hash can be computed.

> This is not a problem for FPGAs because they have more than enough L1 memory to deal with bcrypt hashes.

The team behind [Scattered Secrets](https://scatteredsecrets.medium.com/bcrypt-password-cracking-extremely-slow-not-if-you-are-using-hundreds-of-fpgas-7ae42e3272f6), a password breach notification service, wanted to test this, so they built a cluster of FPGAs capable of cracking bcrypt about 35 to 40 times faster than current high-end GPUs, and using only about 5% of the power.

Using an RTX 2080Ti as a benchmark, they got 54 thousand bcrypt hashes per second on their testing rig, while the rig they built with 18 quad Spartan-6 LX150 FPGA boards and cranked out 2.1 million bcrypt hashes per second.

Mind you, these are not state-of-the-art FPGA chips: they were introduced back in 2011. These boards were the tool of choice because they supported Jack The Ripper, a popular password cracking software. As password cracking applications begin to support newer chips, the speed of these attacks will only increase.

## Looking into the Future

Elon Musk already said that machine learning and AI will be at the forefront of our technological development at least for the next decade, and they rely heavily on parallel computing.

There will always be financial incentives to develop new technologies to solve complex problems we face as a society. The numbers of GPU cores grew from 1 core in 1995 to 24 cores in 2006, then exploded to 128 cores in 2009 and continued to grow exponentially to over 10,000 by 2021.

As new technology arises, we have to keep an eye on how they will change the security landscape, because it’s a game of cat-and-mouse between the good and bad guys.

> One of the most promising future developments in parallel computing is quantum computing.

As we approach the end of Moore’s Law (which states that the number of transistors in microchips doubles every two years), researchers are trying to find ways to continue to increase exponentially the pace at which we can make complex calculations. Quantum computers can completely revolutionize artificial intelligence, drug research, and, of course, the security industry.

In my next article, we are going to talk about how quantum computing works and what it means to the security industry.

How Parallel Computing Will Affect The Security Industry

A closer look at the world of passwords: Tricks, tips, tools, and other stuff to choose a good password in your apps.

This is the second part of our password series. In [part 1](https://auth0.com/blog/defending-against-password-cracking-understanding-the-math/), we talked about how passwords are cracked and what makes them easier or more difficult to crack depending on the type of attack, information an attacker has about you, etc.

If you're familiar with the power of two notations, entropy, sample space, and uniform randomness, I think you'll understand most of what I'll talk about below... if not, I highly recommend you go read the first part of this article before you read this one.

Before I present you what I think are good solutions to the password problem, let's talk about what are "bad passwords" first. One, so it's fresh on your mind while you read and think of ways to avoid them, and two, because I think you'll appreciate the suggestions more if you know what problems they solve.

The goal is that, by the end of this article, you will have all the necessary tools to create an uncrackable password. (While nothing is 100% secure, what lies ahead is the gold-standard when it comes to password creation today and should last for a very long time.)

## What Pitfalls to Avoid When Creating Passwords

Is there such thing as a password too strong? We can answer that question in two ways: a practical one and a mathematical one. The mathematical is out of the scope of this article, so we'll look at it from a practical point of view today.

Consider, for instance, a password with 250 bits of entropy. Despite how big that entropy is and how secure it may look like, a password that strong would need some 40 (the minimum possible N when using all 95 valid characters so that 95^N is equal or greater than 2^250) randomized alphanumeric characters, _and that makes it a horrible password for regular users_.

<include src="TweetQuote" quoteText="Avoiding password pitfalls is all about identifying unintended risks or consequences that can arise with the password you choose, despite it being a strong password."/>

The example above would be so cumbersome to use that dialing down its strength to "secure enough" would make it a better password.

There's a sweet spot to a good password &mdash; that depends on your personal preference, and we'll also talk about that &mdash; and finding that spot is what this article is all about. Below we're going to go over a few of those elements that are important to fine-tune when creating a password.

### Security theater

When people realize they have poor passwords, they tend to have one of two possible reactions, in my experience:

1. Continue choosing poor passwords. Not by choice, but because they don't _actually_ understand how passwords are exploited. They even change the password, but it's equally bad as the one they had originally;
2. Go to the other extreme and create prohibitively difficult passwords when they don’t need to.			 					

Option #2 is a good example of security theater: choosing an over-the-top one when a shorter would suffice – tactics that do little or nothing to increase your security yet feel like they do. Past a certain point, there's little to no gain in increasing length, even more, when the adversary would use easier alternatives to attack the user.

This is something that hits close to home because it's something I was guilty of.

Years ago, I decided to use an alphanumeric password instead of a numeric passcode on my phone. Not only that &mdash; at the time, I was not as well-versed in the arts of password-making &mdash; I thought that password length was the most important thing to keep in mind and opted for a 30-character password.

As you can imagine, it was extremely annoying to have to type a password that long, make a typo, and have to do it all over again, often multiple times. So annoying that I decided to change the password to something way easier to type by repeating a few characters multiple times until it added up to the (completely arbitrary) length of 30 characters.

That "helped" for a while but still was too much of a hassle, and over time I found myself unconsciously leaving the phone unlocked for longer so I wouldn't have to type the password every time I wanted to check something. Sometimes I'd even get up and leave it unlocked on my desk before realizing much later what I had done.

Eventually, I realized that trying to use a 200-bit password made it, paradoxically, less secure than, say, a 100-bit one (we'll talk about ideal strength in a moment).

Not only I was walking around believing my phone was secure because I had this huge password (despite it being one that I created myself, and probably susceptible to the biases we talked about in the previous article), but my attack surface _increased_ as it made me more likely to take risks I normally wouldn't out of annoyance.

There are mechanisms put in place on iPhones that makes brute-force attacks harder to pull off so that you don't need to go to the same lengths to protect it as you would if you were worried about remote attacks:

* The perpetrator would have to get physical access (instead of a database dump from the Internet) to your phone in a one-hour window since you last unlocked it (this is a security feature Apple implemented to prevent brute-force attacks);
* Apple entangles the cryptographic key with the device UID multiple times using the PBKDF2 algorithm. The number of iterations is calibrated so that one brute-force attempt takes a lot of time (approximately 80 milliseconds);
* You can set up your iPhone to wipe out everything after ten failed attempts (that's why having a working backup is a crucial part of any security strategy).

![Security](https://images.ctfassets.net/23aumh6u8s0i/4sojwhheCn0q4sCdNRzvAk/607e85cf08ad9cc7aa4e1170a2eb5e2f/01_security_encrypted)
Credit: <a href="https://xkcd.com/538/">xkcd.</a>

After reaching a good-enough point for your password, you'd be better off addressing other ways an attacker might be able to exploit your passwords.

### Usability

As illustrated before, you have to consider where that password is going to be used.

Are you going to use it on your phone, where you'll tend to type with one hand while fumbling your coffee with the other, or are you only going to type it on your full-sized keyboard at home? Do you use your phone frequently, or just once or twice per day?

Another thing you have to consider is your preference when it comes to length or complexity. Do you prefer longer but simpler to type passwords or shorter but more-complicated-to-type ones? Both options can be equally secure, but one will appeal more or less to different folks.

Even if you use both hands, it can be quite complicated to type symbols on small touch keyboards &mdash; you have to press Shift multiple times, and in many instances, it takes much more time to type two or three symbols than one entire English word.

The more usable a password is, the more likely you are to keep using it. You want to increase its usability as much as possible. Note that this doesn't mean you should reuse passwords across different applications (use a password manager instead), but that you should make deliberate decisions to decrease the likelihood of you giving up before your new password becomes second nature.

There is a quote circulating among Security Stack Exchange circles that encapsulate this very well. It's known as "AviD's Rule of Usability":

<include src="TweetQuote" quoteText="Security at the expense of usability comes at the expense of security."/>

### Easiness to remember

A great password has to be easy to remember. An easy-to-remember password will give you confidence that you can memorize it eventually and will avoid situations where someone needs you to unlock your accounts on the spot.

Note that whether passwords like `sBt$][p'_3d {+@:(b-i(-y> H'x&'a)K` are easy to remember or not depends on the person &mdash; I've met people who had zero problems creating mnemonics to memorize passwords like that, and I've met people that aren't too keen on them.

If that's hard for you, consider using **passphrases**: a list of real words strung together, such as `swell posing gruffly slander onto`. We'll talk about a method for creating passphrases like this further down below.	

## How to Create Great Passwords

With the pitfalls out of the way, let's talk about how to create great passwords.

A great password is one that has sufficient entropy, is resistant to dictionary attacks, and avoids all the previously mentioned pitfalls. The first thing we need to determine is what is sufficient entropy so we can determine the minimum length to avoid brute force attacks.

### How long should it be?

Even though using entropy to measure password strength has some drawbacks, as we've talked about in the first installment of this series &mdash; if you can guarantee the password was generated uniformly and randomly — entropy is very useful because it gives you a number that we can compare against different benchmarks; we can quickly determine if a particular password is "out of reach" or not.

For example, the NIST, which is responsible for providing scientific standards in the US, used to recommend 80-bit passwords for **cryptographic secrets** (government documents, etc.) and updated that to 112 bits in 2014.

For comparison, the French equivalent to the NSA, ANSSI, [rates passwords](https://www.ssi.gouv.fr/administration/precautions-elementaires/calculer-la-force-dun-mot-de-passe/) up to 64 bits as "very weak," between 64 and 80 bits as "weak," between 80 and 100 as "moderately strong," and above 100 as "strong." They require a minimum of 100 bits when it comes to passwords or secret keys for encryption systems that must be secure.

So, if you're using all 95 characters (lowercase and uppercase letters, numbers, and symbols), the minimum length your password must have to have an entropy of 80 bits is 13 characters.

But we also need to be able to resist dictionary attacks. The password `Passw0rd1234!` has 13 characters and a theoretical entropy of 85 bits, but it's a horrible password because it's a permutation of a known word (and also a widely used password).

To avoid dictionary attacks, you need to use words that aren't real, i.e., a string of gibberish created by a cryptographic generator or _passphrases_.

### An Alternative: Diceware Passphrases

Diceware passphrases consist of a list of words that you can create randomly by throwing a fair dice five times, then comparing the result with a word list to come up with real words.

The list is provided on the official [Diceware website](https://theworld.com/~reinhold/diceware.html) and has 7,776 words in total, all possible permutations of five dice throws. The resulting passphrase will be something like `rewrite Celtic life raft armed`.

For example, say you roll a dice five times, and the results are six, one, four, six, and one. If you look up `61461` on the word list, you'll find the word `tori`. And then you'll have to repeat that for as many words as you want on your password.

Some people might be worried that the dictionary of possible words is publicly available, but it doesn't matter. Think about it: the attacker also knows the valid characters in your keyboard when you create a regular password.
What's difficult to guess is the order in which they go. The Diceware method swaps the 95 possibilities of a keyboard for 7,776 possibilities (i.e., the words).

Representing that in bits, we have that `7,776 = 2^12.92`, or that each word has around 12.92 bits of entropy. If you choose five words, that's `7,776^5` possibilities or `12.92*5 = 64.5 bits` of entropy. A six-word password has about 78 bits of entropy and a seven-word one about 90 bits.

The beauty of Diceware is that you are converting real randomness into a passphrase; you know exactly how strong it is. This method essentially turns a dictionary attack into a much more computationally-intensive brute force one.

A passphrase generated through this method avoids many of the pitfalls we talked about before: you can choose just how strong you want it to be by adding or removing words, it's easy to type on your phone, and for most people, it's easier to remember than a random string.

![Password Strength](https://images.ctfassets.net/23aumh6u8s0i/6TopClFD6DfGj23Tk1SjiR/699968f99e11bc9ba97df9af238f98c8/02_password_strength)
That's too short to be a good passphrase. Credit: <a href="https://xkcd.com/936/">xkcd.</a>

And you don't need to buy dice if you don't have any lying around. You can use a random numeric generator for this, and it's sufficiently secure for most people.

The physical dice only certifies that your password wasn't tampered with (for example, if your computer was compromised when you created your password) and that nobody spied over your shoulder.

### Other Word Lists				

There are word lists available in other languages available on the official website. They aren't any less or more secure, just in a different language. You should use the language you're more comfortable with, as those will be easier to type and remember.

There are alternative English word lists with a few different attributes as well. The most well-known of those is perhaps the EFF list: it uses more common words, but they are longer on average.

It comes down to personal preference. You should check the [official EFF article](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases) to compare both lists.

Driving home the point on security theater: mixing additional dictionaries doesn't make your passphrase more secure. If you mix three dictionaries, that will give an additional 1.5 bit of entropy per word... at that point; it's better to just use a single dictionary and tack an additional word at the end.		

## Diceware vs. Random Strings

While you can choose either method, as both are equally secure, it may make more sense to use one over the other depending on the situation.
					
For example, some websites limit the password length you can use – iCloud limits passwords to 32 characters.
					
This makes it impossible to create a Diceware password with satisfactory entropy – you'd be better off using a random string even if you prefer Diceware passphrases.		
On the other hand, if it's a password, you can see yourself having to share with other people (e.g., the WiFi password), then telling them a list of words is way easier than spelling a 20-character string out loud.				
The same goes for situations where you can't use the auto-fill feature of your password manager and are forced to copy the password by hand: much better to have a list of words.

## So, How Strong Should Your Password Be?

Regardless of which method you prefer, you should consider using a password manager to generate and store different passwords for the different services and websites you use.

You choose which one you choose is up to you since different applications will appeal to different folks: for example, some people don't like storing their passwords on the cloud, while others enjoy the convenience.

(Keep in mind that not all password managers have passphrase generators, though, so that's something you'll have to look for when choosing one if you haven't already. KeePassXC has a Diceware generator that you can use alongside your cloud-capable password manager if it can't generate Diceware passphrases and you wish a convenient way to create them without dice.)

What's important is that your password manager will store all of your passwords for you, so it doesn't cost you anything to have 128-bit passwords for every website on your vault (length limits permitting)... so you can go ahead and 128-bit passwords for those.

And what about your master password? Well, it'll depend on your threat model and how well you are able to balance the things we talked about in this article.

Here are some entropy targets for your master password and situations where you can't use a password manager: 90+ bits (seven Diceware words) is secure, and probably the minimum you should strive for; 100 bits (eight words) is really secure, and 128 bits (ten words) will probably be secure until (or if) quantum computing becomes a thing.

Creating Great Passwords

Take a look at the math behind passwords, and how passwords are cracked.



You've probably stumbled onto websites that have password requirements: they might require a minimum number of characters, or perhaps a number and a symbol.

But does that really make a better password?

Despite their best intentions, policies lead people to choose horrible passwords. Evidence suggests that people are annoyed when such arbitrary measures are put in place and end up choosing weaker passwords.

This happens, in part, because most people don't know how their passwords are actually exploited. Even after many cries from the cybersecurity community, many people still believe swapping letters for a numerical equivalent ("l33t" speak) makes their password harder to crack (i.e., when the adversary has possession of a database of hashed passwords &mdash; an offline attack), when in fact it does nothing.

Users are then left with two problems: an insecure password and a false sense of security since the password looks complicated to them, but it's easy for a computer to crack.

By helping you understand how exactly passwords are cracked and the math behind it, you will be in a better position to create or instruct other people on how to create good passwords.				

## It's All in the Space

Let's say an attacker stole your credit card without you noticing and wants to withdraw money from your bank account. (Let's also assume the bank won't freeze your credit card after five or so failed attempts, as it's common practice today.)

And like most banks, let's assume your bank requires a 4-digit PIN to let you withdraw money from an ATM.

What are the chances that he guesses your password correctly, by pure chance?

Well, the first digit of your PIN can be any number between 0 and 9, so there are ten possibilities in total. Since there's no restriction in place for the second digit that would limit his choices (e.g., if you couldn't create a PIN with repeated numbers), there are also ten possibilities. And the same thing is valid for the third and fourth digits.

In total, there are 10 x 10 x 10 x 10 = 10,000 possible passwords, one of which is your password. The chance of an attacker correctly guessing your password by pure chance would be 1 out of a sample space of 10,000 passwords.

Now, this is not entirely true in practice because humans can't pull a number combination &mdash; or anything &mdash; out of their minds randomly. We are hostage to our brains' biases.

We tend to follow predictable patterns, even if it feels to us like we came up with random numbers: we tend to use sequential numbers, we are more likely to think in groups of two or four numbers because of our date system, etc.

What happens, in reality, is that a subset of those 10,000 possibilities happens much more frequently in the real world &mdash; 1234 or 1111 end up appearing way more than, say, 8065.

However, while it is pretty unlikely that the thief will have enough time to type in 10,000 combinations in an ATM, a regular computer today can make tens of billions of attempts per second. A 4-digit PIN would be cracked instantly.

To make it as hard as possible to crack your password, you have to increase its sample space as much as possible (it's harder to guess the correct password out of a trillion possibilities than a thousand possibilities).

## How to Calculate the Sample Space of Your Password?

If you look back at our example, you'll see that we calculated the sample space by multiplying the number of **allowed characters** for **each digit allowed**. We had ten valid characters as input for each digit, so 10 x 10 x 10 x 10 or 10^4.

To calculate the sample space of a password, we can use the following formula: S = C ^ N.

Where S is the total number of possible passwords, the sample space, C is the number of characters in the pool of characters available to us, and N is the number of characters our password has.
						
![How to Calculate the Sample Space of Your Password](https://images.ctfassets.net/23aumh6u8s0i/3xu4JBsRSYyDSVJ7aU94u3/fa70c58eeea8638f697a00e98369fb7f/table_1)

If you choose a password that only has lowercase letters, then **C = 26**; if it has lowercase and at least one uppercase, then **C= 52**, and so forth.

Let's compare different passwords and see how their sample space compare with each other:

```
Example: czvpgp
C = 26 (lowercase only)				
N=6
S = 308,915,776 or about 309 million passwords combinations	
```

Let's see what happens if we introduce all other characters type and leave the length at 6 characters:

```
Example: -@}"Bt=:6 
C = 95			
N=6
S = 735,091,890,625 or about 735 billion password combinations
```

Now let's see what happens if we use only lowercase letters but increase the length to 15 characters:

```
Example: tuubbxvhyexmgow 
C = 26		
N = 15
S = 1,677,259,342,285,725,925,376 or about 1.7 million million billion passwords, 
approximately 2.28 billion times greater than -@}"Bt=:6, our last example.
```

We can see here that what makes a password hard to crack is not whether it has symbols or not, or numbers or not, but its sample space. You can make the sample space bigger with length or with more characters. The bigger the sample space is, the harder it is to crack the password.

We'll have a look at which option is preferred when we talk about crafting a great password in the next part of this article.

## Measuring Password Strength: Entropy

It's very hard to quantify exactly how difficult a password is to crack without knowing how it was generated (e.g., randomly or by a human) due to the biases we talked about earlier.

But it's very useful having a number that tells us at a glance whether password A is harder to crack than B, and that number is expressed in **bits of entropy**.			

Think of entropy as a measure of how big is the sample space that a particular password was taken from. High entropy is harder to crack; low entropy is easier to crack.

Note: when you think of a decimal digit, there are ten possibilities (0 through 9). In a binary digit, a bit, there are only 2 (0 and 1), so a bit represents a space of 2 possibilities.

A bit represents a sample space of 2 possibilities, so an entropy of 50 bits represents a space of 2 x 2 x 2 x 2... = 2^50 possibilities (similar to how our 4-digit PIN represented a space of 10^4 possibilities).

A password with 50 bits of entropy is said to be drawn uniformly from 2^50 possible distinct passwords. A password of 51 bits is drawn from a sample space of 2^51, which means it's twice as hard to crack as a 50-bit password.

To calculate the entropy of a password, you have to calculate the size of the sample space of a password using the formula we saw above and then convert it to "power of two notation" (which is how bits are represented) using the following formula:

```
S=2n ⇔log2S=n
```

So, if the password was generated uniformly and randomly, the entropy can show you at a glance how many tries it would take to brute force your password.

It's worth noting that while it would take 2^50 attempts to go through all possibilities of a password with 50 bits of entropy, a brute force attack probably wouldn't need to go through all combinations to eventually land on the right one.

So when assessing the strength of a password, we consider the "expected number of guesses" instead: how many guesses it takes to have a 50% chance of guessing the password. In the case of a 50-bit password, that means 2^49 guesses.

## High Entropy Is Not Enough

The problem with using entropy as a measure of password strength is that it works for as long as all the possibilities have the same chance of being the correct one.

If a human is tasked with creating an 8-character, lowercase-only password, then a password like a password would be way more likely to come up than vcwcyqyu – but we don't know how much more likely. This heavily skews the probabilities and makes it very difficult to estimate the password's real entropy.

That's why we can't just consider the size of the sample space to calculate the entropy.

There are solutions at the disposal of developers to warn users of such risks; two well-known being Have I Been Pwned (HIBP) and zxcvbn.

HIBP aggregates known password breaches into a database that services can check against. That way, developers can notify the users that their password has been compromised as soon as a new breach is added to the database or even when the user is first signing up for the service.

Naturally, a shortcoming of HIBP is that it's a "hard" penalty: you can only flag bad passwords if they appeared in a breach at some point. But it doesn't take into consideration the biases we talked about before. Zxcvbn tries to address by weighing and penalizing different patterns: common names, dates, keyboard patterns, etc.

## What's a Password Hashing Algorithm?

If webmasters stored the passwords in plain text on their server and an attacker managed to get access to it, they would have the passwords straight away, no matter how strong they are.

That is why it's highly recommended that passwords are salted and hashed before being stored. Instead of the password itself being stored, we compute a "fingerprint" of the passwords, generated by a hashing function, and store that hash.

Hashing functions are pseudo-random, one-way functions that make it computationally infeasible to "reverse engineer" the password from the hash (i.e., the "fingerprint), and there are many algorithms we can choose from to compute these hashes.

For example, here's the SHA-1 hash for czvpgp, our first password from the previous section: `b5162e4e38acb4a04120aa6efdd4b4ae9c699935`.

And here's the SHA-1 hash for 8065: `1797dff2748ea5c11e32e3de845673b96c1b89fa`.

Now, SHA-1 is not a good enough algorithm for today's standards, and you should never use it to store passwords – you have better options at your disposal, like bcrypt.

However, from a defensive standpoint, you can't assume that your passwords are always going to be hashed with bcrypt, and SHA-1 is still common-enough that you will have to "defend" against it. For that reason, we're going to assume a worst-case scenario and proceed using SHA-1 as an example.

So, going back to the scenario we laid out above: the attacker would have a list of hashes instead of passwords. But if hashes can't be reversed, how are passwords cracked?

## How Passwords Are Cracked

We know that it's impossible to solve the hash back to it's plain text form. But what you can do, however, is to hash every single possible password of that sample space and see if their hashes match up with your target. If they do, then you cracked their password.

Now, it takes some computational power to hash these passwords, and some hashing functions are more computationally intensive (harder to compute) than others, making them **more time-consuming** (sometimes, infinitely more) to crack.
	 	 	 	
That is why SHA-1 is a poor choice: computers today can calculate SHA-1 hashes too quickly. An attacker can go through a list of SHA-1 hashes much faster than they would if it were a dump of bcrypt hashes, for example.
			
Like I explained earlier, the bigger the sample space of your password, the more possibilities your attacker has to try hashing before he finds the correct one &mdash; in some cases making the attack infeasible (e.g., so big it would take hundreds of thousands of years to crack).

This is called a brute force attack. The attacker is trying to guess the correct password at random out of the possible passwords on the sample space.

However, this method is not very common because it's incredibly inefficient. It's only really useful if your password is very short &mdash; say, shorter than eight characters, or if the attacker knows you used a limited set of characters (e.g., only numbers, etc.).

For longer passwords, attackers have to make some assumptions about the way people make passwords. Like I mentioned, in the vast majority of cases, our choices are weighted towards certain tendencies of human behavior.

They create a dictionary of commonly used words, patterns, and passwords, like password, and then try those and see if the hashes match up. And then they manipulate it slightly, like passw0rd, and then try those. And then we append words and try once again. This process makes guessing the correct combination insurmountably easier.

It's for this reason that Password1, from a brute force standpoint, would be a slightly above average password; it has nine characters and 62 characters possibilities and a theoretical entropy of around 53 bits.

But in reality, it's a horrible password because it's a variant of one of the most common passwords out there. If you were using a password strength estimation tool that accounted for common passwords, a password like that would receive a **nasty** penalty; probably down to 0 bits of entropy.

These attacks are called dictionary attacks. Instead of brute force blindly, we use computational power to create variations on top of words people are most likely to use: words they know or passwords used before by other people.

That's why data breaches are so valuable: they not only provide private information that criminals can use for malicious purposes &mdash; extortion or social engineering &mdash; they also provide the best dictionary possible: actual passwords people are using!

## Time to Crack

As we've learned by now, the whole point of choosing a hard password to crack is to create a password that would take so much time to crack it wouldn't be worth it &mdash; something like 900 million years.

And how do we know much time it would take to crack your password? Well, it depends on a few variables: the hash rate of your attacker's computer (how many hashes it can calculate per second), the attack mode used, the hashing algorithm used, etcetera.

A motivated individual with consumer-grade gear could put together a cluster capable of 170 billion unsalted SHA-1 (the same used by LinkedIn at the time of their infamous leak) hashes per second.

To estimate how much time it would take to crack your password, use the following formula:	

```
T = S/(A*6.308*10^7) (in years)			
```

Where S is the sample space and A is the number of attempts per second. This number will change with your hardware.

A great place to estimate hash rates for different hashing functions is Hashcat's forum. Hashcat is a software dedicated to cracking passwords, and users frequently post benchmarks along with their computer's specs.

Naturally, this is assuming the attacker doesn't have access to enterprise-level or state-sponsored clusters; those have a much higher hash rate. (In 2013, Snowden suggested the NSA could make 1 trillion attempts per second.)

To give you an idea, assuming you generated a password completely randomly, here's how much time it takes to crack passwords of different entropies with 170 billion attempts per second:

![Time to Crack](https://images.ctfassets.net/23aumh6u8s0i/7JDEbcJ7FdNbBHyrdZ98SW/237428fc45ff65bfb0e4751eb5a1105f/table_2)

As you can see, things get out of hand for the attacker pretty quickly. But one of the caveats when it comes to estimating time to crack is that we make calculations with components available today.

What if technologies advance so rapidly that in 5 years' time, it would be trivial to crack an 80 or 100-bit password?

In 1975, Gordon Moore, co-founder of Intel, stated that the number of transistors in chips would double every two years.

Even though transistors in a chip don't equate to raw processing power, they are strongly correlated. Later dubbed Moore's Law, it was able to predict with great accuracy what ended up happening in the following years up until today. However, experts, including Moore himself, believe that we are reaching a fundamental limit and predict Moore's Law will end by 2025.

With all that said, how much entropy is enough entropy to make you secure for years to come? Is more entropy always better? Can you avoid the pitfalls of excessively complicated passwords and still be safe? What if you don't like or can't remember the long and complicated strings password managers generate?

All those questions are answered in the second part of this series, How to Create Great Passwords: Entropy, Diceware, and More.


Defending Against Password Cracking: Understanding The Math

5e074956ee8ba1fea26e30d28c190495?s=300 avatar

5e074956ee8ba1fea26e30d28c190495?s=300

Full stack developer creating content at Auth0. I love taking a deep dive into hard-to-understand concepts and creating content that makes them easier to grasp. In my free time you can usually find me reading, hanging out with my dogs, or curling in the squat rack.

Former Developer Content Manager

Holly Guevara

Learn how an authentication server works and how it compares with an authorization server.

## What is an Authentication Server

An authentication server is used to verify credentials when a person or another server needs to prove who they are to an application.

To better understand *what* an authentication server is, let's look at what it *does* by taking a peek into what happens when an authentication request is made.

## Day in the Life of an Authentication Server

Authentication, in short, is the process of identifying a person or computer to make sure they are who they say they are.

An application or device may ask for several different identifiers to verify this. Each identifier generally falls in one of these three categories:

- **Something you know** &mdash; Usually something like a username and password or PIN. It is the most common identification method.

- **Something you have** &mdash; This covers physical things that you possess, such as a smartphone, key, etc.

- **Something you are** &mdash; This category involves verifying through [biometric methods](https://auth0.com/blog/3-critical-trends-in-biometric-authentication-in-2019/), such as a fingerprint or retinal scan.

There are several different types of authentication, but for brevity, we'll go through what happens in two scenarios: single-factor authentication and multi-factor authentication.

### Single-factor authentication

Single-factor authentication is the process of verifying an identity using only **one factor**. The different factors generally fall into one of the categories above: something you know, something you have, or something you are. The most common form of single-factor authentication is simply a **username and password**.

Let's look at what happens when a user authenticates with a username and password.

<blockquote style="font-weight:300;font-style:normal;">
User: Navigates to a website and types in username and password
Authentication Server: Whoa, what's this? Who are you??
Authentication Server: puts on glasses
Authentication Server: Ahh yes, bobbysmith3. Let me verify that your secret password is correct. 🧐
User: Waiting
Authentication Server: I have run my checks, and I can confirm you are indeed bobbysmith3! Welcome!
</blockquote>

In this scenario, what was the authentication server checking for when the user entered their username and password? Here's the more in depth flow about what happened behind the scenes while the user was waiting to be authenticated:

* The username and hashed password are sent to the server.
* The server accesses its database of users that holds the username and [hashed/salted password](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/).
* It checks the provided username and hashed password against the one in the database.
* If the credentials match, the user's identity is verified, and the application decides what's next.
* If not, a [generic error message](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages) is returned.

> Note: The error message should not reveal too much information about why the request failed. For example, messages such as "This username does not exist" can also be used by an attacker to determine if a username *does* exist, as they would get a different error message if they try a valid username. 

While this may seem like a foolproof method of verifying a user's identity, there's a lot left to be desired. What happens if someone figures out your password?

Over the years, there has been a huge increase in the number of [credential stuffing attacks](https://auth0.com/blog/what-is-credential-stuffing/). When a data breach occurs, and usernames/passwords are leaked, they're compiled into huge lists that attackers can use to try to sign into several different websites. Since [password reuse](https://www.pandasecurity.com/mediacenter/security/password-reuse/) is so common, there's a decent chance that some of the usernames and passwords leaked from one application may be valid for another.

<include src="TweetQuote" quoteText="Single-factor authentication just doesn't cut it anymore."/>

This is where **multi-factor authentication** comes into play. Unlike single-factor, which relies on just one form of identification, multi-factor authentication requires more than one identifier to verify a user.

### Multi-factor authentication

Let's look at what happens when an authentication request is made using **two identification factors**.

<blockquote style="font-weight:300;font-style:normal;">
User: Navigates to a website and types in username and password
Authentication Server: Ahh, it's you again, bobbysmith3! Let me check that your password matches the one I have on file.
Authentication Server: Well, it checks out. But I'm still skeptical. I'm sending a code to the phone number I have on file. Please type in the code once you receive it.
User's phone: DING!
User: Receives a text message and types in the code
Authentication Server: The code matches! Since you have bobbysmith3's password and phone on hand, I'm confident that you are indeed bobbysmith3! Welcome!
</blockquote>

One of the most common forms of [multi-factor authentication](https://auth0.com/docs/mfa) is a **username and password combined with something sent to a device or account you own**.

For example, you have probably signed into an application with your username and password, and then received a text message or email with a code that you have to provide back to the application to be authenticated. This code is called a [one-time password (OTP)](https://auth0.com/docs/mfa/guides/configure-otp).

The process for authenticating a user with username/password and an OTP is the same as above, but there's an additional step &mdash; the authentication server must send the OTP to the user's registered device and verify that the code is correct.

To do this, the authentication server must perform the following actions:

* Generate the OTP.
* Send it to the application where the user is attempting to sign in.
* Once the application sends the OTP back that the user submitted, verify that it's correct.
* If so, the user is authenticated.
* If not, return an error and allow them to regenerate another OTP. To prevent brute force attacks, there should be a [limit to how many times a new OTP can be requested](https://auth0.com/docs/anomaly-detection#brute-force-protection) before the user is blocked.

With this additional requirement, an attacker's attempt to fake their identity is greatly stunted! Let's revisit the question that was posed with single-factor username/password authentication.

> What happens if someone figures out your password?

In this case, simply having someone's password isn't enough. The attacker must also gain access to the real user's OTP to verify the identity.

As you can see, multi-factor authentication [greatly reduces](https://auth0.com/blog/why-nist-recommends-mfa-to-fight-ecommerce-fraud/#Why-E-Commerce-Needs-MFA) the chances of an attacker impersonating a user.

## What an Authentication Server Doesn't Do

An authentication server does a lot of work in the background, but it's also important to understand what it's *not* responsible for doing.

### Authentication vs. authorization

In the examples so far, the authentication server has taken steps to verify a user's identity and return it to the requesting application. What happens next is up to the application.

Once the application knows who the user is, it usually has to decide *what the user can access*. This is known as [**authorization**](https://auth0.com/docs/authorization).

**Authorization** &mdash; Authorization refers to the process of verifying what a user has access to.

**Authentication** &mdash; Authentication refers to the process of confirming identity.

It's easy to confuse authentication and authorization, but it's important to understand the difference. The authentication process **does not** determine what a user can access.

<include src="TweetQuote" quoteText="The authentication process does not determine what a user can access."/>

The authentication server simply verifies the identity of the user and then passes that information back to the application. The application then uses this identity information to determine what the current user can access.

To manage access control, an **authorization server** will issue [access tokens](https://auth0.com/docs/tokens/concepts/access-tokens) to the client that lists what permissions the current user has. If you'd like to learn more about access tokens, please check out the free ebook below. It goes in-depth about a popular web token standard, JSON Web Token (JWT). 

<include src="ebook-ads/JwtHandbook" />

So even though these two terms have entirely different meanings, the authorization process depends on authentication. Authorization cannot be granted unless the identity of the user is verified.

Because these two processes go hand-in-hand, it's common to see a solution that can handle both ends: authentication and authorization. [Auth0](https://auth0.com), for example, is an all-in-one solution that serves as both an authentication server and an authorization server.

<include src="asides/AboutAuth0" />

## Conclusion

Although the authentication process may seem simple to an end-user, what goes on behind the scenes is very complex. Every time you sign in to a website, there's a lot happening behind the scenes to verify that you are who you say you are.

Hopefully, this article was able to shed a little bit of light on some of the major tasks an authentication server performs, as well as tasks that it isn't responsible for performing.

Thank you for reading and reach out below if you have any questions or if you'd like to learn more about using Auth0 as your authorization and authentication service!

What is an Authentication Server

ramiro

I am an internet guy who loves reading and asking questions—those are the two things that helped me the most as an autodidact 🤓. If I am not learning about the latest trends in digital marketing or listening to house music, you can probably find me watching a tennis tournament. And also, I manage Social Media at Auth0 ✌️

Manager, Social Media

Ramiro Nunez Dosio

Explore the complexities of authentication and how to solve them on this stream from .NET Conf 2019.

.NET Conf 2019 was an exciting and unique event that took place this year from September 23 — 25. It is a free, 3-day virtual conference co-organized by the .NET community and Microsoft. Anyone with an Internet connection was able to attend.

## .NET Conf 2019: A Virtual Conference

This year the conference saw the [launch of .NET Core 3.0](https://auth0.com/blog/exploring-dotnet-core-3-whats-new/), offered prizes to attendees such as free Xbox One X consoles, and hosted talks from a world-class lineup of speakers from Microsoft and the community.

Our own [Developer Advocate Engineer Bobby Johnson](https://auth0.com/blog/authors/bobby-johnson/) gave a talk focused on exploring how the username-password strategy got so complicated over time. Bobby shows you how overwhelming it can be to take your first step beyond username and password-based authentication strategies, which are the default authentication strategies offered by most full-stack web application frameworks.

Social logins, Identity Providers, OAuth 2.0, LDAP, SAML, OpenId Connect; all can be confusing. What does it all mean? How did we get here? Watch Bobby's talk to find out:

<AmpContent>
 <amp-iframe width="480" height="270"
 sandbox="allow-scripts allow-same-origin"
 layout="responsive"
 frameborder="0"
 src="https://www.youtube.com/embed/ga3u_4B7_Bw?start=69">
 </amp-iframe>

</AmpContent>

<NonAmpContent>

 <iframe width="560" height="315" src="https://www.youtube.com/embed/ga3u_4B7_Bw?start=69" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

</NonAmpContent>

<include src="ProfileCard" picture="https://cdn.auth0.com/blog/auziros/bobby-johnson.png" name="Bobby Johnson" title="Developer Advocate Engineer" team="Technical Experience" location="Washington, United States" body="Attending .NET Conf 2019 and collaborating with the Channel 9 team was an awesome experience. They were very professional and the event ran like clockwork."/>

The organizers have made all the sessions available [on-demand on YouTube](https://www.youtube.com/user/VisualStudio). Be sure to check them out.

## More Resources

- [.NET Conf 2019 Official Site](https://www.dotnetconf.net/)

- [Bobby's Twitch Channel](https://www.twitch.tv/iamnotmyself/): Streams three times per week!

- [The Live Coders' Twitch Channel](https://livecoders.dev/): Enthusiastic streaming developer community with members who participated in .NET Conf 2019 as organizers or attendees.

- [Exploring .NET Core 3.0. What's New?](https://auth0.com/blog/exploring-dotnet-core-3-whats-new/)

- [Building and Securing Web APIs with ASP.NET Core 3.0](https://auth0.com/blog/how-to-build-and-secure-web-apis-with-aspnet-core-3)

## Aside: Securing ASP.NET Core 3.0 with Auth0

Authentication and authorization are hard but securing ASP.NET Core 3.0 applications with Auth0 is easy and brings a lot of great features to the table. With [Auth0](https://auth0.com/), you only have to write a few lines of code to get solid [identity management solution](https://auth0.com/user-management), [single sign-on](https://auth0.com/docs/sso/single-sign-on), support for [social identity providers (like Facebook, GitHub, Twitter, etc.)](https://auth0.com/docs/identityproviders), and support for [enterprise identity providers (like Active Directory, LDAP, SAML, custom, etc.)](https://auth0.com/enterprise).

<AmpContent>
<amp-youtube
 data-videoid="U3NDciLTTgI"
 layout="responsive"
 width="480" height="270">
</amp-youtube>

</AmpContent>

<NonAmpContent>

<iframe width="560" height="315" src="https://www.youtube.com/embed/U3NDciLTTgI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

</NonAmpContent>

On ASP.NET Core 3.0, you need [to create an API in your Auth0 Management Dashboard](https://auth0.com/docs/apis) and change two things on your code. To create an API, you need to <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</a>. After that, you need to go to [the API section of the dashboard](https://manage.auth0.com/#/apis) and click on "Create API". On the dialog shown, you can set the _Name_ of our API as "Books", the _Identifier_ as "http://books.mycompany.com", and leave the _Signing Algorithm_ as "RS256".

![Creating API on Auth0](https://images.ctfassets.net/23aumh6u8s0i/EqGkwFxCdRtjWblGcRHo8/4d14728749a8c8db52447c6a4f62713d/creating-api-on-auth0)

After that, you have to add the call to `services.AddAuthentication` in the `ConfigureServices` method of `Startup`:

```csharp
string domain = $"https://{Configuration["Auth0:Domain"]}/";
services.AddAuthentication(options =>
{
 options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
 options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
}).AddJwtBearer(options =>
{
 options.Authority = domain;
 options.Audience = Configuration["Auth0:Audience"];
});
```

You also need to add an invocation to `app.UseAuthentication()` in the body of `Configure()` method of `Startup`.

And add the following element to `appsettings.json`:

```json
{
 "Logging": {
 // ...
 },
 "Auth0": {
 "Domain": "bk-samples.auth0.com",
 "Audience": "http://books.mycompany.com"
 }
}
```

> **Note** that the domain, in this case, **has to be changed** to the domain that you specified when creating your Auth0 account.

How Usernames and Passwords Got so Complicated

A strong password storage strategy is critical to mitigating data breaches that put the reputation of any organization in danger. Hashing is the foundation of secure password storage.

Hashing Passwords: One-Way Road to Security

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing. Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Three ways SMBs can invest in cybersecurity best practices that prioritize protecting sensitive data.

Many small business leaders believe their companies are safe from cybersecurity threats. In a [2017 study by Insureon](https://www.insureon.com/resources/research/small-business-cyber-security-poll), just 16% of 2,400 respondents were concerned about a cybersecurity attack — down from 18% the year prior. 

Small business leaders assume their teams are too small to be worthwhile targets — or that existing IT teams can handle external threats. In particular, startup founders must juggle numerous other priorities as they scale, like getting to product-market fit, hiring, and fundraising. If cybersecurity isn’t front of mind, it’s less likely the team will make a concerted effort to improve their current infrastructure.

Yet this lack of attention can be a fatal mistake. Hacking operations often use bots to [_crawl multitudes of sites_](https://www.sitelock.com/blog/2017/04/website-vulnerabilities/) looking for known vulnerabilities. In these situations, company size doesn’t matter. While security disasters at massive companies, such as [_Anthem and Target_](https://auth0.com/blog/4-security-measures-after-data-breach/), dominate headlines, startups, and the rest of the small-to-medium businesses often make easy prey because [_they devote fewer resources to defense_](https://www.bbb.org/globalassets/shared/media/state-of-cybersecurity/updates/cybersecurity_final-lowres.pdf)_._

How can small teams protect themselves when resources are low and other projects are vying for immediate attention? In this piece, we highlight three areas where startup and small business leaders can invest their time and money to secure their sensitive data and safely grow.

## 1. Secure your users from the start.

From the moment you begin hiring, safely and easily managing access to your technical systems becomes a challenge. Yet the pace of startup growth and the [_looming chance of failure_](https://www.godaddy.com/garage/startup-mistakes-4-startups-that-monumentally-failed-and-what-we-can-learn-from-them/) can make it difficult to spend time on credential management. 

A lack of a strong user management and authentication system, however, can sink you.

In Verizon's annual Data Breach Investigations report, they found that [63% of confirmed breaches](https://enterprise.verizon.com/resources/reports/2017/dbir-presentation-beltug.pdf) involved weak, default, or stolen passwords. A bad password doesn't threaten a single account. If users reuse passwords, one compromised account could lead to the loss of many other devices and systems. 

A solution like Auth0 provides [_multi-factor authentication_](https://auth0.com/multifactor-authentication) (MFA) that bypasses password vulnerabilities and enables admins to immediately approve login requests with a single click across a range of devices.

![Auth0 Guardian MFA authentication requests mobile and smart watch screenshots](https://images.ctfassets.net/23aumh6u8s0i/2WzftOPNUQiNo7UrxPClrO/f30cb0b18a1882b312362585c23f8c6d/auth0-guardian-mfa)

With MFA in place, users need a second piece of sensitive information, such as a thumbprint or facial scan, to access other systems. Hackers with only one set of credentials can't get any further. 

[Auth0 Guardian](https://auth0.com/multifactor-authentication) helps startups keep moving by ridding employees of pesky, single-use login codes. With push notifications, busy admins can approve or deny requests without ever having to open the app. Guardian also offers mobile Software Development Kits (SDKs), so that you can design your own MFA application that integrates smoothly with the rest of your company's branding.

## 2. Plan your response to attacks.

Unfortunately, [with data breaches on the rise](https://auth0.com/blog/what-is-a-data-breach/), you can’t afford to not plan ahead.

In 2017, the startup Kickico [found itself unprepared](https://medium.com/@kickico/how-they-tried-to-hack-our-ico-d348659dc4). They endured a wave of distributed denial-of-service (DDoS) attacks as hackers spoofed their site, cloned their platform on GitHub, and readied the clone to fool potential users once the original site went down. Luckily, the hackers appeared to run out of funds to keep up the DDoS attacks, and GitHub promptly responded to Kickico's request to block the attackers. 

Kickico wasn't ready, and admitted “We did not realize such a small and inconspicuous company without huge PR actions [would] attract any attention.”

Many startups are ill-prepared and subtle attacks can take much longer to detect. One study found that [over two-thirds of companies](https://enterprise.verizon.com/resources/reports/DBIR_2018_Report_execsummary.pdf) took months or longer to discover a breach—even though those breaches took mere minutes to accomplish. 

Startups can build in preparedness with tools that offer [breached password notifications](https://auth0.com/breached-passwords), so that you know about leaked credentials instantly, and can even lock out users until they reset their passwords. 

![Auth0 anomaly protection Dashboard brute force protection enabled](https://images.ctfassets.net/23aumh6u8s0i/1dU6iYAvPdzS7ZM8HcK2RA/44ebc4556fcf622399d699338f3383f9/anomaly-detection-overview)

With anomaly detection in place, startups can also set limits on brute force logins before they happen, establishing a baseline level of preparedness. 

These cybersecurity best practices can buttress a [data breach response plan](https://auth0.com/blog/data-breach-response-planning-for-startups/), which prepares startups to react as quickly as possible to a breach. Rather than taking it alone, startups should form relationships early on with law, public relations, and incident response firms that are familiar with data breaches. Once you detect a breach, you can follow the plan and leverage the experts to recover as quickly and fully as possible. 

Data privacy laws are also increasingly [taking breaches more seriously](https://auth0.com/blog/get-ready-for-gdpr/), requiring faster responses and imposing stiffer penalties. A well-thought-out data breach response plan, informed by automatic detection, is only going to become more necessary.

<include src="TweetQuote" quoteText="Many startups are ill-prepared to tackle cybersecurity attacks and subtle ones can take too long to be detected. One study found that over two-thirds of companies took months or longer to discover a breach."/>

## 3. Guard against web-based attacks.

Your website is like your company's front door, yet hackers have thousands of ways in. [Forty-nine percent of cyber attacks](https://www.cyberreadinessinstitute.org/cyber-readiness-news/small-and-mid-sized-businesses-cyber-threats-by-the-numbers) are web-based, and [44 attacks per day](https://smallbiztrends.com/2018/03/sitelock-website-security-insider-q4-2017.html) strike the average small business site. 

Web security depends on more than the connection between two entities. Data [goes through third parties](https://auth0.com/blog/using-https/) to get where it needs to go, so authentication at all stages is central to secure communication. 

If the [right communication protocols](https://auth0.com/blog/common-threats-in-web-app-security/) aren't set, transmitted information can become vulnerable to so-called man-in-the-middle attacks. HTTP, an application protocol you've likely seen in many URLs, is historically focused on sending information, not securing it. 

HTTPS, a newer protocol with security built in, makes attacks much harder to accomplish. HTTPS adds Transport Layer Security, or TLS, which ensures a client is only communicating with the expected server and that all data passed between is encrypted. 

Using an [HTTP Strict Transport Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security), or HSTS, header reinforces HTTPS across your web application by telling browsers your site can only be accessed through HTTPS. Even if users have an older version bookmarked or type http://, an HSTS header forces browsers and applications to use HTTPS instead. Hackers won't be able to access the encrypted information, steal your site's cookies, or force a redirect to a spoofed site. 

Auth0 [enforces HTTPS connections](https://auth0.com/blog/a-run-through-the-owasp-top-10/) to all of its services, which means any non-HTTPS connections will be upgraded. 

Startups have to use their limited resources judiciously, but in the same way, a new restaurant wouldn't skimp on locks, neither should startups ignore these web security best practices. 

## Security on day one

Poor cybersecurity is technical debt. These shortcuts can keep a company moving but compound over time, eventually becoming expensive burdens. You can wait on establishing good cybersecurity procedures, but hackers won't. The longer you take to make security a priority, the harder it's going to be to retroactively protect yourself. 

Cybersecurity is an investment in the sustainability of your company. Growth without cybersecurity best practices in place is [growth for the benefit of hackers](http://blog.idonethis.com/security-ringcaptcha/) seeking a big payout. 

Start by addressing one of your primary vulnerabilities: identity. With an outsourced provider like Auth0, you can scale security with user growth, form an informed threat response plan, and build a secure login environment. Investing in security early will keep you safer and better-informed when it matters most.

<include src="TweetQuote" quoteText="Cybersecurity is an investment in the sustainability of your company. Growth without cybersecurity best practices in place is growth for the benefit of hackers seeking a big payout."/>

<include src="asides/AboutAuth0" />

How SMBs can Improve Cybersecurity for their Customers

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Here are 5 trends that will help you keep your organization secure in 2018.

<div class="alert alert-info alert-icon">
 
 GDPR is around the corner. Are you Ready? Take our GDPR Readiness Assessment to find out. <a href="https://auth0.com/gdpr-assessment/tool-1">Start the survey</a>.
</div>

---

**TL;DR:** It's easy to predict the security threat for 2018 (Hint: It will be bigger and more sophisticated than 2017). It's another thing to prepare for what lies ahead. Here are 5 trends that will help you keep your organization secure in 2018.

<include src="TweetQuote" quoteText="Here are 5 trends that will help you keep your organization secure in 2018"/>

[GDPR compliance](https://auth0.com/gdpr) is dominating the 2018 security discussion. With the May 25th deadline quickly approaching, the first half of 2018 will likely be consumed with making the necessary changes for compliance, which is an enormous task for any size company.

While GDPR is extremely important and failure to comply comes with [stiff penalties](https://resources.auth0.com/whitepaper/gdpr-fine-determination/), don't let it distract you from anticipating the security threats that await your organization. If you thought 2017 was a massive year of cyber attacks, there are unfortunately no signs of slowing down in 2018.

Here are our 5 security predictions to help you prepare for 2018.

### 1. Customers Are Fed Up With Passwords

The weaknesses of traditional credentials are well documented, yet most organizations continue to use them as the primary security method. Customers have had enough.

The Equifax breach was the straw that broke the camel's back. While security experts have known of the vulnerabilities of password reliance, the high-profile breaches of 2017 have brought a higher level of awareness to the general public.

People want security alternatives. A recent [survey](https://www.csoonline.com/article/3242866/security/our-top-7-cyber-security-predictions-for-2018.html) showed that people are now more concerned with someone stealing their personal data than they are with a home break-in. A company's reluctance to add stronger authentication will have to deal with fierce customer demand for additional security beyond the password.

The first logical step to strengthening traditional credentials is to implement [multifactor authentication](https://auth0.com/docs/multifactor-authentication) (MFA).

![Multi-factor Auth](https://images.ctfassets.net/23aumh6u8s0i/4n9ZcXraMMRDtcmRwG04bn/5aee12138b7dee3679d1ec18cdb246e4/Multifactor-Authentication)

MFA is a method used to verify a user's identity when they are trying to access an application. In addition to a password, MFA requires you to provide additional information such as an SMS code or a fingerprint to confirm your identity.

Consumer-oriented companies like Google, Apple, and PayPal have made MFA a standard feature and the trend will continue in 2018 with both consumer and enterprise accounts.

### 2. Preventing Aftershock Breaches

Companies that are breathing a sigh of relief that they weren't hit by a cyber attack in 2017 need to worry about a different type of threat — the aftershock breach.

The millions of compromised credentials taken from previous breaches now pose a liability for every company that uses passwords for security (which is everyone). Most people use the same credentials for all of their accounts, which heightens this risk of an aftershock breach, where hackers use the stolen credentials to access other accounts.

Experian's recent Data Breach [Report](https://www.experian.com/assets/data-breach/white-papers/2017-experian-data-breach-industry-forecast.pdf) notes:

> Given the continued success of aftershock breaches involving username and passwords, we predict that attackers are going to take the same approach with other types of attacks involving even more personal information, such as social security numbers or medical information.

Aftershock breaches can be minimized by using risk-based authentication, such as[ anomaly detection](https://auth0.com/docs/anomaly-detection) which monitors user behavior data to determine suspicious activity. By[ collecting signals](https://auth0.com/university/1/4/how-to-use-auth0-s-rules-feature) such as an IP address or the location of a user, anomaly detection can compare previously established behavior in order to spot inconsistencies.

![Password Breach Block](https://images.ctfassets.net/23aumh6u8s0i/3UQfTsXEnWW38EvMxQ7VvM/881ab7f175259a79750d7aafd6837fd3/breached-pass-lock)

Auth0's anomaly detection also tracks [password breaches](https://auth0.com/breached-passwords) of major third-party sites to help keep your users and systems secure. When a company like Equifax is breached, you can block your users from logging into your accounts until they go through a new authentication protocol.

When combined with MFA, anomaly detection makes it really hard for hackers to leverage their stolen credentials and initiate an aftershock breach.

### 3. Weaponizing Data Rather Than Stealing It

A few years ago, someone hacked into the Associated Press' Twitter account and tweeted a false report that President Obama had been injured in an explosion. The news caused a 150-point drop in the stock market.

![Source](https://images.ctfassets.net/23aumh6u8s0i/4Z7i4HQDeGCtb9UE1oVoKg/edc28deb72bca4907cd0af23e55c8b53/67201644_ap)

This type of data manipulation, known as a data integrity attack, will become more prevalent in 2018. While stealing millions of credit card numbers might seem like a huge score, it only works if you have a buyer on the other end. Hackers are realizing that it is much easier to capitalize on the data itself.

For example, an attacker could doctor a bank's routing numbers for a large financial gain. Or, one could erode public confidence by shutting down electrical grids. Regardless of the intention, the new target is in using the data, not stealing it.

Integrity attacks are hard to detect, which could leave companies defenseless with their current monitoring systems. The immediate solution to this threat is [data encryption](https://digitalguardian.com/blog/what-data-encryption). Most companies have an encryption policy that protects their most sensitive data, but the definition of sensitive data must be expanded to protect all potential attacks.

![Source](https://images.ctfassets.net/23aumh6u8s0i/1L5kShBmyTcdpOSeANibPA/161401f1ab2aa62f9563ce6668e6cabd/data-encryption)

The idea behind data encryption is to make your data incoherent to outsiders without the decryption key. **Why does this matter?**

The breaches in the past five years have shown that hackers can infiltrate the most sophisticated cyber security systems in the world. Traditional security like firewalls, intrusion monitoring and antivirus software are not very effective once hackers get inside. The last line of defense is to encrypt your data.

### 4. Rise of the Bots Against IoT

Bots are supposed to be our friends. They take care of the tedious, repetitive tasks so we can focus on the more important work. **But what happens when bots turn to the dark side?**

In 2016, a [botnet](https://www.csoonline.com/article/3240364/hacking/what-is-a-botnet-and-why-they-arent-going-away-anytime-soon.html) of more than 500,000 devices [attacked ](https://en.wikipedia.org/wiki/2016_Dyn_cyberattack) Dyn, a domain name service providers, crippling the internet and impacting huge websites like Amazon, Spotify, and Netflix. These types of attacks are often executed through internet-connected devices, and the threat for 2018 has never been greater.

![Source](https://images.ctfassets.net/23aumh6u8s0i/2XSmrlVo479am1wBxhs8PQ/b6429c8a47e75c0c1c6dc646fde06a9c/botnet2_1238990)

IoT is expected to surpass 10 billion devices in 2018 and over [22 billion by 2021](http://uk.businessinsider.com/the-internet-of-things-2017-report-2017-1?r=DE&IR=T). Every one of these devices poses a security risk as the surface area for an attack expands well beyond what current security measures can handle. In fact, [HP](http://www8.hp.com/de/de/hp-news/press-release.html?id=1744676#.WMFmT1XyiUk) found that at least 70 percent of IoT devices are vulnerable to an attack.

Hackers can simply buy a botnet kit, which gives them everything they need to launch an attack. The three most popular kits—Andromeda, Gamarue, and Wauchos—have already helped attackers infiltrate millions of devices. Once inside, the bots are capable of a myriad of debilitating tasks from taking down networks to compromising data or even controlling a device. **It will make you think twice about who is driving your self-driving car.**

### 5. Phishing is Still King

Major data breaches, ransomware attacks, and identity theft often start the same way—with a simple phishing scheme.

Phishing is still the most effective method for attackers to infiltrate a system, mainly because it relies on human error, which renders technical security useless. The only real defense is to train people to identify schemes and remain aware at all times.

While awareness will help prevent traditional phishing, attackers are creating more sophisticated techniques to outsmart the uneducated. They've also found success with other channels beyond email like phishing with SMS, also known as smishing.

![https://images.ctfassets.net/23aumh6u8s0i/6CsaSx8Zo8BWwel3zXoo5V/e4e81b69fc9360fd19c5471d3d439482/phishing-bank](https://images.ctfassets.net/23aumh6u8s0i/6CsaSx8Zo8BWwel3zXoo5V/e4e81b69fc9360fd19c5471d3d439482/phishing-bank)

Smishing scams are harder to detect because they take advantage of people's sense of urgency. Let's say you receive a text that appears to be an important message from your credit card company. An urgent message can catch you off guard and before you know it, you've compromised your information.

Awareness training becomes more difficult with smishing because of its heightened nature. You can't always prevent someone from being tricked by phishing, but you can anticipate it and secure your accounts beyond credentials. Password managers like [1Password](https://1password.com/) can be useful, but adding more layers of defense with MFA will help keep your accounts safe.

## Security in 2018 is About Proactive Prevention

Sadly, many of the breaches in 2017 could have been prevented with stronger security measures, especially around identity access management. Archaic methods like passwords and unprotected data made it easy for hackers to pull off some of the biggest heists of 2017 including corporate giants like Equifax and Deloitte.

The attack tactics might evolve, but at the end of the day, taking proactive measures will help deter the majority of attempts. By understanding the different threats, you can get ahead of them before they occur.

**_READ MORE:_** [How Poor Identity Access Management Equals Security Breaches](https://auth0.com/blog/how-poor-identity-access-management-equals-security-breaches/)

Security Predictions for 2018 That Go Beyond GDPR Compliance

Learn how to leave usernames and passwords behind with social and passwordless authentication.



**TL;DR:** Learn how to leave usernames and passwords behind with social and [passwordless authentication](https://auth0.com/passwordless) with Auth0's [Identity and Access Management solution](https://auth0.com/user-management).

---

After months and months of developing your new app, it's finally ready to launch. You feel confident that you've got all the features and functionality you need. But with all of that work, you've let your login fall by the wayside. A simple a username and a password will do the trick, right?

Wrong. In the age of modern authentication, you need to go beyond usernames and passwords to protect customer information and give users frictionless logins that they trust. Embracing login as identity management rather than as a simple gate to access is imperative.

Here's what you need to know.

## Implement Easy Login Options for Users

Between the growing number of passwords users have to remember and the multiple steps needed to reset a forgotten password, users are demanding easier login options.

Making it as easy as possible for them to visit your site means they'll [stick around longer](https://blog.fullstory.com/the-best-products-will-win-7ec43a93186#.onq2r8lau). By removing the friction usually associated with activating a new account or simply signing in, you'll reduce your abandon rate.

Using modern authentication practices, [Auth0](https://auth0.com) has built a system that can be quickly integrated into your site to give users the easy access they've been asking for. [Social login](https://auth0.com/learn/social-login/) and [passwordless authentication](https://auth0.com/passwordless) are two options that provide freedom from usernames and passwords.

With social login, users confirm their identity by using a third party site that has already vetted their authenticity.

![Social authentication](https://images.ctfassets.net/23aumh6u8s0i/1OFiTKkAcgA3DECIVuNOKL/05681fd900210170f791822e35124c2c/social-login)
[Source](http://tradablebits.com/social-login)

It takes less time for users to set up an account and profile since their personal information is automatically filtered into the new site. Almost everyone has at least one social media profile, so it's perfect for users who want one fewer password.

With passwordless authentication, users are sent timed codes via SMS or email to access their account.

They only need to have immediate access to their phone or email to quickly access their account. Again, this saves them time and effort while their account remains accessible and secure.

## Provide Enterprises with Centralized Oversight

Enterprise customers need to maintain control of their many employees' login access. They want a secure, central place to manage user identity, and often want the benefits of [Single Sign-On (SSO)](https://auth0.com/learn/how-to-implement-single-sign-on/) as well.

They also need you to be able to comply with whatever their given enterprise connection is, whether that's AD, LDAP, ADFS, SAML, Ping, or Google Apps. These connections can be difficult and time-consuming to implement, and that's _without_ looking at getting everything up to specific industry standards.

If identity isn't part of your core business, scaling up to support enterprise authentication only serves to take attention away from what you do best.

In this case, enterprise federation is the best approach for enterprises. Scaling up to an enterprise platform is quick and easy to set up with an [IAM (Identity and Access Management) solution like Auth0](https://auth0.com). Once up and running, it's easy to choose who will manage and monitor access based on identity, add and remove users, manage login requirements, and run any necessary analytics.

From the Auth0 dashboard, go to Connections > Enterprise to view available connections or to create new ones.

![Auth0 enterprise connections dashboard](https://images.ctfassets.net/23aumh6u8s0i/7EuJvrcgzvbIjrFpZCtWfj/af08c4fa5429eb1ea34cdb5e5fee87b1/auth0-enterprise)

With this platform, enterprises can monitor user accounts from one central dashboard.

## Make Security a Top Priority

Both users and enterprises want secure logins. Users expect a certain level of protection from the sites they access and enterprises want to secure their internal data. Unfortunately, simply relying on the username and password approach might not get you very far.

Just look at companies like [LinkedIn](http://fortune.com/2016/05/18/linkedin-data-breach-email-password/) and [Yahoo](https://auth0.com/blog/yahoo-confirms-data-breach-of-half-a-billion-user-accounts/). They are some of the largest companies out there, but were still susceptible to data breaches. User data was easily accessed by hackers due to inadequate security parameters.

That's why modern authentication is so important. Instead of building a system from scratch, you can access ready-made platforms that provide encryption, brute force protection, constant monitoring for attacks, and the ability to promptly notify users.

With Auth0's approach to modern authentication, we take away the need for in-house custom builds that don't meet compliance standards.

For example, as part of a suite of [security features](https://auth0.com/security), Auth0 offers anomaly detection to fight against brute force attacks. If suspicious activity is detected, users are notified immediately. All of Auth0's automated blocking features are built with resilience in mind.

Another important security feature is credential and user login monitoring.

![Auth0 log tracking](https://images.ctfassets.net/23aumh6u8s0i/6rogIjpng0uNPfQHJ8rILE/16474d490bddf002418e9d26660af093/auth0-logs)

From the dashboard, you can easily track logs and be confident in knowing that security compliance and regulations are automatically taken into consideration and deployed across your site.

## Moving Forward with Modern Authentication

Now more than ever, authentication involves more than just supporting usernames and passwords. Modern authentication puts the emphasis on creating and protecting identity for users, whether they're an individual using an app or enterprise employees.

Usernames and passwords aren't going to disappear, but authentication is complex, and it's only going to get harder to manage.

There's no need to struggle to keep up using in-house solutions when you can rely on experts that live and breathe identity management. Your IAM solution can support everything you want to offer your users, while letting you focus on the product that got users to sign up in the first place.

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can improve your product's security with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

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


Go Beyond Username/Password with Modern Authentication

When your users' behaviors determine the safety of your login, passwordless comes out on top.

<div class="alert alert-info alert-icon">
 
 Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.
</div>

---

One place where both businesses and consumers agree is login safety. For consumers, it's important that they trust the login of their apps and websites because they are handing over sensitive, personal information. For businesses, keeping that information safe is of the utmost importance — nobody wants to send out a [notification that their system has been breeched](http://arstechnica.com/security/2016/06/how-linkedins-password-sloppiness-hurts-us-all/).

So when a new way to log in comes along, it's only natural that we respond with skepticism — is this *really *safe? — because we know how important a secure sign on is. In the case of passwordless authentication, that reaction is particularly strong, because we have had it drilled into our heads that passwords are the ultimate source of protection for your account.

Although that skepticism is healthy and helps us find the best, most secure ways to log in, Auth0 is here to clear things up. Not only is passwordless authentication safe to use, it might even be safer than a traditional username + password login.

## What is passwordless authentication?

[Passworldess authentication is a way to configure your login, well, without a password](https://auth0.com/passwordless). For example, a user might register their email and then receive a single-use passcode for each sign on. One common example of this is **Slack's magic links**. Put in your email, hit “Send Magic Link,” and you can log into Slack from your email inbox with no password.

![Slack Magic Link](https://images.ctfassets.net/23aumh6u8s0i/4bjIqxPizjKKtupJJdERUW/0aa79623fffe7f0ae9c7fcd1ea02a1c2/slack_magiclink)

While it is not as popular as other forms of login yet, it is [sustaining rapid growth](https://auth0.com/blog/analysis-of-passwordless-connections/).

![Passwordless Connections](https://images.ctfassets.net/23aumh6u8s0i/6SqLL2G9s89DPOY8eS8ub5/6db064112a71b3dcd862065ab5dd2fef/passwordconnection)

In fact, by our estimates, it could overtake passwords as the [primary form of login](https://auth0.com/blog/analysis-of-passwordless-connections/) within the next ten years.

![Forecast vs Passwordless](https://images.ctfassets.net/23aumh6u8s0i/3mF40i04Jbz2YCt794Gync/aeb7261960f8886cc68298bcd3e8d322/forecast-up-vs-passwordless)

But magic links are just the tip of the passwordless iceberg. There are several different [ways you can configure your passwordless login](https://auth0.com/blog/how-passwordless-authentication-works/). Here's a quick overview:

* **Magic link through email:** In this scenario, a user is asked for their email. Once they've given it, the IAM (in this chart, Auth0) facilitates the creation of a token that allows the user to log in through a link sent to their email.

 ![Passwordless email magic link start flow](https://images.ctfassets.net/23aumh6u8s0i/6Lri8oqw3o3fqYdhCQoaib/04f440b4035b9183f18c16273128a62a/passwordless-email-magic-link-start-flow)

* **Code through email: **This works similarly to a magic link, but instead of a token, a one-time code is generated. This starts a session when a user retrieves the code from their email and puts it into the app or website.

 ![Passwordless create user flow](https://images.ctfassets.net/23aumh6u8s0i/2MBj8JJQOGQJJ3sZQTLp9j/15390089698f2c023766f63f5f52d819/passwordless-create-user-flow)

* **Code through SMS: **This is the same process as code through email, but the one-time code is sent through SMS instead. Auth0 [protects SMS messages](https://auth0.com/blog/how-passwordless-sms-authentication-can-improve-your-app/) with Twilio to keep everything secure.

* **Auth0 Guardian: **Instead of putting in a password, with Auth0 Guardian you can approve or deny login requests on a second device paired with your account via the Guardian app (compatible with smartphone or smartwatch). When there's a login attempt, you get a push notification that allows you to log in with the swipe of a finger.

 ![Guardian](https://images.ctfassets.net/23aumh6u8s0i/2kaQgBRWm9WJn5ZmXz6r2A/fd29598b45f95a3974cc006fe16c80a0/guardian)


## How does the safety of passwordless authentication compare to other logins?

The technical side of both passwordless and username + password authentication has many considerations. It's up to the company to make sure that they are storing customer information correctly and to protect it from hacks. There are best practices for each method, and, if done correctly, there isn't a runaway winner.

Here's a brief rundown of how things stack up on the technical side of things:

* **Numerical Passcode:** Apple cites a [1-in-10,000 chance](https://support.apple.com/en-us/HT204587) of a numerical passcode being guessed (or generated).
* **Passwords and passphrases:** If a password or passphrase is unique and complex, it can be a perfectly adequate form of security.
* **Login codes and magic links: **Since each time a login code or link is used it is generated, there isn't the same type of risk for a security risk via brute force generation. When a login code or link is sent, an IAM should ensure that the channel is secure. If the code or link is not used within a certain time frame, login access will expire, to guard against malicious use.
* **SMS risks:** Codes sent via SMS may carry more risk factors because of [phone networks' vulnerabilities](https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/), but otherwise operate similarly to other login codes and magic links.
* **Guardian:** App authenticators like Auth0's Guardian also use token generators, but have the benefit of not relying on SMS messaging.

All good IAM systems like Auth0 will have safety nets in place to mitigate the risks of brute force attacks, recognize malicious login attempts, and alert users of potential threats. They will also have advanced encryptions to keep data safe and will do their utmost to protect data at every step of the process.

Where things really get interesting is how user behavior affects the safety of login systems.

 Unfortunately, even the best-laid plans can be rendered insecure when people use unsafe login practices. Let's look at how user behavior can compromise the safety of authentication, and especially how passwordless authentication deals with this.

### Username + Password

By now, it's pretty clear: we reuse the same passwords over, and over, and over. The Telegraph reported that “the data shows that at least some people are still [failing to heed even the most basic security principles](http://www.telegraph.co.uk/technology/2016/01/26/most-common-passwords-revealed---and-theyre-ridiculously-easy-to/) about secure codes.” When you look at the [best ways to keep your personal information secure](https://auth0.com/blog/personal-information-security-identity-guide/), it's no wonder why: it takes time and attention to ensure security with a password.

With an average of [130 accounts](http://blog.dashlane.com/wp-content/uploads/2015/07/MailboxSecurity_infographic_EN_final1.jpg) registered to one email in the US, it's not surprising that [73% of users](https://www.telesign.com/resources/research-and-reports/telesign-consumer-account-security-report/) have duplicate passwords. To remember 130 different passwords would be extremely difficult for anyone — and probably send password retrieval requests through the roof.

![Online hoarders](https://images.ctfassets.net/23aumh6u8s0i/48ke2yiPybnTWFoygBIrXC/3874e42b7458bd3bba467478453ac53c/online-hoarders)

These bad habits can make it hard to protect your users, no matter how good your system is. When one password is used across multiple accounts, that's a huge risk that is completely out of your hands.

### Eliminating The Password

Passwordless authentication, by its nature, eliminates the problem of using an unsafe password. This means that one of the biggest user errors is taken out of your login.

One of the biggest skepticisms around passwordless authentication is the idea that using a channel like email to send a code or link can be unsafe because it can be compromised. This is a legitimate concern, but a compromised email account could also be used to “reset” a password, and therefore this concern presents no additional risk for the passwordless method over username + password login.

Passwordless authentication can also have the added benefit of two devices required for login. If you are authenticating with Auth0 Guardian, for example, you would need the device paired with the account in order to access that account, even if you knew the username. Of course, it is possible for devices to be stolen, but it makes malicious logins more difficult

Requiring two devices for login is part of multi-factor, physical authentication, which is the most secure login option. Each individual method has a [single point of failure](http://www.imore.com/talk-mobile/future-authentication-biometrics-multi-factor-and-co-dependency-talk-mobile), and multi-factor authentication helps reduce impact of a single system's flaws.

## For login, passwordless is the future

Although this has not been an exhaustive exploration into all of the safety considerations relevant to the username + password and passwordless methods, it's clear that the technical foundations of passwordless authentication are safe and robust.

Although username + password is currently the most familiar login method, it is by no means the gold standard. Yes, much of this rests on the way that users behave. Unfortunately, humans simply aren't built to remember and use different secure passwords for all of our 130 accounts.

Passwordless authentication, then, is becoming an increasingly relevant option for login. Users are connected to more devices and have more accounts than ever, which means that the passwordless approach is only growing more convenient for users. Sometimes it's also the case that you have to save the user from themselves — and for that, passwordless* is* a clear winner.

Is Passwordless Authentication More Secure Than Passwords?

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

Stormpath is shutting down Aug 18, 2017. Learn how to migrate your existing Stormpath users to Auth0 without requiring your users to reset their passwords.

---

**TL;DR** Stormpath announced today that it was acquired by Okta. As a result, the Stormpath API will be shutting down this coming August as the team transitions to Okta. Customers have until August 18, 2017 to export their user data to Okta or a different provider. Find out how to easily migrate your users to Auth0 without requiring your users to reset their passwords and some additional benefits you'll gain by making the switch. If you would like to follow along with our demo, download the sample app from [GitHub](https://github.com/auth0-blog/migrate-stormpath-users-to-auth0/tree/master/).

---

[Stormpath](https://stormpath.com) is an authentication as a service company that allows developers to offload their authentication and authorization needs to a third party. The company offered a RESTful API that customers could use to manage identity in their applications. Today, the company [announced](https://stormpath.com/blog/stormpaths-new-path) that it had been acquired by [Okta](https://www.okta.com), another company that provides identity management services.

![Acquisition announcement](https://images.ctfassets.net/23aumh6u8s0i/1KJLrUakWKfawgsxdBFZth/3edb24a5aac1fd1a7522e702f0a704f8/acquisition)

Acquisitions in the software industry are a norm. What is surprising about this acquisition is that the Stormpath product will be shut down later this year as the team transitions to Okta and many customers will have to find an alternative. Customers have until **August 18, 2017** to find a new provider, get it up and running, and export their existing users. This could be a challenging amount of unexpected work in such a short time frame.

<include src="TweetQuote" quoteText="Stormpath customers have until August 18, 2017 to migrate off the platform as it is being shut down!"/>

At [Auth0](https://auth0.com), our goal is to provide the best authentication and identity management solution that is also simple and easy for developers to work with.

<blockquote class="twitter-tweet" data-lang="en"><a href="https://twitter.com/auth0">@auth0</a> should open user migration to everyone from <a href="https://twitter.com/goStormpath">@goStormpath</a> and gain all those clients that can&#39;t move to okta. <a href="https://twitter.com/hashtag/wearesorry?src=hash">#wearesorry</a>&mdash; Tom Compagno (@TomCompagno) <a href="https://twitter.com/TomCompagno/status/838825630078660608">March 6, 2017</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

**You ask, we deliver :)!** We're offering the database migration feature for free for all Stormpath customers 💥!

## Custom Database Migration Made Easy with Auth0

The most important thing you are probably concerned with right now is how to migrate your existing users with minimal impact to your applications. At Auth0 we hope to greatly reduce your stress and anxiety with our painless user import functionality.

The way this feature works is by setting up a [custom database connection](https://auth0.com/docs/connections/database/mysql) and connecting it to your Stormpath account. When your users login the first time, they will enter their existing Stormpath credentials and, if authenticated successfully, we will automatically migrate that user account from Stormpath into Auth0. Your users will not have to change their password or jump through any additional hoops and you can decide what data to port over from Stormpath. Next time the user logs in, Auth0 will detect that they have been migrated and authenticate them with their Auth0 account.

![Auth0 User Migration](https://images.ctfassets.net/23aumh6u8s0i/2o0NcjoJdvUBx7AiZztxkg/6fcb081c1c17597cf37095725459da81/migrating-copy)

Talk is cheap, so let me actually walk you through the steps.

### Implementing the Database Migration Scripts

First of all you will need an Auth0 account. <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Signup for free here.</a> With your account created, let's setup a custom database connection. In your Auth0 [management dashboard](https://manage.auth0.com), navigate to the [database connections](https://manage.auth0.com/#/connections/database) section.

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

![Create DB Connection](https://images.ctfassets.net/23aumh6u8s0i/48UDN4ZvSqdmy5Ievrc1sR/f78bd0c795f68b2d5a2cb5d266d3dd81/create-db-connection)

You can name your connection anything you like. Leave all the default settings as is for now and click the **Create** button to create the connection.

![Setup Custom DB Connection](https://images.ctfassets.net/23aumh6u8s0i/6rrp1qEEoY4dxrXe8axQvu/0d73729a8811b54500327bb603e59b91/configure-db)

Next, let's go into this database connection and connect it to our Stormpath account. Click on your newly created connection and navigate to the **Custom Database** tab. Flip the switch titled "Use my own database" and the **Database Action Scripts** section will be enabled. This is where we will write our code to connect to your existing Stormpath user datastore. We will need to write two scripts: **Login** and **Get User**. **Login** will proxy the login process and **Get User** will manage looking up accounts when a user attempts to reset their password.

![Enable Custom Database](https://images.ctfassets.net/23aumh6u8s0i/23Z1dp5ad3L8AKItc6YfgT/7089780e5e9e9aa0f91b972caad23385/enable-custom-db)

With our custom database feature turned on, let's enable the import functionality. By default the custom database connection will allow us to authenticate with an external database. If we want to migrate users from the external platform into Auth0 we'll need to simply toggle a switch. Go to the **Settings** tab of the connection and flip the switch titled "Import Users to Auth0" and you're done.

![Import Users to Auth0 Switch](https://images.ctfassets.net/23aumh6u8s0i/4uB3CXu4ZaERpzAjWdcuSW/14f743da4e1e17bb0c16f759e9c148e8/import-to-auth0)

One final step we'll do before implementing our scripts is enabling this connection for our default client. Navigate to the **Clients** tab while you are in your database connection and flip the switch to enable this client for the Default Connection. *If you already have an existing Auth0 account, the connection name may be different.*

![Enable Database Connection](https://images.ctfassets.net/23aumh6u8s0i/6XGYxllP60DPLPJgm9X1TE/ceb49017e52c3267b524f4d456ffde3e/enable-connection)

### Login
The **Login** script is executed when a user attempts to sign in but their account is not found in the Auth0 database. Here we will implement the functionality to pass the user credentials provided to our Stormpath user datastore and see if that user is valid. Auth0 provides templates for many common databases such as MongoDB, MySQL and Sql Server, but for Stormpath we will have to write our own. We will utilize Stormpath's REST API to authenticate the user. Let's look at the implementation below:

```js
function login(username, password, callback) {
 // Replace the YOUR-CLIENT-ID attribute with your Stormpath ID
 var url = 'https://api.stormpath.com/v1/applications/{YOUR-CLIENT-ID}/loginAttempts';

 // Stormpath requires the user credentials be passed in as a base64 encoded message
 var message = username + ':' + password;
 var pass = new Buffer(message).toString('base64');

 // Here we are making the POST request to authenticate a user
 request({
 url: url,
 method: 'POST',
 auth: {
 // Your API Client ID
 user: '{STORMPATH-CLIENT-ID}',
 // YOUR API Client Secret
 password: '{STORMPATH-CLIENT-SECRET}'
 },
 headers: {
 'Content-Type': 'application/json'
 },
 json: {
 type: 'basic',
 // Passing in the base64 encoded credentials
 value: pass
 }
 }, function (error, response, body) {
 // If response is successful we'll continue
 if (response.statusCode !== 200) return callback();
 // A successful response will return a URL to get the user information
 var accountUrl = body.account.href;

 // We'll make a second request to get the user info. This time it will be a GET request
 request({
 url: accountUrl,
 method: 'GET',
 auth: {
 // Your API Client ID
 user: '{STORMPATH-CLIENT-ID}',
 // YOUR API Client Secret
 password: '{STORMPATH-CLIENT-SECRET}'
 }
 }, function (errorUserInfo, responseUserInfo, bodyUserInfo) {
 // If we get a successful response, we'll process it
 if (responseUserInfo.statusCode !== 200) return callback();

 var parsedBody = JSON.parse(bodyUserInfo);
 // To get the user identifier, we'll strip out the Stormpath API
 var id = parsedBody.href.replace('https://api.stormpath.com/v1/accounts/', '');

 // Finally, we'll set the data we want to store in Auth0 and migrate the user
 return callback(null, {
 user_id : id,
 username: parsedBody.username,
 email: parsedBody.email,
 // We set the users email_verified to true as we assume if they were a valid
 // user in Stormpath, they have already verified their email
 // If this field is not set, the user will get an email asking them to verify
 // their account
 email_verified: true,
 // Add any additional fields you would like to carry over from Stormpath
 });
 });
 });
}
```

### Get User
The **Get User** script is executed when the user attempts to do a password reset but their account is not found in the Auth0 database. The **Get User** script interfaces with your Stormpath datastore and checks to see if the user exists there. If the user does exist, their data is sent back to Auth0 where the user is automigrated and a password reset email is sent out from Auth0. Once the user confirms the reset, they are good to go and can access your app. Subsequent logins will be authenticated against the Auth0 database as the users profile is now stored with Auth0.

Let's look at our implementation of the **Get User** script for Stormpath:

```js
function getByEmail(email, callback) {
 // Replace the YOUR-CLIENT-ID attribute with your Stormpath ID
 var url = 'https://api.stormpath.com/v1/applications/{YOUR-CLIENT-ID}/accounts';

 request({
 url: url,
 method: 'GET',
 auth: {
 // Your API Client ID
 user: '{STORMPATH-CLIENT-ID}',
 // YOUR API Client Secret
 password: '{STORMPATH-CLIENT-SECRET}'
 },
 qs: { q: email }
 }, function (error, response, body) {
 if (response.statusCode !== 200) return callback();

 var parsedBody = JSON.parse(body);
 var user = parsedBody.items[0];

 if (!user) return callback();

 var id = user.href.replace('https://api.stormpath.com/v1/accounts/', '');

 return callback(null, {
 user_id: id,
 username: user.username,
 email: user.email,
 email_verified: true,
 // Add any additional fields you would like to carry over from Stormpath
 });
 });
}
```

With these two scripts we have user migration setup and ready to go. To test it and make sure our code works, let's build a simple application that allows a user to login and request protected resources via an API. We'll build the frontend with Angular 2 and the backend we'll power with Spring.

### Building the Frontend

We will build our frontend with Angular 2. We'll use the [Auth0 Angular 2 Quickstart](https://github.com/auth0-samples/auth0-angularjs2-systemjs-sample/tree/master/01-Login) to get up and running quickly. Our source code can be found [here](https://github.com/auth0-blog/migrate-stormpath-users-to-auth0/tree/master/frontend). Auth0 provides a comprehensive set of quickstarts, SDKs, and guides for many popular languages and frameworks. See them all [here](https://auth0.com/docs). With the project downloaded, we'll need to setup our Auth0 credentials. We'll do that in the `auth.config.js` file. Open the file and change the values to look like this:

```js
"use strict";
exports.myConfig = {
 // Your Auth0 ClientID.
 clientID: '{AUTH0-CLIENT-ID}',
 // Your Auth0 Domain
 domain: '{YOUR-AUTH0-DOMAIN}.auth0.com'
};
```

Both of these values can be found in your Auth0 [management dashboard](https://manage.auth0.com). In the dashboard, simply click on the **Clients** link from the main menu, and select the **Default Client** that was created when you signed up. *If you already had an Auth0 account, select the client that has the database connection with the custom database enabled*.

With these values configured save the file and run `npm install`. Once npm has installed all the required dependencies, run the project by executing `npm start`. Navigate to `localhost:3000` to see the app in action.

![Angular 2 Frontend](https://images.ctfassets.net/23aumh6u8s0i/18HQrQSCSg4y9UrCi7sMV0/c0f3debbce23cf2c9c11f17ddc9ced09/app-new)

Click on the **Login** button to login to your application. Clicking the **Login** button will bring up the Auth0 [Lock](https://auth0.com/lock) widget and ask the user to provide their email and password. Here, the user will provide their Stormpath email and password credentials and if they are correct they will be logged in. If you don't already have a Stormpath user account you can login with, go into your Stormpath dashboard and create an account. Now login with your Stormpath user credentials.

![Angular 2 Login with Lock](https://images.ctfassets.net/23aumh6u8s0i/5bzzMjL0c5aW0869E46Y5q/366034baff0d48ddb16c51c5471c3bfd/lock)

> [Lock is an embeddable login form for desktop, tablet and mobile devices.](https://auth0.com/lock) It provides the easiest way for securing your website and mobile apps.

Notice that you are instantly logged in. If we look at the response data from the transaction we'll see that the user is coming from the **Stormpath-Users** connection alongside other data that we imported. Let's make sure that this user was migrated to Auth0 as well. To check this we'll navigate to the [Users](https://manage.auth0.com/#/users) section of the Auth0 dashboard and we'll now see the user we logged in with.

![User Migrated](https://images.ctfassets.net/23aumh6u8s0i/7hkbvruJC8h7xLE7NTOCcE/214e761a53a243e2a3463b2012759986/migrated)

This means that our migration was successful. This user is now migrated to Auth0. The next time they login to the application, we'll check their credentials against Auth0's database instead of making the extra call to Stormpath. The workflow diagram below illustrates the process once again.

![Auth0 User Migration](https://images.ctfassets.net/23aumh6u8s0i/2o0NcjoJdvUBx7AiZztxkg/6fcb081c1c17597cf37095725459da81/migrating-copy)

Now you may notice the two links `Call Public API` and `Call Private API`. Let's build a simple backend that will return data when these links are clicked. We'll do that next.

### Building the Backend

For our backend, we'll build a simple Spring Boot application that exposes a RESTful API. You can get the code for the sample application [here](https://github.com/auth0-blog/migrate-stormpath-users-to-auth0/tree/master/backend). To setup the application, you will just need to update the application with your credentials. The file where the credentials are stored is called `auth0.properties` and can be found in the `src/main/resources/` directory. Edit the file to look like so:

```
auth0.domain: {YOUR-AUTH-DOMAIN}.auth0.com
auth0.issuer: https://{YOUR-AUTH0-DOMAIN}.auth0.com/
auth0.clientId: {YOUR-AUTH0-CLIENT-ID}
auth0.securedRoute: NOT_USED
auth0.base64EncodedSecret: false
auth0.authorityStrategy: ROLES
auth0.defaultAuth0ApiSecurityEnabled: false
auth0.signingAlgorithm: HS256
```

With this update in place, you should be able to build the application by running:

```
mvn spring-boot:run -Drun.arguments="--auth0.secret=YOUR_SECRET_KEY"
```

If the application was built successfully, you will be able to access the API at `localhost:4000`. The two routes that are exposed by this application that we care about are `/public` and `/secure`. The `/public` route will be accessible by everyone, while the `/secure` route will return a successful response only if the user is authenticated and passes the correct credentials.

![Accessing Public API](https://images.ctfassets.net/23aumh6u8s0i/4MAMKVaISJhxqbpbRkoZmM/ec39376d8ca4ed42c3d97f698bd26496/public-api)

Once your backend is up and running go back to your frontend application and try clicking on the the two links `Call Public API` and `Call Private API`. The public API you will be able to access even when not logged in. For the private API, you will need to be logged in to call the route and get the appropriate response.

![Accessing Private API](https://images.ctfassets.net/23aumh6u8s0i/4ZQdzDiaiRv7B4Bq1bFS9c/ed20e52d6feff3101465e94efd7358a5/private-api)

We also used Angular 2 to add some dynamic classes. So if the user is logged in we'll make both of the buttons green to indicate they can be clicked.

![App when logged in](https://images.ctfassets.net/23aumh6u8s0i/7yVJJKoAH4iVnoLq46SYP5/ab53413fd2cd513d5fa7c1863e07f398/app-logged-in)

## Go Further with Auth0

I hope the user migration functionality I showed in this post helps with your use case. This gradual migration works great because it is transparent to your end-users. As the deadline approaches and Stormpath prepares to shut down their service, you may need to speed up the migration process. Auth0 can help here as well. You can [bulk import](https://auth0.com/docs/tutorials/bulk-importing-users-into-auth0) your existing user datastore into Auth0 or since we already wrote the **Get User** script you can send out a mass email to your users letting them know they need to change their password and by clicking on the link in the email their accounts will be migrated to Auth0.

Now that your migrates woes have been taken care of, let's briefly talk about what Auth0 brings to the table besides authentication and authorization. Many features that Auth0 provides can be enabled with the flip of a switch. [Multifactor authentication](https://auth0.com/multifactor-authentication) is one such feature. You can enable MFA using our in-house MFA solution, [Guardian](https://auth0.com/multifactor-authentication), with just the flip of a switch.

If you are already using a 3rd party MFA solution or have your own custom solution, you can continue to use it as well. The Auth0 [Rules](https://auth0.com/docs/rules) extensibility platform allows you to take control of the authorization workflow. Here you can configure any number of events such as triggering 3rd party MFA, performing progressive profiling, and much more.

We want to make your switch to Auth0 as painless as possible, so we are making the Database Migration feature free for all existing Stormpath customers. For customers switching from Stormpath to Auth0 and purchasing an Auth0 Enterprise Support plan, we are also offering 8 hours of professional services at no cost.

## Conclusion

Stormpath will be shutting down their authentication and authorization API's this coming August. Customers have until August 18, 2017 to move off the platform. At Auth0, we hope to give existing Stormpath customers an easy and smooth transition plan. Our database migration feature can start migrating your users today!

If you are affected by the Stormpath news and want to easily migrate your users, give Auth0 a try, <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 account</a> and get started today.

> Auth0 provides the simplest and easiest to use [User interface tools to help administrators manage user identities](https://auth0.com/user-management) including password resets, creating and provisioning, blocking and deleting users.

Easily Migrate Your Existing Stormpath Users to Auth0 

Tavis Ormandy, a vulnerability researcher at Google, discovered that Cloudflare was accidentally leaking sensitive data including passwords, private messages, and more. Learn how this may affect you and your customers and what to do next.



On February 17th, Tavis Ormandy, a vulnerabilities researcher at Google, sent the tweet that kicked off 2017's biggest security story yet:

![Tweet](https://images.ctfassets.net/23aumh6u8s0i/70lrHor3JHJ2mpMhcIYmD0/a8ae61fe8062a2abad060c9707f51819/tweet)

*Could someone from cloudflare security urgently contact me.* That's not something anyone wants to read on a Friday afternoon, but especially not when it's coming from one of the world's top infosec researchers.

The problem? While doing some routine bug checking, [Ormandy](https://twitter.com/taviso?lang=en) saw some data that did not match at all what he expected to find.

"It's not unusual to find garbage, corrupt data, mislabeled data or just ... non-conforming data...but the format of the data this time was confusing enough that I spent some time trying to debug what had gone wrong, wondering if it was a bug in my code," [he wrote](https://bugs.chromium.org/p/project-zero/issues/detail?id=1139), "In fact, the data was bizarre enough that some colleagues around the Project Zero office even got intrigued."

The rest of the Google Project Zero team (a team of security researchers employed specifically to find new [zero-day exploits](https://en.wikipedia.org/wiki/Project_Zero_(Google))) probably expected Google's announcement of the first [practical SHA-1 collision](https://auth0.com/blog/sha-1-collision-attack/) to be the big news of the week.

As they looked closer, they found “encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests” for all sorts of different sites using Cloudflare—private messages, reservations, plaintext API requests from a password manager, hotel bookings.

How did all of this happen?

## Cloudflare was dumping memory across the web

It begins with a simple bug in the code to Cloudflare's highly popular reverse proxy service. HTTP requests to certain types of sites signed up with Cloudflare would trigger the bug, which would then "leak" data from random* *Cloudflare customers' sites (those that happened to be in memory at the time).

![Cloudflare](https://images.ctfassets.net/23aumh6u8s0i/SFApl9rEVZFr1bZEQnm2k/1df7cc080c9c802b225f4610a0daee12/cloudflare)

*A simple depiction of how a reverse proxy like Cloudflare's works. Since reverse proxies are shared between customers, data from all was at risk of being disclosed.*

Since September, random bits of data have been coming out of initialized memory and leaking across random Cloudflare customer's sites. In other words, if you went to visit a site that used Cloudflare, you could have had other people's sensitive information “leaking” into your own browsing session.

When search engines “crawled” these pages to index them, the same kind of information “leaked.” Because search engines cache the output they receive when they visit a page, all these leaked tokens, secrets, and messages were indexed, split up and spread across *millions* of pages of search results.

![Search Results](https://images.ctfassets.net/23aumh6u8s0i/569KQNvP3RuTSc2z9FCZy/83586ba930635d2bace66281330bc291/SERPs)

(Source: [Wordfence](https://www.wordfence.com/blog/2017/02/cloudflare-data-leak/))

While Cloudflare is working with the major search engines to purge their caches of sensitive information now, it's hard to avoid thinking about the paranoid version of events.

Paranoid version: state actors, or state-sponsored actors with significant resources, discovered this vulnerability before Google did. They found a way to send manipulated HTTP requests to Cloudflare sites that would output a predictable stream of user data—and have either packaged everything they found for resale or set about figuring out how to crack what could be billions of passwords, credit card numbers, and secret tokens.  

Cloudflare claims they can rule out this scenario with access logs, but whether or not that's true has been subject to [some debate](https://news.ycombinator.com/item?id=13721452).

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

## What you should do now

The way that data was disclosed means that any site using Cloudflare could potentially have had its secrets and tokens compromised. Patreon, Yelp, Uber, Medium, Fitbit, and OKCupid all use Cloudflare—for a full list of sites you can [click here](https://github.com/pirate/sites-using-cloudflare). Several tools have also been [built to assess your risk](http://www.doesitusecloudflare.com/), like this script that [crawls your Chrome history](https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d586f064).

Though many, many sites use Cloudflare, at least to some degree. It's still quite unlikely that your personal information has been exposed. Many of the individual sites mentioned have also come out and written posts to explain whether you should be concerned—perhaps most notably, 1Password, which was initially mentioned in Tavis's tweets as a [potentially compromised site](https://blog.agilebits.com/2017/02/23/three-layers-of-encryption-keeps-you-safe-when-ssltls-fails/).

The first thing you want to do to protect yourself from this and future incidents is to enable [multifactor authentication](https://auth0.com/multifactor-authentication). The most important sites to enable MFA on are the ones you use as an SSO iDP—if you're logging into 20 different sites using your Google credentials, then you definitely want to enable some form of MFA there.

While it's unlikely your passwords were exposed, this is as good a reminder as any that you should be using strong, unique passwords and organizing them using a password manager.

Resetting individual passwords for sites doesn't make much sense—the list of compromised sites is simply so vast. The only solution is to do a mass reset and make sure you're using proper password hygiene going forward.

## What you should do for your customers

As a site operator, you're probably wondering 1) if you're at risk, and 2) if any of your users' data was exposed in this incident.

Cloudflare has already reached out to domain owners that they have proactively identified as being at risk in this leak. However, the absence of notification does not mean that your domain (and customers) are safe.

First off, enable multifactor authentication [if you haven't already](https://auth0.com/multifactor-authentication). It's the easiest way to get a huge boost to the security of your site.

Many site operators have begun forcing password resets for all of their users. If you run a consumer site, it may not be worth the trouble and inconvenience. If your customers are in the enterprise, then it is probably a very good idea to force a change. If you're not going to make your users change their passwords (and from a cursory browse of the web this Monday morning, it appears that this is mostly the case), then you should at least recommend it.

As far as data invalidation, any secrets which you can easily rotate—session identifiers, tokens, keys—should immediately be changed. Customer SSL keys do not appear to have been compromised in this incident, but it would be prudent to change as much data as you can which may have passed through Cloudflare.  

If you or any of your customers are regulated by the Health Insurance Portability and Accountability Act (HIPAA), then you'll [definitely want](https://www.aptible.com/blog/aptible-was-not-affected-by-cloudbleed/) to have your security/compliance teams get in touch with your lawyers and discuss whether this is a breach that needs to be reported.


What Cloudbleed Means for You and Your Customers

Username and password are not enough. So why do most companies still use them?

<div class="alert alert-info alert-icon">
 
 Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.
</div>

---

There’s a Technology Basics White Paper first published in 2002 entitled *“Username and Password – A Dying Security Model.”* This paper documents the **HIGH** risk level associated with legacy authentication (using username and password) and predicted that secure access methods using *Biometrics*, [*Single Sign On (SSO)*](https://auth0.com/learn/how-to-implement-single-sign-on/), [*One Time Password Tokens* (a.k.a *passwordless*)](https://auth0.com/passwordless) and [*Multi-Factor Authentication*](https://auth0.com/multifactor-authentication), would quickly replace the use of traditional passwords.

Fast forward to a decade and a half later and the majority of companies are still using username and password authentication. We all agree that legacy authentication is not good enough, so why do most companies still use them?


For many, the path to modern authentication seems difficult and expensive, while others worry about the impact on user experience.


Join me and Garrett Bekker (*Principal Security Analyst of 451 Research*) for a webinar where we will explore this paradox and discuss practices for making secure, modern authentication fast and easy for developers and simple and frictionless for users.

![Risks Posed By Legacy Authentication Webinar](https://images.ctfassets.net/23aumh6u8s0i/725zV9pN6ilKOKGJykmkiL/d6d69f5319e0bcfcff169f50c273574f/webinar-banner)

> The Webinar will be live online Jan 18 9:00 am PST or after on demand.

[Register now!](https://www.brighttalk.com/webcast/10363/235469?utm_source=Marketing&utm_medium=brighttalk&utm_campaign=235469)

Risks Posed By Legacy Authentication Webinar

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

Learn about NIST's Digital Authentication Guideline and what it means for authentication security.

<div class="alert alert-info alert-icon">
 
 The new 2019 NIST Privacy Framework Draft can help your organization meet its cybersecurity needs more efficiently and effectively. <a href="https://auth0.com/blog/5-takeaways-from-2019-nist-privacy-draft/?utm_source=auth0blog&utm_medium=messagebox&utm_campaign=nist_2019/">Read 5 valuable takeaways from the Privacy Framework.</a>
</div>

**TL;DR:** The US National Institute of Standards and Technology ([NIST](https://www.nist.gov/)) is creating new policies for Federal agencies implementing authentication. Learn about [NIST Special Publication 800-63-3: Digital Authentication Guideline](https://pages.nist.gov/800-63-3/sp800-63-3.html) and what it means for authentication security. 

---

## NIST Digital Authentication Guideline

The [US National Institute of Standards and Technology (NIST)](https://www.nist.gov/) has created new policies for Federal agencies implementing authentication.

![Digital Authentication Guideline: US NIST logo](https://images.ctfassets.net/23aumh6u8s0i/64gd0WJ9nBSh86HbwGfqzG/7327fa02c5c28b33128f8ce9895279d7/nist)

The Digital Identity Guidelines — [**Special Publication 800-63-3** — are available on the NIST website](https://pages.nist.gov/800-63-3/sp800-63-3.html) as well as [on NIST's GitHub](https://github.com/usnistgov/800-63-3). The suite of documents includes the following:

* [800-63-3: Digital Authentication Guideline](https://pages.nist.gov/800-63-3/sp800-63-3.html) (overview)
* [800-63A: Enrollment & Identity Proofing](https://pages.nist.gov/800-63-3/sp800-63a.html)
* [800-63B: Authentication & Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html)
* [800-63C: Federation & Assertions](https://pages.nist.gov/800-63-3/sp800-63c.html)

The policies are intended for Federal agency applications, but serve as a standard for many others as well.

## NIST Improved Password Requirements

The NIST Digital Authentication Guidelines strives for improved password requirements. One of the guiding principles is _better user experience_ and shifting the burden to the verifier whenever possible. In order to support the creation of passwords that users will remember while implementing excellent security, several guidelines are important:

* Length: 8 character minimum, >64 character maximum
* Compare new passwords to a [dictionary](https://auth0.com/docs/connections/database/password-options#password-dictionary) and don't allow common, easily-guessed passwords (such as `password`, `abc123`, etc.)
* Allow all printing characters + spaces
* Should offer option to show password rather than dots or asterisks; helps typing accuracy
* Don't enforce composition rules (ie., no "passwords must include uppercase and lowercase letters, a number...", etc.); such rules provide a poor user experience
* Don't use password hints; they weaken authentication 
* Don't expire passwords arbitrarily; regular expiration encourages users to choose easy-to-guess, less secure passwords
* Don't use [Knowledge-based Authentication (KBA)](https://en.wikipedia.org/wiki/Knowledge-based_authentication)

## NIST Guidelines for Password Storage

NIST also supplies guidelines for the verifier's encryption and storage of passwords. These policies ensure that [passwords are stored securely](https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/):

* Passwords shall be hashed with 32-bit (or greater) random salt
* Use approved key derivation function [PBKDF2](https://www.ietf.org/rfc/rfc6070.txt) using [SHA-1, SHA-2, or SHA-3](https://en.wikipedia.org/wiki/Secure_Hash_Algorithm) with at least 10,000 iterations
* Passwords should use keyed [HMAC](https://tools.ietf.org/html/rfc2104) hash with the key stored separately

## NIST on Multifactor Authentication

NIST recommends utilizing [out-of-band (OOB) authentication](https://www.techopedia.com/definition/29532/out-of-band-authentication-ooba) to provide [2-factor Authentication (2FA)](https://auth0.com/learn/two-factor-authentication/). The guidelines also state that **SMS is _deprecated_ for OOB authentication**. SMS can be compromised by a variety of threats such as smartphone malware, [SS7 attacks](https://www.theguardian.com/technology/2016/apr/19/ss7-hack-explained-mobile-phone-vulnerability-snooping-texts-calls), forwarding, change of phone number, and more.

Examples of non-SMS OOB authenticators include [Auth0 Guardian](https://auth0.com/docs/multifactor-authentication/guardian), [Duo Mobile](https://duo.com/solutions/features/two-factor-authentication-methods/duo-mobile), and [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en). NIST states that use of biometrics must be _with_ another authentication factor for [Multifactor Authentication](https://auth0.com/docs/multifactor-authentication).

## Conclusion

Overall, the new guidelines put the user experience at the forefront while also establishing more robust storage and authentication methods. Although the NIST Digital Authentication Guideline governs Federal sites, its tenets are good standards for _any_ app or site with authentication. Federal agencies as well as many other companies and vendors must make strides to comply with the new guidelines for improved authentication security and user experience. **Auth0 supports the NIST guidelines** with more configurable password policies. To learn more, check out the [NIST Special Publication 800-63-3](https://pages.nist.gov/800-63-3/sp800-63-3.html) itself and [Jim Fenton's "Toward Better Password Requirements"](http://www.slideshare.net/jim_fenton/toward-better-password-requirements) presentation.

What the New NIST Guidelines Mean for Authentication

New features make it easy for subscribers to ditch passwords and enable their users to log in with just an email account or mobile phone

**BELLEVUE, Wash.**--(BUSINESS WIRE)--[**Auth0**](https://auth0.com), the leading universal identity platform, today introduced [passwordless authentication](https://auth0.com/passwordless), allowing developers to quickly and easily implement secure authentication for their apps without the need for passwords. Passwordless authentication through Auth0 uses email, or SMS to replace a username and password for any application. Also released today is Auth0’s ‘Lock Passwordless’ - a free login box widget for software developers that can be integrated into any web, native or mobile application with just a few lines of code, almost effortlessly enabling use of a fingerprint or one-time access code or link.

*“Passwords can be easily forgotten or stolen,”* said Auth0 CEO, Jon Gelsey. *“By eliminating the need for users to remember passwords, developers and IT professionals can reduce hassles for their users, greatly increase the security of their apps, APIs and IoT devices, and accelerate user acquisition. Now, any application can easily incorporate simple yet strong multifactor identity security.”*

Passwordless authentication uses either a fingerprint, a temporary secret link, a temporary secret code, or a combination of the three to allow access and authenticate a login. The link or code is sent to a user’s verified email address or phone number, or is displayed on an authenticator app on their phone. The link or code expires after a few minutes, ensuring that others cannot gain access if the code becomes compromised. In addition, OS native fingerprint identification can also use the fingerprints of a pre-registered user to log them in. Email, and SMS passwordless authentication can be implemented with just a few lines of code and Auth0’s cloud platform, and can be combined with other features such as multifactor authentication.

*“Human error associated with passwords is a common entry point for hackers to exploit. The prevalence of easy-to-guess passwords or passwords compromised through exploits is low-hanging fruit for black hats,”* Gelsey continued. “Passwordless authentication makes access more secure, while removing the burden of remembering and typing a strong password on a phone.”

<include src="TweetQuote" quoteText="Human error associated with passwords is a common entry point for hackers to exploit."/>

Auth0’s goal is to make secure identity implementation and management easy for developers and IT professionals. Auth0’s passwordless authentication can be used with any identity provider or application, making the migration away from traditional passwords extraordinarily simple. This announcement is the latest addition to Auth0’s comprehensive and ever-growing universal identity security platform which also helps subscribers implement single-sign-on (SSO), multifactor authentication (MFA), and much more across any application, API or IoT device.

<include src="asides/AboutAuth0" />

Auth0 Introduces Passwordless Authentication

0cd73f2f2f39709bd03646e9225cc3d3?s=200 avatar

0cd73f2f2f39709bd03646e9225cc3d3?s=200

I’m an engineer with a passion for building frictionless products. I’ve built effective teams and have grown them into successful engineering organizations. I like to forge a culture.

CTO and Co-founder

Matias Woloski

SMS Authentication and Email Authentication made easy and secure.

**TL;DR**: Auth0 Passwordless is a drop-in authentication system based on Email or SMS, that improves security and user experience. Check it out [auth0.com/passwordless](https://auth0.com/passwordless).

---

It’s clear that passwords are not fun anymore. According to the website [haveibeenpwned.com](http://haveibeenpwned.com), **220,385,281 accounts were exposed in the top 10 breaches**, and **152,450,038 of them were compromised this past year**. On the other hand, according to a [study](https://www.passwordboss.com/password-habits-survey-part-1/), **more than half (59%)** of the users surveyed admit they **reuse the same password** because it’s hard to remember them.

What is our industry doing to address this problem?

<ol>
 <li>A second factor of authentication (Google Authenticator, SMS, etc.)</li>
 <li>Password managers</li>
</ol>

A second factor significantly reduces the risk of your account being compromised. We support [multifactor](https://auth0.com/docs/mfa) at Auth0 and it has been a very popular feature, but you still have a password to remember and the second factor introduces more complexity and friction to the average user. Password managers are useful (I personally use one) but still they feel like a band-aid on the problem, not addressing the real issue.

A third trend we've started to see is to **remove the password input from the login box altogether**. Companies like Medium, Slack, Twitter, and WhatsApp are already doing it, and even Google’s new login screens [hints at a future beyond passwords](http://techcrunch.com/2015/05/13/gmails-new-login-screens-hints-at-a-future-beyond-passwords/).

![trend to remove password input from login box](https://images.ctfassets.net/23aumh6u8s0i/63OzRLWXLoi0U5GcahbAkO/489c9d4936977197f4502ff48731447d/pwdless1)


We’ve been experimenting over the past few months, and we’re ready to release our first version today. With [Auth0 Passwordless](https://auth0.com/passwordless) you can use one time codes or “magic links” delivered via SMS or e-mail without having to worry about the implementation details.

## Log in via e-mail or SMS, simplified

Following our philosophy of "just a few lines of code", here is how you trigger a "magic link" that will be sent to the user’s email:


```
var lock = new Auth0LockPasswordless('client-id', 'yours.auth0.com');
lock.magiclink();
```

And log in via SMS is this simple as well:


```
var lock = new Auth0LockPasswordless('client-id', 'yours.auth0.com');
lock.sms(options, function(err, profile, jwt) {
 alert('welcome ' + profile.phone_number);
});
```

Try this yourself on the [playground](https://auth0.github.io/lock-passwordless).

## What's behind this?

Although conceptually simple, implementing passwordless authentication requires coordination of many components. And [Auth0 Passwordless](https://auth0.com/passwordless) takes care of them all. These components include:

* A [public API](https://auth0.com/docs/auth-api#passwordless) with appropriate rate limiting that prevents abuse.
* A beautiful, extensible and open source client [JavaScript API](https://github.com/auth0/auth0.js#passwordless-authentication) library and [UI widget](https://github.com/auth0/lock-passwordless) for Web apps.
* An open source native component and UI widget for [iOS](https://github.com/auth0/Lock.iOS-OSX) and [Android](https://github.com/auth0/Lock.Android).
* Integration with well known, scalable and secure Email (SendGrid, Mandrill and Amazon SES) and SMS providers (Twilio).
* An admin dashboard to manage and customize all of the above.

We implemented all of these and made it easy, accessible and secure to everyone. We also docummented typical questions that come up around passwordless: check out the [FAQ](https://auth0.com/docs/connections/passwordless/faq).

## Works everywhere

As developers we have to deal with a handful of devices, screen sizes, and browser-specific challenges. We wanted the [Lock Passwordless](https://github.com/auth0/lock-passwordless) widget to automatically adapt to mobile web browsers on various iOS and Android versions.

Auth0 Passwordless can be used on all platforms: native apps, web apps, mobile web, command line interfaces or anything that can send an HTTP request over the net. It's a great way to achieve [Single Sign On](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog) across everything with a single uniform authentication scheme across the board.

<include src="TweetQuote" quoteText="Auth0 Passwordless can be used on all platforms and anything that can send an HTTP request over the net."/>

## Future directions

We are seeing a trend that web applications are moving to longer session expirations so that **users are not asked to log in frequently** - similar to a native app on a mobile device. Then, whenever a user asks to perform a sensitive operation, they’re asked for **"step up" authentication** (think "sudo" command on Linux). [Auth0 Passwordless](http://www.businesswire.com/news/home/20150930005480/en/Auth0-Introduces-Passwordless-Authentication) is a way to implement such a mechanism quickly and securely. Combine this with **anomaly detection**, **suspicious logins** and **centralized session revocation** and you have a robust yet usable authentication system.

Auth0 Passwordless is **ready to be used in production** today and it is **included in every Auth0 plan**.

We can’t wait to see what you will build. And we look forward to continuing to contribute more improvements to identity and security on the web 🔐.

[Want to learn more about Single Sign-On? Get The Definitive Guide on SSO (74-page free eBook) here.](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)

Log in without Passwords: Introducing Auth0 Passwordless

d48b998c2dce49ca309710eba498c562

Nathan Totten

Remembering usernames and passwords and login urls for all of these apps is a pain. With this app we take another step in simplifying the authentication experience.

<div class="alert alert-info alert-icon">
 
 Update: The Single-Sign-On Dashboard referred in this article is now deprecated and has been replaced with the extension that can be found here: <a href="https://auth0.com/docs/extensions/sso-dashboard">Auth0 Extension: Single Sign-On (SSO) Dashboard</a>.
</div>

**tl;dr**: Control which apps your users can access with an SSO dashboard. Download the [code](https://github.com/auth0/auth0-sso-dashboard) or [deploy to Heroku](https://dashboard.heroku.com/new?template=https%3A%2F%2Fgithub.com%2Fauth0%2Fauth0-sso-dashboard) in 5 minutes.

Today, we are excited to announce the release of the Auth0 [Open Source Single-Sign-On Dashboard](https://github.com/auth0/auth0-sso-dashboard). This SSO dashboard is designed to solve a problem familiar to many people. Organizations of all sizes maintain a variety of different applications to handle various business functions like accounting, HR, development, support, etc. Remembering usernames and passwords and login urls for all of these apps is a pain. With this app we take another step in simplifying the authentication experience.

<include src="TweetQuote" quoteText="Today, we are excited to announce the release of the Auth0 Open Source Single-Sign-On Dashboard."/>



![SSO Dashboard](https://images.ctfassets.net/23aumh6u8s0i/52rZ04u2zwgwGtEGzjtim0/4c2a917d6d5fe7fd6a01b84a99e20db0/cfENOYpKxfL_)

You can find the entire source of this project on [Github](https://github.com/auth0/auth0-sso-dashboard) along with instructions on how to deploy and configure a dashboard for your own organization. Additionally, you can try out a demo version (with non-functional apps) at [https://ssodashboard.herokuapp.com](https://ssodashboard.herokuapp.com). Username: `publicdemo` Password: `TestUser123`. This demo only shows the user functionality; if you would like to see the full admin capabilities, please deploy your own instance.

A few key features of the SSO Dashboard:

* Landing page showing all apps that a user is allowed to access.
* Self-service user profile updates.
* Administrator interface for configuring roles, apps, and users.
* Completely customizable UI.

## Completely Open Source
Our approach to this project, like many projects at Auth0, was to build this as an open source app. This approach gives our users the most flexibility while still being very easy to maintain and receive updates.

* Node.js Backend (Express)
* React, Flux, and React-Router
* Bootstrap ([Paper Theme](https://bootswatch.com/paper/)) and [Material UI](http://callemall.github.io/material-ui/#/)
* [Babel](https://babeljs.io/) to enable ES6
* [Webpack](https://webpack.github.io/) for asset bundling

Feel free to fork and clone this project. We will accept pull requests and [issues](https://github.com/auth0/auth0-sso-dashboard/issues) if you want to contribute back.

If this is something you have been looking for at your company or organization do give it a try. Let us know what you think, we will be adding features based on feedback.

"passwords"