htpasswd Generator

An htpasswd generator is a cryptographic utility used to create and manage the flat-file databases that store usernames and hashed passwords for HTTP Basic Authentication. By transforming plaintext credentials into secure, salted hashes, this mechanism allows web servers like Apache and Nginx to restrict access to specific directories, websites, or applications without requiring a complex relational database. Understanding how these generators process, salt, and hash passwords is fundamentally essential for any system administrator or web developer tasked with securing staging environments, internal tools, and private web assets.

What It Is and Why It Matters

At its core, an htpasswd generator is a tool that facilitates HTTP Basic Authentication, one of the oldest and most fundamental access control mechanisms built directly into the HTTP protocol. When a web server is configured to protect a specific directory or application, it needs a reliable, localized way to verify the identities of users attempting to access that resource. Instead of querying a heavy relational database like MySQL or PostgreSQL, the web server reads a simple, structured text file—traditionally named .htpasswd—which contains a list of authorized usernames paired with their cryptographically hashed passwords. The generator is the mathematical engine that takes a user's chosen plaintext password, applies a specific cryptographic algorithm to obscure it, and outputs the exact string format required by the web server. This process ensures that even if a malicious actor gains unauthorized read access to the server's file system, they cannot immediately discern the actual passwords used by the administrators or clients.

The continued relevance of htpasswd and HTTP Basic Authentication in the modern web ecosystem cannot be overstated. While consumer-facing applications rely on complex, token-based authentication systems like OAuth 2.0 or JSON Web Tokens (JWT), developers and system administrators constantly require lightweight, database-free security layers. When deploying a staging version of a website that must be hidden from search engine crawlers and the general public, setting up a full authentication portal is an inefficient use of development time. Similarly, internal monitoring dashboards, server administration panels like phpMyAdmin, and continuous integration pipelines often require a quick, impenetrable wall of security that operates entirely at the server level. The htpasswd system solves this problem elegantly: it requires zero application-level code, operates instantaneously within the web server's core processes, and provides an immediate 401 Unauthorized barrier that stops unauthorized traffic before it ever reaches the application layer.

History and Origin

The origins of the htpasswd utility trace back to the very foundation of the World Wide Web and the earliest attempts to secure networked information. In 1993, Rob McCool, a software developer at the National Center for Supercomputing Applications (NCSA), authored the NCSA HTTPd web server. As the web rapidly evolved from a medium for public document sharing into a platform capable of hosting private, sensitive data, McCool and his peers recognized the urgent need for an access control mechanism. They implemented HTTP Basic Authentication, a standard that was later formalized by the Internet Engineering Task Force (IETF) in RFC 1945. To manage the credentials for this new authentication scheme, NCSA HTTPd included a command-line utility named htpasswd. This original implementation relied on the standard Unix crypt() function, which utilized a modified Data Encryption Standard (DES) algorithm to hash passwords.

When the Apache HTTP Server project was launched in 1995 by Brian Behlendorf and a group of developers who were patching the NCSA codebase (hence the name "A-patchy" server), they inherited the htpasswd utility. However, the limitations of the original Unix crypt() function quickly became apparent. It truncated all passwords to a maximum of eight characters, meaning a password of "administrator" was functionally identical to "administ". Furthermore, DES was becoming increasingly vulnerable to brute-force attacks as computing power increased. In response, the Apache developers introduced a modified version of the MD5 hashing algorithm, specifically tailored for htpasswd, known as APR1 (Apache Portable Runtime 1). This allowed for passwords of unlimited length and introduced a 1,000-iteration loop to slow down attackers. As the decades progressed and graphics processing units (GPUs) made cracking MD5 trivial, the htpasswd ecosystem evolved once again to support bcrypt, a Blowfish-based algorithm designed by Niels Provos and David Mazières in 1999, which remains the gold standard for password hashing today.

Key Concepts and Terminology

To truly master htpasswd generation and HTTP Basic Authentication, one must possess a rigorous understanding of the underlying cryptographic and networking terminology. Plaintext refers to the unencrypted, readable password exactly as the user types it into their browser prompt. Hashing is the process of passing this plaintext through a one-way mathematical function that converts it into a fixed-length string of seemingly random characters. Unlike encryption, which is designed to be reversed (decrypted) with a key, a proper cryptographic hash cannot be reversed; the only way to discover the original plaintext is by guessing passwords, hashing them, and comparing the outputs. Salting is a critical security enhancement added to the hashing process. A salt is a randomly generated string of characters appended to the plaintext password before it is hashed. This ensures that if two users have the exact same password (e.g., "P@ssw0rd123"), their resulting hashes will look completely different, neutralizing the threat of pre-computed rainbow table attacks.

