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'><strong>Cosmos</strong></a>.<br /><br />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 <strong>over 600,000 unique visitors per month</strong> is quite challenging!<br /><br />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)'><strong>Sign up for a free account</strong></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

jimena-garbarino

Jimena is an experienced result and value-oriented programmer with a strong engineering background. She excels with Ruby on Rails, Java, and Scrum development. She has worked in web development for 10+ years in many industries and has a master's degree in software engineering from Universidad de Buenos Aires.

Spring Cloud Developer

Jimena Garbarino

Storing secrets in your code is a bad idea. Learn how to use Spring Cloud Config and HashiCorp Vault to make your app more secure.

Secure Secrets with Spring Cloud Config and Vault

andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

Encoding, Encryption, and Hashing have different goals and shouldn't be confused. Learn the differences.

Sometimes people use the terms encryption and encoding interchangeably. Also, often hashing is called into play as an encryption mechanism. Confusing these concepts may lead to misunderstandings in the way security is implemented.

Let's take a high-level overview of these concepts and clarify the differences.

If you prefer watching videos, here is a video version of this article:

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

<NonAmpContent>
<div
  class='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/-bAnBzvMLig'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

## What Is Encoding?

Let's start with encoding. You can define it as **a technique to transform data from one format to another so that it can be understood and consumed by different systems**.

