Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

Step 1, the basics

We start at the beginning. The very first step is the password, the most common authentication method.

What makes a good password, how to best manage the multitude of passwords.

All about a good password

For developers, this article explains how to manage password authentication on your system. Note, the recommendations in this article are valid for the first quarter of 2019. If you read this article in 2038 (well hello to transdimensionals already, or “−··· −−− −· ·−−− −−− ··− ·−· ·−−·− ·−·· ·−−−−· ·· −· − · −· − ·· −−− −· −·· · ·−·· ·− −−· ·−· −−− ··· ··· · ···− −−− ·· −··−  " in your language), the recommendations will probably (surely) be outdated.

Passphrase implementations

Step 2, strengthening

Once the password is set (so no more “1234567890”), we move to the second step (which is aptly named).

Two-factor authentication is based on the principle “Something you know, something you have.”

All about two-factor authentication

Step 3, distributing authentication

Once authenticated on one system, why do it again on others? It is error-prone and not very pleasant.

There is a solution that allows you to securely distribute your authentication. With this solution, you authenticate to one service and other services, systems, websites you use can recognize your identity and authenticate you on demand without repeating the first two steps.

Social logins, how do they work?

Step 4, access control

Once authenticated, you do not have access to all the resources provided by services either. There are rules to select what you can access and what is denied. Users of a service are organized according to groups or roles. What on social networks is called tribe, clan, horde, community, committee, section, commission, (·−−· −−− ·−·· −·−− ·−−· ···· −−− −· ·· · ··· for the transdimensionals)…

What is a community? Groups and roles

There you go. Of course, this is a base. There are many variants and special cases.

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

The service implements access control. Most commonly, it uses group-based or role-based access control. For a social network, there is also relationship-based access control.

Group-Based Access Control

This is the tribe.

This type of access control is a grouping of users who have access to a certain set of resources.

This grouping defines permissions (rights) for using these resources. Each user in this group inherits those permissions.

Role-Based Access Control

This is the tribal chief or shaman…

This type of access control defines a set of permissions (rights) that are collectively assigned to a specific user.

Typically, there’s an Administrator role that has all permissions. Other roles are granted to users by this Administrator. A user cannot assign a role to themselves.

Roles can also be hierarchical. A higher-level role includes all permissions of a lower-level role plus additional ones.

Difference and Relationship Between the Two

When comparing these two types of access control, it can be tricky to distinguish them. Depending on the system, the distinction may not even be explicitly made.

To clarify, here is the distinction:

• Groups are generally used to classify resources and users. They manage identity. For example: a user belongs to one or more groups.
• Roles are generally used to manage permissions and rights. They manage activity. For example: a user can perform a certain action because they have a specific role.

Groups and roles are linked because they complement each other: A group defines the scope of a role. That is, the users and resources on which the role can act. But a role can exist across multiple groups.

Example: Facebook

You might be a member of the “Raspberry Fans Group” and like the “Blackberry Fans Page.” From an access control perspective, you belong to two groups.

Within the “Raspberry Fans Group” you’re a member, and within the “Blackberry Fans Page” you’re a moderator. These are your roles.

As you can see, your roles are bounded by groups. You are a moderator of the “Blackberry Fans Page” only, not elsewhere. But there might be a moderator of the “Raspberry Fans Group” who has the same permissions there as you have on the page. Thus, a role can be present in multiple groups.

Also, group membership provides default permissions. As a regular member of the “Raspberry Fans Group”, you have access to that group’s posts. You wouldn’t have this access if you weren’t a member.

Example: A Computer

The distinction between group and role is subtle (especially on UNIX). But you can think of the computer itself as the group, and the user accounts on that computer have roles (usually one is the administrator—a role that exists on all computers).

Relationship-Based Access Control

This refers to your friends or contacts on social networks.

The existence of a relationship between you and a friend grants permissions to both of you over each other’s resources.

The relationship manages permissions. These can be symmetric (the friend has the same rights as you) or asymmetric (the friend has fewer permissions—this is closer to a “fan” or hierarchical relationship).

Capability-Based Access Control

This type of access control allows for fine-grained permission management.

Permissions are attached to a specific resource (object) rather than a group of resources (as in group- or role-based control). The object-permission pair forms a capability.

If a user possesses the corresponding capability, they can access that object with the defined permissions.

This allows for much more precise permission management since it’s handled resource by resource.

This control type is used by OAuth2 (the mechanism used for social login) to manage permissions. For example, when you use Facebook social login on a website, Facebook tells you that the site wants to access your email, your friends list, or other data.

This is the capability you delegate (fully or partially) to the site over the Facebook resource (which in this case is your profile).

The underlying protocol that everything relies on is OAuth2. So, let’s start there.

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

OAuth2

If there’s a “2”, that means it’s the second version.

The first version, OAuth, had multiple security vulnerabilities. Never use it.

OAuth2 is the protocol that manages authorization. It allows a device to access resources—data stored on a server.

To do this, it uses scopes. These are parameters that request access to specific resources.

For example, the scope “profile” requests access to the user’s profile information.

The server returns a claim, which represents the requested data.

For the “profile” scope, the claim would be:

{
  "name": "Alice the rabbit",
  "firstname": "Alice",
  "lastname": "the rabbit"
}

This protocol can handle different methods of granting authorization, but for social login, only one concerns us.

Authorization Code Grant

This authentication method allows a service to authorize a user’s login without requiring their password, by trusting an authorization server.

Here’s how it works:

• The user wants to log in to a service
• The service redirects the user to the authorization server’s login page
• The user logs into the authorization server if not already logged in (they enter their password at this step on the authorization server)
• The authorization server displays a confirmation panel asking the user if they really want to connect to the service
• The user confirms
• The server then redirects the user back to the service with an authorization code
• The service uses the received authorization code to request an access token from the authorization server
• The authorization server approves the connection between the service and the user
• The user is logged in to the service

As you can see, the user never enters their password on the service. Password storage happens only on the authorization server.

OpenID Connect

This extension of OAuth2 is managed by the OpenID Foundation, which also maintains the original OpenID with its own mechanism.

This extension handles authentication (identity). It leverages the authorization server as an authentication server.

Building on the “Authorization Code Grant” flow, it verifies the user’s identity with the server using information returned by it (a unique identifier, usually an email, though ideally a UUID).

Additionally, this extension offers several options:

• The UserInfo endpoint provided by the authentication server: allows dynamic retrieval of user profile information
• The Session endpoint provided by the authentication server: enables session verification to synchronize sessions (e.g., making sure the user’s session on the service ends when they log out of the server)
• A logout flow that logs the user out of all services when they log out of the authentication server
• An implicit login flow called “Single Sign-On” which allows users to log into a service seamlessly. The service and the server appear unified as a single application.

Advantages

This system links multiple services without requiring a password for each one, enhancing security.

It also enables data synchronization between services with a central information silo (a reference point for data storage). This reduces data conflicts when properly implemented.

Risks

Using this system requires full trust in the authorization provider. The provider can access information within connected services because it can impersonate the user and obtain an authorization code on their behalf.

Identity and data synchronization isn’t always well executed. You might end up with multiple accounts on the same service just because you changed your email on the authorization server. The service relying on email won’t recognize the old account and will create a new one.

Logout is often not implemented. Major social login providers use persistent sessions, and many services don’t implement proper logout checks. As a result, services may remain logged in (the user stays connected) even after logging out of Facebook or Google.

If the authorization server is attacked, compromised, or weakened, all linked services become vulnerable.

Attacks

Clickjacking

A hacker could create a malicious service that loads the authorization server inside a transparent iframe.

To simplify, imagine your authentication server as a smartphone.

You tap the center button on your smartphone screen to accept the service.

With clickjacking, the hacker has placed a transparent sheet over your screen, and when you click the button, you’re actually clicking on the sheet, unknowingly granting the malicious service access to your data.

For developers: Implement the X-Frame-Options header with strict settings (e.g., “SameOrigin”) and/or use JavaScript framebusting techniques.

Cross-Site Request Forgery (CSRF)

A hacker can trick the user into clicking an authorization button that redirects, not to the intended service, but to the hacker’s malicious service. The malicious service captures the authorization code and then redirects the user to the correct service.

The user notices nothing, but the malicious service now has the authorization and access tokens.

For developers: Enforce fixed, pre-registered redirect URLs for services.

There are other CSRF variations; I’ll detail them in a future article.

Confused Deputy Problem

This issue occurs when services do not correctly verify the identity of the user utilizing the authorization server.

A malicious user can log in to the authorization server and trick the service into thinking they are another user by manipulating the information used to identify the user.

If the service doesn’t use a reliable identifier for proper user identification, it gets fooled and grants access to the wrong account.

Example:

A service uses an authorization server that provides both a UUID and a username.

The authorization server has two accounts:

• Alice with UUID: 46d07175-dbf2-46e2-80fc-c6493e481479
• Oscar with UUID: 362b862b-51b3-41f4-82c7-82eb677a9aa4

The authorization server provides UUIDs as unique identifiers, expecting the service to use them.

But instead, the service chooses to use the username as the unique identifier.

Oscar changes his username to “Alice” (allowed by the server since it uses UUID as the true unique ID).

Now, when Oscar logs into the service, he gains access to Alice’s account (because the service mistakenly uses username as the unique identifier).

For developers: Always choose a truly unique identifier. UUIDs are designed for this purpose. They don’t carry user information and allow users to freely change their details (even email) without affecting uniqueness.

The idea behind two-factor authentication is to ensure that the user identifies themselves using two techniques that are very unlikely to be compromised at the same time.

The key phrase to remember is:

“Something you know, something you have.”

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

In practice, this often involves a password (“something you know”) and a physical device (e.g., a message on a smartphone, “something you have”).

Two-factor authentication is just one method within a broader concept: multi-factor authentication.

Multi-Factor Authentication

When you watch a spy movie with a secret base, you sometimes see the hero or villain scan their iris, type a code on a keyboard, place their hand on a pad, and even spit into a sensor before opening the door. That’s multi-factor authentication.

You may encounter or implement an authentication chain, meaning several authentication steps are required, and if one fails, authentication stops.

In some real-world high-security scenarios, more than two steps are used. But most of the time, two steps are enough.

Methods (and Their Pitfalls)

SMS

The most common two-factor authentication method is SMS.

This is the weakest method because it’s easily hackable. With enough resources, a hacker can compromise SS7.

SS7 is the network layer that routes SMS messages. Designed in the 1970s, it’s long outdated and has been exploited in real attacks ( NextImpact article in french).

It’s also inconvenient in areas with no mobile network coverage.

PUSH

Another method used by some services is push authentication. This involves a notification sent to your smartphone asking for your approval. The message is pushed by the service to your device.

This requires an internet connection on your phone, which can be a weakness because hackers can attempt to intercept these notifications.

HOTP/TOTP

The second most common method is HOTP/TOTP (HMAC-based One-Time Password / Time-based One-Time Password).

• HOTP (“One-time password based on HMAC”) generates a unique password using a cryptographic HMAC and a counter.
• The user installs an app on their smartphone that generates a 6-character token on demand. This token is generated using:
  • A seed stored both in the web service account and the app.
  • A counter that increments in sync between the service and the app.

When the user enters the token, the web service compares it with its own calculation. If they match, authentication succeeds. The service knows it’s from the user’s smartphone because only that device holds the seed.

The seed is usually transferred from the service to the user via a QR code.

• TOTP (“Time-based One-time Password”) extends HOTP by using the current time (typically 30-second intervals) instead of a counter. TOTP is much more widely used than HOTP.

We recommend using FreeOTP to generate tokens on smartphones or other devices:

• Android and F-droid
• iOS
• Source Code

These methods do not require internet or SMS connectivity, making them safer. Hackers can’t intercept messages because no messages are sent.

Hardware Devices

The most secure method is to use a dedicated hardware device. During setup, the device is linked to your account on the web service. Thanks to cryptographic recognition (the device contains an asymmetric key), the service recognizes it as “something you have” for authentication.

The downside: you have to carry an extra device—and not lose it!

Some banks also provide hardware tokens tied to your bank card, often using TOTP internally.

Recovery Codes

While not strictly “something you have,” recovery codes are the best backup method if you lose your device or smartphone. It’s a list of single-use tokens you can use instead of your primary factor.

Store this list in a very secure location and only use it as a last resort.

Attacks

These solutions aren’t perfect and can be targeted by attackers.

Social Engineering

In SMS-based two-factor authentication, attackers can use social engineering. For example, DeRay McKesson’s case.

Hackers impersonate the phone owner with the carrier, request a SIM card swap, and once their SIM is activated, they receive all of the victim’s SMS messages.

Proxy Attacks

Attackers can also intercept via proxies, either by:

• Creating a fake mobile network nearby to intercept SMS ( NextImpact article in french), or
• Setting up a phishing site that mimics the real one to capture credentials and tokens. This is known as a homograph attack or typosquatting.

Mitigation: Use hardware authentication or always check the website domain name.

Example: If you intend to visit “douce-framboise.com”, make sure it’s not “douce-framb0ise.com”.

Forgotten Authentication Paths

Sometimes web service maintainers forget that the main login page isn’t the only access point.

Examples:

• Password reset via an email link may bypass two-factor authentication.
• Using external services via APIs (like Google or Facebook OAuth2 login) might also skip two-factor checks.

Always ensure two-factor authentication is enforced for all access paths to your users’ data.

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

The password to rule them all

First of all, how can you create a good password you can remember?

Replacing characters is not good

Often, a bad but seemingly good idea pops up: replacing characters with others.

For example, using “p@ssw0rd” instead of “password”.

This idea comes from the English-speaking world and is based on the fact that most passwords were composed of ASCII characters, meaning the 26 letters of the Latin alphabet plus some punctuation symbols.

This article was originally written in French and was therefore aimed at French speakers who are less affected by this issue because French contains characters not included in the basic ASCII table. Accents, for example: “à, é, è, ù…” are included in the extended ASCII table or even UTF-8 (a table that contains alphabets from all over the world: Arabic, Cyrillic, Chinese…).

This technique makes passwords much harder to remember. Because they’re hard to memorize, we tend to make them shorter, which is also very bad.

Passphrases are good

This technique is known thanks to the xkcd comic strip, often referred to as “correct horse battery staple”.

To be effective, the combination of words must be as rare as possible. In the xkcd comic, this rarity is conveyed by randomness.

But let’s not forget that this is a password we need to remember. Our brains don’t handle randomness well. That’s why, at the end of the comic, the author emphasizes creating a mental image of the passphrase.

Note: In French, word frequency and word combinations are lower than in English because French speakers are fewer and the language contains articles, determiners, and possessives that further reduce combination probability. Thus, randomness is less critical than in English.

We can therefore use grammatically correct phrases as passwords.

An example to illustrate:

Which do you think is the better password:

“!He_r@spberr1es”

or

“The Queen of the Night’s Aria, The Magic Flute by Wolfgang Amadeus Mozart”

If you like Mozart, it’s definitely the second one. It’s easy to remember, longer than the first, and the chance that two people have the same password is low.

The password manager to bring them all

Having a password you can remember is good. But even better is being able to use passwords you cannot remember yourself. This reduces the risk of accidentally revealing them in conversation.

Jimmy Kimmel has a segment on his show available on YouTube.

To avoid this risk and create passwords you can’t remember, you need a password manager.

This is software or a web service that stores your passwords and displays them when requested. You just copy-paste them or use plugins that auto-fill login forms. They’re usually encrypted, and you access them with a master password. The only one you really need to remember.

With this system, since you don’t have to remember passwords, go big. Use 50-character randomly generated passwords with lots of weird symbols. Take advantage of UTF-8, checking compatibility with your software and services (not all support it, and some don’t display Cyrillic correctly, for example).

Software or web service

The advantage of using software instead of a web service is reduced risk of attacks and leaks.

A web-based password manager attracts attackers because a breach could expose thousands of accounts instead of just one.

There are also legal conflicts between the service’s jurisdiction and users’ rights, for example, European GDPR vs. the U.S. Cloud Act. We’ll discuss these legal aspects in future articles.

The advantage of a web service is a lower risk of password loss and a dedicated team monitoring and patching vulnerabilities.

Me

I use KeepassXC.

It’s open-source, meaning the code can be easily audited.

It runs locally on your devices instead of online, reducing centralized attack surfaces.

It encrypts passwords with the master password.

Legal conflicts between European GDPR and the U.S. Cloud Act are avoided since passwords aren’t stored on U.S. servers.

However, it’s harder to share the password database across devices. You also need to manage backups of your encrypted password database yourself.

KeepassXC is a variant of KeepassX (development appears to have stopped), itself a variant of Keepass, which is Windows-only. In fact, Keepass will undergo a security audit by the European Commission.

And in the darkness bind them (attacks)

Mass attacks

Mass attacks aim to collect as many passwords as possible, without caring whose accounts they belong to.

Dictionary attacks

The most common are dictionary attacks. They require little computing power but lots of storage (time-memory tradeoff). They test the most common known passwords (from previous breaches) and move on if they fail.

A yearly list of the 25 most popular passwords is published (here’s the 2018 list, with 2017 comparison):

• 123456 (unchanged)
• password (unchanged)
• 123456789 (+3 spots)
• 12345678 (-1)
• 12345 (unchanged)
• 111111 (new)
• 1234567 (+1)
• sunshine (new)
• qwerty (-5)
• iloveyou (unchanged)
• princess (new)
• admin (-1)
• welcome (-1)
• 666666 (new)
• abc123 (unchanged)
• football (-7)
• 123123 (unchanged)
• monkey (-5)
• 654321 (new)
• !@#$%^&* (new)
• charlie (new)
• aa123456 (new)
• donald (new)
• password1 (new)
• qwerty123 (new)

The issue with this list, present in all “how to make a good password” articles, is that it’s from the English-speaking world and doesn’t reflect the most common passwords in other languages (as french). If you have sources for other languages passwords, I’d love to see them.

Of course, there are also lists with 100, 1,000, 10,000, 1 million, or more passwords circulating online.

Rainbow tables

The second type is the rainbow table attack. It’s more computationally expensive but requires less storage. It only works if the attacker has obtained a database of password hashes (we’ll explain “hash” in a future article).

A rainbow table compares its stored hashes with those in the hacked database. If they match, the password is the same.

Example:

The attacker has a rainbow table with these md5 hashes:

• password: 5f4dcc3b5aa765d61d8327deb882cf99
• sdhfksdkfh: e2a1dbf388e7a7e87dc02943e3521036
• raspberry: 54a9fc48a5b664772e2ca06d1e0772d9

They hack a site’s hash table and get:

• Bob: 098f6bcd4621d373cade4e832627b4f6
• Alice: 54a9fc48a5b664772e2ca06d1e0772d9
• Lee: 190a16e29799b184d9900690ee04438a

The second hash matches the third entry in their rainbow table, so Alice’s password is “raspberry”.

Passphrases counter both these attacks. If the passphrase isn’t in the dictionary or rainbow table, the attack fails.

In a future article, we’ll discuss strengthening hash tables for website developers.

In the hash article, we’ll also see how to reduce rainbow table storage needs.

Brute force (grrrr)

The last technique is brute force: trying every possible combination. It’s the most computationally expensive but requires the least storage.

It’s the oldest method and why we started adding special characters to passwords.

But attackers have long used extended ASCII (with uppercase and accents) or UTF-8 (all alphabets worldwide: Arabic, Cyrillic, Chinese…) to test everything.

To counter it, use longer passphrases and the full alphabet (not “aaaaaaaaaaaaaaaaaaaaaa”).

This increases entropy (we’ll explain entropy in another article). French, with its accented letters, provides even higher entropy than English.

Example:

“!Es_fr@mbo1ses” has 72.1 bits of entropy, which is strong (good for most cases).

“The Queen of the Night’s Aria, The Magic Flute by Wolfgang Amadeus Mozart” has 475.8 bits of entropy, making it ultra-strong (obviously good).

The higher the entropy, the longer brute-force takes. The goal is to make attacks take years or centuries, not seconds. And with a password manager, take full advantage of UTF-8 (checking compatibility).

Targeted attack

A targeted attack aims to hack a specific user.

Keylogger

This involves infecting the user’s device with a tool that records every keystroke. When the user types their password, it’s captured.

This is outside this article’s scope and will be covered in future articles.

Social engineering

Through social engineering, a hacker may obtain your password from friends, family, or even you. Remember Jimmy Kimmel.

First, never share your password with anyone. Many services (including email) allow account sharing without sharing passwords.

Second, a password manager helps here too. If you don’t know your own password, a hacker can’t extract it this way.

For your master password, try a unique word combination or phrase no one knows.

Tools to find them

Yes, for those catching the title reference, I had to swap titles for coherence.

Once you have passwords for online services or devices, you must monitor them and track their lifecycle.

Make sure deleted passwords are truly deleted.

Expiration

You can set an expiration date for passwords. I don’t recommend this unless you’re sure because it often clashes with human behavior.

People quickly create slightly modified versions of old passwords or stop changing them altogether. Since password expiration handling isn’t standardized, this can create security flaws.

Breach monitoring

You should also ensure your password hasn’t been breached. Use monitoring tools for this.

A great service is haveibeenpwned by Troy Hunt. You can monitor your emails, and if they appear in a breach, the service notifies you.

It even provides tools to integrate into your website or app. However, I have serious GDPR concerns about it (to be discussed later).

Lastly, here’s a Twitter account showing how hard it is for services to handle passwords correctly:

https://twitter.com/PWTooStrong

Well, I’ve promised a lot of future articles. Great, more work for me. Pfff…

For developers, here are some tips on implementing passwords.

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

Password Rules

If you’re tempted to set password rules like “between 8 and 20 characters” or “3 uppercase letters,” stop right there.

This approach is outdated, overly rigid for users, and leads them to create passwords that are hard for them to remember but very easy for bots to crack.

Don’t believe me? Check out the Twitter account passwordistoostrong.

Example:

Imagine the rule:

“Between 8 and 20 characters, at least 3 uppercase letters, and a punctuation mark.”

This password would qualify: “AbCdEfgh!” even though it’s not actually strong.

Meanwhile, the user is left frustrated.

Entropy

Instead, use an entropy-based system.

The zxcvbn library (named after the bottom row of keys on a U.S. keyboard) is a great implementation for calculating password strength based on entropy. It’s available in a wide variety of programming languages.

The advantage is that there are no rigid rules for estimating password strength. The library calculates the complexity of your password (considering the rarity of characters, their patterns, etc.) and assigns it a score. You can then decide from which score threshold you consider the password sufficiently secure.

Of course, you must use the same scoring and thresholds on both the server and client sides. If they differ, the server has the final say since the client side can be tampered with by an attacker (it’s not secure).

Avoid Compromised Passwords

Once you’ve set a threshold to block weak passwords, you still need to check if the entered password hasn’t already been compromised.

This is an optional additional safeguard because if your complexity threshold is high enough, the way the password is stored can already effectively defend against rainbow table attacks. Still, it’s a valuable bonus.

To do this, you can either load a JavaScript file on the client side or make an AJAX request to an API when the user creates their password.

If your AJAX request sends the plaintext password, that’s a problem. It increases your attack surface.

Loading a JavaScript file can be heavy, so it’s better to load it asynchronously. However, even asynchronously, the file size (and therefore the number of compromised passwords it can check) is limited.

Naturally, since the client side is not secure, you must repeat the verification on the server side.

Another technique is to use the Have I Been Pwned service. It offers a technically elegant solution but, as it’s an Australian service using U.S.-based infrastructure, it raises serious concerns about GDPR compliance in Europe (we’ll cover this in a future article).

This service works using k-anonymity.

You hash the user’s password and send only the first k characters of the hash to the service. The service returns all hashes in its database that share those k starting characters. You then compare them to the user’s password hash; if any matches, the password has been compromised.

Example:

The password “framboise” has this SHA256 hash:

“F9E4141EE43A3B877758E2584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C”

The first 5 characters are “F9E41.”

You send those 5 characters to Have I Been Pwned.

It returns:

• “F9E4141EE43A3B8777ERT8584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C”
• “F9E4141EE962758777ERT8584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C”
• “F9E4141EE43A3B877758E2584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C”

You compare and see that the third hash matches the user’s hash. Therefore, the password is compromised.

With this system, no password is ever transmitted over the network, and Have I Been Pwned never knows which password you’re testing. In the example, three results were returned, but the smaller the k value, the more results you get.

Then Store Passwords Properly

After the user has chosen a good password and securely submitted it, you must store it properly.

A fundamental rule: never store passwords in plain text. If an attacker gains access to your password storage, you’ve handed them access to every account on your service, and possibly other services (users unfortunately often reuse passwords).

So, what should you do?

1. First, limit password length, but not too much. Drupal, for example, limits password length to 512 bytes, meaning between 128 and 512 UTF-8 characters. This step is necessary to prevent a DoS attack because hashing consumes resources (an attacker could input an extremely long password to exhaust system resources during hashing).

2. Generate a random salt. A specific length string.

   

   You can generate a salt per database (for all passwords) or per password. It’s added to the password to ensure identical passwords have different hashes. Salts prevent hash comparisons, table-wide or row-wide, even if users choose the same password or reuse it across services.

   Example:

   Table-level salt:

   Alice uses “framboise” on both “nice-raspberries-squashed.com” and “mean-raspberries-squashed.com”.

   “nice-raspberries-squashed.com” generates salt “458,” making Alice’s password “458framboise.”

   “mean-raspberries-squashed.com” generates salt “gdf,” making Alice’s password “gdfframboise.”

   If a hacker accesses both tables, the hashes won’t match (since the salted passwords differ), so they won’t know Alice reused the same password.

   Row-level salt:

   Alice and Bob both use “framboise” on “nice-raspberries-squashed.com.”

   The site generates salt “458” for Alice’s password → “458framboise.”

   It generates salt “sdd” for Bob’s password → “sddframboise.”

   If an attacker accesses the table, they won’t know Alice and Bob used the same password because their hashes are different.

3. Hash the combined salt + password using a secure algorithm like SHA512.

   For password “framboise” with salt “458”:

   hash(sha256, ‘458framboise’) = ‘527D88733ED03CE5EF2D12AE4279950ABC29DC42817B14A58AB2150678A7CC72486CE637B8AD10333E80879F3D0CE685FA6CBB5DB8D7954382C2116616F8F6CF’

4. You now have a reasonably secure stored password. Also store the salt. To strengthen the hash further, you can iterate hashing with the previous hash and the password:

   hash(sha256, ‘527D88733ED03CE5EF2D12AE4279950ABC29DC42817B14A58AB2150678A7CC72486CE637B8AD10333E80879F3D0CE685FA6CBB5DB8D7954382C2116616F8F6CF framboise’) = ‘E3A252D3C455D638C82D8430DDC85E9B5B13F6508D690D97E2C5A1CC8AEE4A26D4C723E4EE4F524B4926C0357B2651132DF67446721BB4D3BCDD017C4A0E0E1B’

   The goal is to make the resulting hash different from any known hashes attackers might have, making password recovery harder.

   When a user tries to log in again, your system repeats the process (using the stored salt) and compares the new hash to the stored one. If they match, the password is correct.

Common Mistakes to Avoid

Sometimes we make silly mistakes! Here are some to avoid:

• When changing the complexity threshold for accepted passwords, don’t apply it to old password fields. Otherwise, users won’t be able to enter their old password to change it. Only apply the threshold to new password fields.

• If you change your password storage method or complexity rules and need user action, notify them by email. Don’t send password reset links with long expiration—users may click them months later, giving attackers time to exploit them.

• Never send a user’s password via email. Emails are like postcards: anyone can read them. And if you can email a password, it means you’re not storing it securely.

• Provide meaningful error messages when users create passwords. Use labels like “weak,” “strong,” or “very strong,” not entropy scores users won’t understand.

• Ensure passwords are transmitted via HTTPS. Ban HTTP completely.

• For extra security, implement authentication chains, meaning two-factor authentication (e.g., with a smartphone token) in addition to a password.