In the context of the web server, the .htpasswd file is the actual flat-file database storing these credentials. Each line in the file corresponds to one user, formatted simply as username:hashed_password. The .htaccess file is an Apache-specific configuration file placed within a web directory that issues the directives telling the server to protect that directory and pointing it to the location of the .htpasswd file. During the authentication process, you will encounter the term Base64 Encoding. When a user types their username and password into the browser, the browser combines them with a colon (e.g., admin:secret99) and encodes the entire string using Base64 before sending it to the server in the HTTP Authorization header. It is a massive, dangerous misconception that Base64 is a form of encryption; it is merely a data translation format that can be instantly decoded by anyone who intercepts the traffic. Finally, the Cost Factor (or Work Factor) is a variable used specifically in algorithms like bcrypt that dictates how many times the hashing calculation is performed, allowing administrators to intentionally slow down the hashing process to thwart brute-force attacks.

Types, Variations, and Methods

The security and functionality of an htpasswd file depend entirely on the specific cryptographic algorithm used to generate the hashes. Over the years, four primary algorithms have been supported by web servers, each with distinct mathematical properties, historical contexts, and security profiles. Understanding the differences between them is critical for making informed security decisions.

Bcrypt (Modern Standard)

Bcrypt is currently the only algorithm that security professionals recommend for new htpasswd implementations. Based on the Blowfish cipher, bcrypt was explicitly designed to be computationally expensive and resistant to hardware-accelerated cracking via GPUs. A bcrypt hash in an htpasswd file always begins with the identifier $2y$ or $2a$, followed by a two-digit cost factor (e.g., 10), a 22-character Base64-encoded salt, and finally the 31-character hash itself. For example, a string might look like $2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. The mathematical brilliance of bcrypt lies in its cost factor, which is logarithmic. A cost factor of 10 means the algorithm performs $2^{10}$ (1,024) key expansion iterations. If computing power doubles in the future, an administrator can simply increase the cost factor to 11 ($2^{11}$ or 2,048 iterations), instantly doubling the time it takes to hash a password and effectively future-proofing the system against brute-force attacks.

APR1-MD5 (Legacy Apache Standard)

For over a decade, the Apache-specific implementation of MD5, denoted by the prefix $apr1$, was the default standard for htpasswd generation. Unlike standard MD5, which is a lightning-fast algorithm that produces a simple 32-character hexadecimal string, APR1-MD5 incorporates a salt and utilizes a 1,000-iteration loop. A typical entry looks like $apr1$QAKOONN7$w.r2O3Lw4B3/Z3v.1j3bC0. While this 1,000-iteration loop was computationally heavy in the early 2000s, modern ASIC (Application-Specific Integrated Circuit) miners and high-end consumer GPUs can now calculate billions of MD5 hashes per second. Consequently, APR1-MD5 is no longer considered secure against targeted, offline brute-force attacks, though it remains widely supported for backward compatibility on older legacy systems.

SHA-1 (Insecure)

The SHA-1 (Secure Hash Algorithm 1) implementation in htpasswd is mathematically the weakest and most dangerous option available, aside from storing passwords in plaintext. An htpasswd SHA-1 hash is identified by the prefix {SHA} followed by a Base64-encoded string, such as {SHA}W6ph5Rs5VsEQCRHLkqJfxfs08l8=. The fatal flaw of the htpasswd implementation of SHA-1 is that it does not utilize a cryptographic salt. Because the hashes are unsalted, an attacker who steals the .htpasswd file can simply compare the hashes against pre-computed rainbow tables (massive databases of pre-hashed common passwords) and crack the majority of the file in milliseconds. It should never be used under any circumstances.

Crypt (Historical Unix)

The traditional crypt() method is the oldest format, relying on the operating system's underlying C library. It does not use a prefix, making it recognizable by its raw string output, which is exactly 13 characters long (e.g., xyZ1a2b3c4d5E). The first two characters of the string represent the salt, and the remaining 11 represent the hash. The most critical limitation of traditional crypt() is that it silently truncates all passwords at the 8th character. If a user's password is SuperSecret123, the algorithm throws away everything after SuperSec and only hashes those first eight characters. Combined with the weak 56-bit key space of the underlying DES algorithm, crypt() is entirely obsolete and exists solely to support ancient, unpatched Unix environments from the 1990s.