Basically, encoding has to do with information representation. When you have some information, say the [name of the mineral that weakens Superman](https://en.wikipedia.org/wiki/Kryptonite), you can represent it through letters, as in *kryptonite*. This is a handy representation for humans but not so easy for being manipulated by computers. What usually happens, in this case, is the transformation of this sequence of characters into a sequence of bits like this:

```
01101011 01110010 01111001 01110000 01110100
01101111 01101110 01101001 01110100 01100101
```

You have two representations for the same information. The letter-based representation is usually understood by *human systems*; the bit-based representation is more suitable for computer systems. Commonly, you say that the sequence of letters has been *encoded* into a sequence of bits.

So, encoding is just a transformation from one data representation to another, keeping the same information. Usually, it involves a conversion table, such as an [ASCII table](https://en.wikipedia.org/wiki/ASCII) in our example, that maps a representation item in one system to the corresponding representation item in the other system.

You can find several encoding mechanisms out there. To mention just a few in the character encoding space, apart from the dear old ASCII, you have:

- [Unicode](https://en.wikipedia.org/wiki/Unicode), which allows you to represent more complex items than letters, such as emoji and other symbols.
- [Base64](https://en.wikipedia.org/wiki/Base64), which lets you represent binary data, such as an image, through text.
- [URL encoding](https://en.wikipedia.org/wiki/Percent-encoding), useful to represent arbitrary data in an URL, where some characters are reserved or cannot be used (think of spaces or colons, for example).

Consider [JSON Web Tokens (JWT)](https://jwt.io/introduction), for example. The three parts that compose a token are encoded using [Base64-URL](https://www.rfc-editor.org/rfc/rfc4648#section-5), a variant of Base64 encoding combined with URL encoding. The following is an example of encoded JWT:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsw
```

You can see the decoded version of this JWT using the [jwt.io](https://jwt.io/?id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsw) debugger.

This encoding mechanism allows the token to be easily passed in HTML and HTTP environments without fear of clashes with reserved or unrepresentable characters. If you want to learn more about JWTs, you can download [the JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook).

Encoding ensures **interoperability** between systems. It allows systems that use different data representations to share information.

Encoding has **no security purpose**. Anyone who knows the conversion algorithm can encode and decode data. The conversion algorithm is not kept secret. On the contrary, it is public in order to facilitate interoperability between systems.

Finally, encoding is a **reversible process**. You can transform a piece of data from one representation to another and then go back to the original representation without information loss.

<include src="BigQuote" quoteText="Every decoding is another encoding.." quoteAuthor="David Lodge" />

## What Is Encryption?

Encryption is **a technique that makes your data unreadable and hard to decode for an unauthorized user**.

So, basically, encryption is a mechanism that transforms data into a different representation so that prying eyes cannot understand it. Wait! Isn't this transformation the same as encoding after all? 🤔

How can a human being understand that the following sequence of bits represents the word *kryptonite*?

```
01101011 01110010 01111001 01110000 01110100
01101111 01101110 01101001 01110100 01100101
```

In fact, the question is not far-fetched. In a way, encryption is a form of encoding. It transforms data from one representation to another. For this reason, sometimes, people use the terms encryption and encoding interchangeably. However, the purpose of encryption is different from the encoding's one.

Look at the definition above. The encryption technique aims at making data **unreadable and hard to decode**. If you think about it for a moment, it is the opposite reason of pure encoding: encoding aims at making data as much understandable as possible across systems while encryption tries to make it undecipherable, unless you are authorized.

The main goal of encryption is to ensure **data confidentiality**, i.e., protecting data from being accessed by unauthorized parties.

So, while encoding makes its conversion algorithms as public as possible, encryption should keep such algorithms private. Actually, it's not really like that. Relying on secret algorithms is not the best choice to protect data in the long run. Better solutions rely on well-known algorithms whose data transformation is based on sequences of numbers or letters called *keys*.

> Do not create your own encryption algorithm unless you are a Math expert with a long experience in the cryptography field.

The best mechanisms to encrypt data are based on mathematical algorithms that can be solved only with the possession of a key or with advanced computational power. Two families of key-based encryption algorithms exist:

- **Symmetric-key algorithms**: these algorithms use the same key to encrypt and decrypt data. The [Advanced Encryption Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) (AES) algorithm is an example of this family's algorithms.
- **Asymmetric-key algorithms**: these algorithms use different keys to encrypt and decrypt data. The two keys are bound by a complex mathematical relationship. [RSA](https://en.wikipedia.org/wiki/RSA_(cryptosystem%29) is an example of an algorithm in this family. Check out [this blog post for a gentle introduction to asymmetric-key algorithms](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/).

Like pure encoding, encryption is a **reversible process** as well, although just for authorized people. Authorized people are the ones in possession of a decryption key.

The challenge of authorized versus unauthorized people is to make data decryption without the key as hard as possible. This leads to applying a mix of cautions such as complex mathematical relationships between the keys, keeping them secret, changing them frequently, and so on.

<include src="BigQuote" quoteText="Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." quoteAuthor="Bruce Schneier" />

## What Is Hashing?

Let's take a look at hashing now. Basically, it's **a technique to generate a unique fixed-length string (hash) strictly depending on the specific input data**.

Since the generated hash depends on the specific input data, any small change to the input data generates a different hash. So, having the hash of a given piece of data, you can verify if that data has been altered by calculating its hash and comparing it with the one you already have. In other words, hashing **ensures data integrity**.

Suppose you like [Lex Luthor](https://en.wikipedia.org/wiki/Lex_Luthor)'s sarcastic line, *That's Kryptonite, Superman. Little souvenir from the old home town*. You like it so much that you want it to always be quoted in exactly this way. No character changed.

You calculate its hash string as follows:

```
7633bbb5bd637575809f0ccbc7db45240255d9637eac38b69d60f0d3d5c4a465
```

> By the way, I used [SHA-256](https://en.wikipedia.org/wiki/SHA-2) as the algorithm to calculate that hash string. But don't mind about this. I'll spend a few words on algorithms in a moment.

Assume someone writes that quote slightly different, such as, *That's kryptonite, Superman. Little souvenir from the old home town*. The following is the hash of this second version:

```
75ae6980bdb589ad7b555548159837a447ece0fc21348a53afc1ecdf62687153
```

You can see that the two hashes are different just by looking at the first characters. This tells you that the two sentences are not written the same way. Did you notice the difference between the two sentences? The second version has a lower-case k instead of the capital K in *kryptonite*.

You may say: why do you compare the two hash strings when you could compare the two sentences? Good point! Imagine that you have a document of thousands of words or a high-quality picture instead of a sentence. In that case, comparing the hash strings is more effective than comparing the whole media.

So, how can you get a hash? A hashing algorithm must have the following features:

1. The resulting hash has a fixed length.
2. The same input always produces the same output.
3. Multiple different inputs *should not* produce the same output.
4. It must not be possible to obtain the input from the output data.
5. Any change to the input data implies a different resulting hash.

As you can see, point 4 implies that hashing is **not a reversible process**, unlike encoding and encryption. Also, point 3 seems to say that, while you should get different hashes for distinct input data, it can't be guaranteed. Actually, this point makes the difference between hashing algorithms. For example, [MD5](https://en.wikipedia.org/wiki/MD5) has been a very common hashing algorithm in the past, but [in 2008 it was deprecated](https://www.kb.cert.org/vuls/id/836068) due to [collision detection](https://en.wikipedia.org/wiki/Collision_resistance). The same happened to some early algorithms of the [Secure Hashing Algorithms (SHA) family](https://en.wikipedia.org/wiki/Secure_Hash_Algorithms). 

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

## The Right Tool for the Right Goal

As you've seen, encoding, hashing, and encryption have their specific purposes and features. Confusing their capabilities and roles in your system may lead to disastrous consequences.

For example, you may think that encrypting passwords is the best security option. Actually, it's a very bad idea. That's what [the Adobe engineers learned in a data breach in 2013](https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/). The attackers who got access to their user database could break the encryption algorithm. Remember that encryption is a reversible process. Even if they don't have the decryption key, they may have enough time to guess it. Adobe reset users' passwords as a countermeasure, but you know users use the same password for multiple services. So, even if access to Adobe services may be safe, access to other websites was potentially compromised.

They should have used hashing instead of encryption to store users passwords securely. You know that hashing is not a reversible process. Attackers can't determine the password from which the hash was generated. But also, simply relying on hashing is not the best option, as [the LinkedIn breach](https://www.computerworld.com/article/2504078/hackers-crack-more-than-60--of-breached-linkedin-passwords.html) teaches us.

I know, it's a hard world! 🙄

If you want, you can learn more about [storing passwords using hashing](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) and [how to use salt to store them properly](https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/). Also, for a more [technical comparison of encoding, encryption, and hashing, read this article](https://auth0.com/blog/how-secure-are-encryption-hashing-encoding-and-obfuscation/).

## Summary

Now you know the difference between encoding, encryption, and hashing. To briefly recap what you learned throughout this article, take a look at the following cheat sheet:

![Encoding, encryption, and hashing comparison](https://images.ctfassets.net/23aumh6u8s0i/32RHwyEORRBB8sbu5EZgdz/e706f821fe5e309fc410d7a56acee7d3/encoding-encryption-hasing-cheat-sheet.png)


Encoding, Encryption, and Hashing

john-brennan

John is an R&D Content Engineer at Auth0. He has nearly a decade’s experience in full-stack software development in a variety of environments, languages, and frameworks. He relishes the challenge of learning hard-to-grasp technical concepts and helping others understand them in a clear, concise manner. His current technical interests are in API design and scalability, Ruby on Rails, accessibility, single-page app architecture, and the ever-changing JavaScript ecosystem. When he's not working, John is usually cooking, doing creative writing, running, or wrangling a toddler.

R&D Content Engineer

John Brennan

How to use HashiCorp Terraform and the Auth0 Provider to maintain your critical infrastructure, including your Auth0 configuration, in code.

Use HashiCorp Terraform to Manage Your Auth0 Configuration

The bcrypt hashing function allows us to build a password security platform that scales with computation power and always hashes every password with a salt.

Hashing in Action: Understanding bcrypt

shafiq-shivji

Shafiq leads Product Marketing for Auth0's Ecosystem and Extensibility domains. He brings vast experience from previous roles as a Product Manager and Sales Engineer working in adjacent SaaS industries like machine learning, web/mobile apps, and communications. He especially enjoys the creative process of conceiving and taking high-impact products to market.

Product Marketing Manager

Shafiq Shivji

Learn how Alex Kalyvitis created Auth0 as Code for Terraform


Infrastructure-as-code is a powerful tool to help alleviate the pain of maintaining cloud architecture. DevOps engineers simply have to code a configuration file, feed it into a solution like HashiCorp Terraform, and viola! Changes occur to the appropriate cloud resources. Auth0's Terraform integration came from our developer community, written by Alex Kalyvitis, a software engineer. We sat down with Alex to talk about his experience and what he learned from it.

What Developers and DevOps engineers will learn from this interview:

* Why infrastructure-as-code for authentication
* What it takes to create a successful open-source project

<br>
Shafiq: **How did you first learn about Auth0?**

**Alex**: Like every engineer, you have to deal with the 300-pound authentication gorilla at a certain point. It's not core to your business, but you must get it right or end up with an insecure app. The consensus in the developer world is to let people who it is their core business do that. In my previous experience at Yieldr, we started with basic authentication to ensure only certain people had access. However, we realized early on that we needed more, and it became clear that we had to implement best practices, such as OAuth2 and Open ID connect, and not try to invent our own.

Luckily, some of the best authentication resources come from Auth0. I learned quite a bit from Auth0's documentation and thought that maybe I should use it instead of building one. I gave Auth0 a try, and after exploring features such as social providers, I realized that it was a robust product. I've been happily using it since.

Shafiq: **Why did you write the Auth0 Terraform Provider?**

**Alex**: Creating the Terraform provider started from an internal organizational philosophy of having all of our cloud infrastructures checked in as code. Doing this gives you the ability to manage all the things that support your infrastructures, such as Amazon AWS, Cloudflare, New Relic, Pagerduty, or other infrastructure or service providers. You can treat it with the same level of scrutiny as your product code. So if I make a change to my infrastructure, it's not by signing into a console and toggling the switch off or on. It makes moves more deliberate and safe. 

![terraform-graphic](https://images.ctfassets.net/23aumh6u8s0i/19lCmccl6pWJ2XL2WX0BO6/46384c1eea33b7692e314b9b6ade2588/terraform-graphic)

As an example, once one of our engineers, while developing a new feature, he had toggled a flag in our Auth0 tenant. This broke our login flow. But we didn't immediately make the connection and instead wasted our time looking for a bug in our codebase. It took us about a day to figure out what happened. So at that point, we said, "All right, this has to be managed with code." Unfortunately, there was no Terraform provider for Auth0 at the time. So we decided to build one. I started by looking through the client libraries offered by Auth0, and unfortunately, a Go SDK was not available, so I had to make one as well to support the provider. Fast forward a couple of years, people are using it to provide their authentication infrastructure, with lots of contributions from the community.

Shafiq: **Did you encounter any challenges, and how did you manage them?**

**Alex**: Challenges. Yeah, I mean, there's always a challenge with any project with significant size or complexity. Building the plan, I started by drawing a line in the sand, so to speak, with whatever is supported by Auth0 and whatever is publicly-documented by Auth0. I used Auth0's management documentation, the API documentation, and that was my golden standard. If it wasn't there, it wasn't in the provider. So that's where I based off a lot of the original work.

Later on, of course, people started using it for things that were not necessarily detailed in the API documentation. So with some reverse engineering and by checking out what changes occurred in the dashboard, we managed to add additional functionality. That was challenging in a sense, but it wasn't rocket science, slightly a bit of guesswork. We built an API that, you know, approximates how it should behave.

Also, time, time is critical. I had to balance how much time I could allocate for this project. I had a demanding schedule at work, as we were building a complex product. Therefore building and maintaining the project was done during weekends and afternoons. Balancing that with home-life was a bit of a challenge. I suspect that some users may get frustrated by that, but there's only so much a single person can do, and I've done the best that I could.

Shafiq: **What was your reaction when demand increased for the provider?**

**Alex**: I was thrilled and delighted to see people finding it useful. I had built something people cared about. It's cool. Even though it's not on the level of developing the next Kafka or precious open-source technology, it's building on the shoulders of that. It's super exciting to see people care about your work and finding it so useful that they want to contribute to it. And some people are passionate about it that they feel that it's even their own even though I haven't yet met them in-person.

<p>
<img src="https://images.ctfassets.net/23aumh6u8s0i/uf8X8pIDwiPy3zXcLo2ON/8dffdab99a5612ceb4719a39b1edfe2b/terraform-github" alt="terraform-github" width="410" height="200"/>
</p>

Shafiq: **What did you learn from the experience?**

**Alex**: You always have to be a good host to everybody. It can be easy to get frustrated by a comment or a request that might seem irrational or too far-reaching. But it's important to be level-headed and treat everybody with respect and point them in the right direction. If I think they're wrong, I try to be helpful because, in the end, what you do people see, and they act in kind. So, if you want people to act respectfully, then you'll have to be respectful and earn respect for yourself. And I see that quality in a lot of people, especially around isolated incidents. So, yeah, be a role model in the community that you want to support.

Shafiq: **Why did you decide to make it open-source and not keep it proprietary?**

**Alex**: Well, for starters, it's not something core to our business, as we're focused on building our product. Open-source is a great way to give back to a community as well as enlist the community to contribute. These are two sides of the same coin. So, on the one hand, you put a lot of effort and give something out for free, but you get more eyes and more scrutiny. This is a good thing, especially when you're dealing with something as sensitive as infrastructure. Crowdsourcing via open-source helps to surface issues we would not have foreseen or would not have the time to deal with.

Shafiq: **What would you say to somebody who is considering writing open-source code?**

**Alex**: Do it. Absolutely do it! The process will teach you a bunch of stuff because people, often smarter than you, may find what you do use and be inclined to share their knowledge with you. So in a way, this is a way to learn. For us, engineers, open-source is hugely valuable as we get to read and understand the world's best codebases written by some of the most brilliant people. That's a huge learning opportunity. I don't know why a developer would do something close-sourced unless it's critical to their business. Unless it's a core piece of software that is intellectual property and you wouldn't want your competitors to see, I don't know why not do open-source.

A special thank you to Alex for allowing us to interview him and for the incredible work he's done with Auth0's Terraform Provider. We highly value and appreciate the contribution our developer community continues to make and for the partnership cultivated over the years.

<include src="asides/AboutAuth0" />


Community Developer Brings HashiCorp Terraform to Auth0

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

Terraform users can now configure and manage Auth0 with code



**BELLEVUE, Wash. — June 17, 2020 —** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced its partnership with [HashiCorp](https://www.hashicorp.com/), the leader in multi-cloud infrastructure automation software, and integration with HashiCorp Terraform, a tool for centrally deploying and managing cloud infrastructure, safely and efficiently, with code. 

HashiCorp Terraform works with vetted and approved infrastructure and service providers to alleviate the pain of maintaining a large number of cloud assets with a single interface. Now available is the [Auth0 Provider for HashiCorp Terraform](https://www.terraform.io/docs/providers/auth0/index.html), enabling Terraform users to set and update common identity configurations for any applications and APIs using Auth0. 

Thousands of Auth0 customers use infrastructure as code solutions to maintain their cloud architecture at scale, including managing their Auth0 environments. This reduces the risk of making manual mistakes while increasing speed and consistency. The Auth0 Provider allows developers to manage clients, resource servers, rules and rule variables, users, roles, tenants, and custom domains as part of a Terraform deployment.

“Auth0 and HashiCorp customers are rapidly adopting cloud services and delivering innovative customer experiences with speed and reliability,” said Bill Lapcevic, VP of Business Development at Auth0. “Auth0 has been working closely with HashiCorp to offer a reliable and fully supported integration of Terraform with our platform.”

Since the company’s inception, Auth0 has relied upon its loyal and widespread developer community. The Auth0 Provider for Terraform, came from one of Auth0’s Community members, Alex Kalyvitis, who played an invaluable role in facilitating this integration. Solving a need within his company, Kalyvitis created an SDK to connect Auth0’s management API with HashiCorp and wrote the Auth0 Provider for Terraform to complete the integration. Auth0 then worked with HashiCorp to get the Provider listing on Terraform.

The Auth0 Provider for Terraform is now fully supported by Auth0. Please see the [_Use Terraform to Manage Your Auth0 Configuration_](https://auth0.com/blog/use-terraform-to-manage-your-auth0-configuration/) technical blog post to learn how to get started. Auth0 and HashiCorp will also be co-hosting a [webinar on June 30, 2020, at 10 am PT](https://auth0.com/resources/upcoming-webinars/auth0-as-code-with-terraform-webinar?utm_source=auth0blog&utm_medium=announcement&utm_campaign=terraform_webinar), where a technology demo and best practices will be shared.

<include src="asides/AboutAuth0" />

### Media Contacts
Jeana Tahnk<br>
Auth0 Global Communications<br>
[press@auth0.com](mailto:press@auth0.com)


Auth0 Announces Technology Partnership with HashiCorp

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

eva-sarafianou

Eva is a Product Security Engineer with a special interest in Cryptography that loves building, securing, and breaking software. At Auth0, Eva works on making our identity platform secure and trusted. She spends her spare time playing the piano, taking dance lessons, and doing outdoors activities.

Product Security Engineer

Eva Sarafianou

marius-mogyorosi

As an Application Security Engineer at Auth0, Marius champions security throughout the software development process with practices ranging from threat modeling to operational application security. Off-hours, he enjoys barbecuing and learning about most things.

Application Security Engineer

Marius Mogyorosi

Cryptography has three key properties: confidentiality, integrity, and authenticity. Let’s learn which of these apply to encryption, hashing, encoding, and obfuscation.

How Secure Are Encryption, Hashing, Encoding and Obfuscation?

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

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

Former Auth0 Employee

Ado Kukic

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



---

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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


"hash"