How It Works — Step by Step

To understand how an htpasswd generator functions in a real-world environment, we must examine both the offline mathematical generation of the credential file and the real-time networking handshake that occurs when a user attempts to log in. Let us walk through a complete, realistic scenario using the bcrypt algorithm. Suppose a system administrator needs to grant a user named "alice" access to a private directory, and Alice has chosen the password "Winter2024!".

Step 1: The Cryptographic Hash Generation The administrator inputs the username "alice" and the password "Winter2024!" into the htpasswd generator, selecting the bcrypt algorithm with a cost factor of 10. First, the generator utilizes a cryptographically secure pseudorandom number generator (CSPRNG) to create a unique 128-bit salt. Let us assume the generated salt, when Base64 encoded, is rO3Lw4B3/Z3v.1j3bC0xyz. Next, the generator feeds the plaintext password ("Winter2024!"), the cost factor (10), and the salt into the bcrypt algorithm. The algorithm undergoes its expensive key setup phase, running $2^{10}$ (1,024) iterations of the Eksblowfish cipher. This process takes roughly 100 milliseconds on a modern CPU. The resulting 192-bit hash is Base64 encoded. The generator then concatenates the algorithm identifier, cost factor, salt, and hash into a single string: $2y$10$rO3Lw4B3/Z3v.1j3bC0xyz.w.r2O3Lw4B3/Z3v.1j3bC0. Finally, it prepends the username and a colon, outputting the final line: alice:$2y$10$rO3Lw4B3/Z3v.1j3bC0xyz.w.r2O3Lw4B3/Z3v.1j3bC0. This line is saved into the .htpasswd file on the server.

Step 2: The HTTP Handshake and Verification When Alice navigates her browser to the protected URL, the web server checks its configuration and realizes the directory requires Basic Authentication. The server immediately halts the request and responds with an HTTP 401 Unauthorized status code. Crucially, it includes an HTTP header that looks like WWW-Authenticate: Basic realm="Restricted Area". Upon receiving this 401 status and header, Alice's web browser natively renders a pop-up dialog box asking for a username and password.

Step 3: Credential Transmission and Validation Alice types "alice" and "Winter2024!" into the browser prompt and clicks submit. The browser concatenates these into the string alice:Winter2024! and encodes the string into Base64, resulting in YWxpY2U6V2ludGVyMjAyNCE=. The browser then resends the original HTTP request, this time including the header Authorization: Basic YWxpY2U6V2ludGVyMjAyNCE=. The web server receives this request, decodes the Base64 string back into alice:Winter2024!, and splits it at the colon. The server opens the .htpasswd file, scans line by line until it finds the username "alice", and extracts the stored bcrypt string. The server reads the $2y$10$ prefix and the salt from the stored string. It then takes Alice's transmitted plaintext password ("Winter2024!"), applies the exact same bcrypt algorithm with the exact same cost factor (10) and the exact same extracted salt. If the resulting hash perfectly matches the hash stored in the file, the server knows Alice provided the correct password. It then serves the requested web page with an HTTP 200 OK status.

Real-World Examples and Applications

The practical application of htpasswd files varies depending on the specific web server software governing the environment. The two most dominant open-source web servers in the world, Apache and Nginx, both rely heavily on htpasswd files for Basic Authentication, but they implement the configuration directives differently. Understanding these exact configurations is vital for successful deployment.

Apache HTTP Server Configuration

In an Apache environment, Basic Authentication is typically enforced using a .htaccess file placed directly inside the directory you wish to protect. Suppose you have a directory located at /var/www/html/staging that you want to hide. You would first generate your password file and save it to a secure location outside the web root, for example, /etc/apache2/.htpasswd. Then, you would create a text file named .htaccess inside the /var/www/html/staging directory containing the following exact directives:

AuthType Basic
AuthName "Restricted Staging Environment"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

The AuthType Basic directive tells Apache which authentication protocol to use. The AuthName directive provides the text that will appear in the user's browser prompt (the "realm"). The AuthUserFile is the absolute file path to the generated htpasswd file. Finally, Require valid-user instructs Apache that any user who successfully authenticates against a record in the htpasswd file is permitted access. If you only wanted to allow the specific user "alice", you would change the final line to Require user alice.

Nginx Server Configuration

Nginx handles configuration centrally rather than relying on distributed .htaccess files. To protect a specific location in Nginx, you must edit the server block configuration file, typically located in /etc/nginx/sites-available/default or a similar path. Suppose you want to protect the /admin route of your website. You would generate your htpasswd file and place it at /etc/nginx/.htpasswd. Inside your Nginx server block, you would add the following location block:

location /admin {
    auth_basic "Administrator Login Required";
    auth_basic_user_file /etc/nginx/.htpasswd;
    try_files $uri $uri/ =404;
}

The auth_basic directive serves a dual purpose: it enables the authentication module and defines the realm string that the browser will display. The auth_basic_user_file points to the absolute path of the generated credentials. Because Nginx loads its configuration into memory upon startup, it is incredibly fast at reading and processing these authentication requests, making it highly suitable for high-traffic environments that require basic security gates.

Common Mistakes and Misconceptions

Despite the conceptual simplicity of HTTP Basic Authentication and htpasswd files, developers and system administrators frequently make critical errors that completely compromise the security of their applications. Correcting these misconceptions is essential for maintaining a hardened server environment.

The single most devastating mistake is placing the .htpasswd file inside the public document root (e.g., /var/www/html/.htpasswd). While Apache is generally configured by default to block web requests to files beginning with .ht, relying on this default behavior is a dangerous gamble. If the server configuration is ever altered, or if you migrate to a server like Nginx that does not natively block .ht files without explicit configuration, an attacker can simply navigate to http://yourdomain.com/.htpasswd, download the entire database of hashed passwords, and begin cracking them offline. The .htpasswd file must always be stored in a directory above the web root, such as /etc/ or /var/secure/, where the web server application has file system read permissions, but the web server cannot serve the file via HTTP.

Another widespread misconception is the belief that HTTP Basic Authentication provides intrinsic data security. As detailed in the step-by-step breakdown, the browser transmits the username and password encoded in Base64. Base64 is an encoding scheme designed to ensure data survives transport across different protocols; it provides absolute zero cryptographic security. Anyone with a packet sniffer (like Wireshark) sitting on the same local network, or any node routing the traffic across the internet, can intercept the Authorization header and instantly decode the plaintext password. Therefore, Basic Authentication is fundamentally insecure unless it is strictly paired with HTTPS (TLS/SSL encryption). The TLS layer encrypts the entire HTTP payload, including the headers, ensuring that the Base64-encoded credentials cannot be intercepted in transit.

Best Practices and Expert Strategies

Professional system administrators employ a strict set of best practices when utilizing htpasswd generators to ensure maximum security and performance. The first rule of expert implementation is the absolute mandate of the bcrypt algorithm. Professionals no longer use MD5 or SHA-1 under any circumstances. When generating bcrypt hashes, experts carefully calibrate the cost factor. As of 2024, a cost factor of 10 or 12 is considered the industry standard for web authentication. A cost factor of 12 requires roughly 250 to 300 milliseconds of compute time on a modern server CPU. This is virtually unnoticeable to a human user logging in once, but it is mathematically devastating to an attacker attempting to brute-force millions of passwords per second.

Furthermore, experts understand that HTTP Basic Authentication lacks built-in brute-force protection. Because the web server simply returns a 401 status code for a failed login and immediately accepts another request, an attacker can write a script to guess thousands of passwords a minute directly against the login prompt. To mitigate this, professionals always pair their htpasswd implementations with an intrusion prevention software framework like Fail2Ban. Fail2Ban monitors the Apache or Nginx error logs; if it detects that a specific IP address has generated five 401 Unauthorized errors within a ten-minute window, it dynamically updates the server's firewall (iptables or ufw) to completely drop all network traffic from that IP address for a specified duration.

Finally, experts practice aggressive credential lifecycle management. Because htpasswd files are flat text files, there is no native way to enforce password expiration or complexity rules. Therefore, administrators must manually audit the files. When a contractor leaves a project, or a staging environment is no longer needed, the corresponding lines in the .htpasswd file must be immediately deleted. Stale credentials left in forgotten htpasswd files are a massive vector for unauthorized access, as they often rely on older, weaker passwords that may have been compromised in other data breaches.

Edge Cases, Limitations, and Pitfalls

While highly effective for simple access control, the htpasswd mechanism has severe architectural limitations that make it entirely unsuitable for complex, consumer-facing web applications. The most glaring edge case is the complete absence of a standardized "logout" mechanism. In modern session-based authentication (using cookies or JWTs), a server can invalidate a session token, instantly logging the user out. HTTP Basic Authentication does not use sessions; the browser simply caches the Base64-encoded credentials and automatically re-sends them with every single HTTP request to that domain. To log out of a Basic Auth session, the user must completely close their web browser, or the server must be configured to send a fake 401 response to clear the browser's cache—a hacky and unreliable workaround. This makes htpasswd unsuitable for public computers or environments where users share workstations.

Another significant pitfall involves file locking and performance degradation at scale. Because the .htpasswd file is a flat text file, the web server must read it sequentially from top to bottom to find a matching username. If a file contains 10 users, this search takes microseconds. However, if an administrator attempts to use an htpasswd file to manage 50,000 users, the server must perform a linear O(N) search for every single HTTP request. Furthermore, if the file is being updated (a new user is added) at the exact millisecond another process is trying to read it, file contention and locking issues can cause server errors. For any application requiring hundreds of users, a relational database or LDAP directory is mandatory.

Additionally, developers frequently fall into the trap of the bcrypt 72-byte truncation limit. The core Blowfish algorithm underlying bcrypt has a strict maximum input size of 72 bytes. If a user attempts to create a highly secure passphrase that is 80 characters long, the htpasswd generator and the underlying bcrypt library will silently truncate the password at the 72nd character. While a 72-character password is mathematically uncrackable anyway, this silent truncation can cause immense confusion if a developer attempts to migrate hashes to a different system or uses a different hashing library that handles the 72-byte limit differently, resulting in users suddenly being locked out of their accounts.

Industry Standards and Benchmarks

The cryptographic standards governing password hashing are rigorously defined by international security organizations, most notably the National Institute of Standards and Technology (NIST) and the Open Worldwide Application Security Project (OWASP). When generating htpasswd files, adherence to these benchmarks is critical for compliance with frameworks like SOC 2, HIPAA, or PCI-DSS.

According to NIST Special Publication 800-63B (Digital Identity Guidelines), passwords must be hashed using an approved, memory-hard or computationally expensive algorithm. While NIST heavily promotes PBKDF2 and Argon2id for modern applications, bcrypt remains an explicitly accepted standard due to its proven historical resilience. OWASP's Password Storage Cheat Sheet dictates that if bcrypt is used, the work factor (cost) must be tuned so that the hash calculation takes at least 250 milliseconds on the specific server hardware hosting the application. In the context of htpasswd, this generally translates to a minimum cost factor of 10, with 12 being preferred for high-security environments.

Furthermore, industry standards dictate strict permissions for the flat files themselves. The Center for Internet Security (CIS) benchmarks for Apache and Nginx explicitly state that password files must be owned by the root user, with read-only permissions granted strictly to the web server's service account (e.g., www-data on Debian/Ubuntu systems). The file permissions should be set to 0640 or 0600 in Unix environments. Any deviation from these benchmarks, such as granting world-readable permissions (0644), is flagged as a critical vulnerability during automated security audits, as it allows any compromised secondary process on the server to exfiltrate the credential database.

Comparisons with Alternatives

To fully contextualize the value of htpasswd generation, it is necessary to compare HTTP Basic Authentication against alternative access control methodologies. The most direct comparison is HTTP Digest Authentication. Digest Authentication was introduced in RFC 2069 as a direct response to the plaintext transmission vulnerability of Basic Auth. Instead of sending the password in Base64, Digest Auth requires the browser to perform a cryptographic hash of the password combined with a server-provided "nonce" (a one-time numerical value) before transmitting it. While this prevents the password from being intercepted in plaintext over unencrypted connections, Digest Auth is notoriously difficult to configure, requires storing passwords in a recoverable format on the server (negating the use of secure bcrypt hashes), and has been largely rendered obsolete by the universal adoption of HTTPS, which solves the transmission problem entirely.

When compared to modern Form-Based Authentication (using HTML forms, cookies, and database-backed sessions), htpasswd is vastly inferior in terms of user experience. Form-based auth allows for custom-branded login pages, "forgot password" workflows, multi-factor authentication (MFA/2FA), and precise session timeouts. Htpasswd offers none of these; it provides only a brutalist, browser-native pop-up box. However, form-based authentication requires significant application-level code (PHP, Node.js, Python), database provisioning, and maintenance. Htpasswd requires zero code and takes less than sixty seconds to implement at the server level.

Finally, compared to enterprise identity providers like OAuth 2.0, SAML, or OpenID Connect (which allow users to log in via Google, Microsoft, or Okta), htpasswd is an isolated, decentralized system. It cannot participate in Single Sign-On (SSO) ecosystems. Therefore, the architectural decision is clear: use OAuth or Form-Based Auth for public-facing applications and enterprise user management; use htpasswd and Basic Auth for internal server utilities, staging environments, and rapid, localized access control where development speed and infrastructure simplicity are the primary requirements.

Frequently Asked Questions

What happens if I forget the password stored in an htpasswd file? Because htpasswd files use one-way cryptographic hashing, it is mathematically impossible to recover or decrypt the original plaintext password from the hash. If a password is forgotten, the only solution is to generate a completely new hash for that username using an htpasswd generator and overwrite the old entry in the .htpasswd file. This is a deliberate security feature, ensuring that even the server administrator cannot read the users' actual passwords.

Can I use an htpasswd file to protect a single specific file instead of a whole directory? Yes, both Apache and Nginx allow for granular protection. In Apache, instead of applying the .htaccess directives to the entire directory, you can wrap the authentication directives inside a <Files "secret.html"> block. In Nginx, you can specify an exact match location block, such as location = /secret.html { ... }, and apply the auth_basic directives exclusively within that block. This allows public access to the rest of the directory while securing sensitive individual assets.

Why does my browser keep asking for the password in an infinite loop? An infinite login loop during HTTP Basic Authentication almost always indicates a mismatch between the web server's configuration and the contents of the htpasswd file. The most common causes are an incorrect absolute file path in the AuthUserFile directive, improper file permissions preventing the web server from reading the .htpasswd file, or a corrupted hash string. If the server cannot read the file or validate the hash, it will continuously return a 401 Unauthorized status, prompting the browser to ask for the credentials again.

Is it safe to use an online generator to create my htpasswd hashes? Using an online generator is generally safe provided the site executes the hashing algorithm locally in your web browser using JavaScript (Client-Side), rather than transmitting your plaintext password to their backend server. However, for maximum security in enterprise environments, system administrators should always use the native command-line utility (htpasswd -B -c .htpasswd username) provided by the apache2-utils or httpd-tools packages, guaranteeing the plaintext credential never leaves the local secure environment.

How many users can a single htpasswd file reasonably support? While there is no hardcoded limit to the number of lines an htpasswd file can contain, performance degrades significantly as the file grows because the web server must perform a linear, line-by-line search for every HTTP request. As a general industry rule of thumb, flat-file htpasswd authentication is suitable for anywhere from 1 to roughly 500 users. If your environment requires managing thousands of users, you should migrate to a database-driven authentication module like mod_authn_dbd for Apache or an external LDAP server.

Can I enforce Multi-Factor Authentication (MFA) with an htpasswd file? No, HTTP Basic Authentication and the htpasswd format fundamentally do not support Multi-Factor Authentication natively. The protocol is strictly limited to a single username and password transmission. If you require MFA (such as TOTP codes from Google Authenticator or SMS verification), you must abandon htpasswd and implement an application-level form-based authentication system or place the resource behind a modern reverse proxy identity provider like Cloudflare Access or Authelia.

What does the -c flag do when using the command-line htpasswd tool? The -c flag stands for "create." When you execute htpasswd -c /path/to/.htpasswd username, it instructs the utility to create a brand new file at that location. It is crucial to understand that if a file already exists at that path, using the -c flag will immediately overwrite and destroy the entire existing file, erasing all other users. To add a new user to an existing file, you must omit the -c flag.

Why are my passwords being truncated at 8 characters? If your passwords are being truncated at 8 characters, your system is using the obsolete, legacy crypt() algorithm. This occurs if you explicitly use the -d flag on the command line, or if you are using an ancient web server environment that does not support modern hashing. To fix this critical vulnerability, you must regenerate all passwords using the bcrypt algorithm (-B flag) or the APR1-MD5 algorithm (-m flag), both of which support passwords of virtually unlimited length (up to bcrypt's 72-byte limit).