How To Encrypt A Password | Two Uses, One Right Answer

Password encryption works for documents and credentials files, while authentication systems require one-way hashing using algorithms like Argon2id or bcrypt.

Learning how to encrypt a password starts with one distinction: encryption scrambles data with a key so it can be reversed later, while the secure method for storing login credentials is hashing — a one-way transformation that cannot be undone. A Microsoft Word document or PDF you want to protect with a password? Encryption is exactly the tool you need. A user database for a website or app? Hashing is the standard, and the guidance from OWASP and the NCSC is consistent. Getting this distinction wrong can mean the difference between recoverable data and a security hole that exposes every user’s credentials.

This article covers both scenarios — when to encrypt and when to hash — with exact steps and current specifications.

What Does “Encrypt a Password” Actually Mean?

In everyday security writing, “password encryption” gets used as a catch-all term for scrambling a password into unreadable data. But the technical meaning matters. Encryption takes plaintext and a key and produces ciphertext that can be decrypted back to the original — it is reversible by design. Hashing, by contrast, is a one-way transformation. The original password cannot be recovered from the hash; the only way to verify a login is to hash the incoming password and compare it to the stored hash.

For authentication systems, the NCSC and OWASP both specify that passwords should be hashed using modern adaptive algorithms with a unique salt per password, not encrypted with a reversible key. Password encryption does have real uses — document protection, password manager vaults, and build-tool credentials — but those jobs differ fundamentally from user authentication.

Encrypting a Password for Storage: Why Hashing Is the Standard

When a user creates an account on a website, the system should never store their password in a form that can be reversed. If an attacker breaches the database, encrypted passwords — which can be decrypted if the key is compromised — expose every user’s credentials in plaintext. A hashed password with a per-user salt cannot be reversed, and even if the hash database leaks, the attacker must crack each hash individually, a process modern algorithms make computationally expensive.

OWASP ranks Argon2id as the top choice for password hashing, followed by scrypt, bcrypt, and PBKDF2. The NCSC similarly mandates salted, iterated hashing with multiple rounds and recommends MFA for important accounts and internet-facing systems.

How Do You Hash a Password Correctly?

The right algorithm depends on your environment, but OWASP’s Password Storage Cheat Sheet provides concrete minimums for each option. The table below summarizes the current specifications and their trade-offs. Every password also needs its own unique salt — generated by a cryptographically secure random generator — to defeat rainbow-table attacks, and the transport layer must use HTTPS so the password arrives at the server unread by eavesdroppers.

NIST-based guidance recommends a minimum password length of 8 characters, with 15 characters as the target, allowing up to 64 characters and all printing ASCII characters plus space. The NCSC advises against arbitrary complexity rules — a long passphrase consistently beats a short complex password for both security and user convenience.

How To Encrypt a Password in Documents and Files

For protecting an individual file — an Office document or a PDF — encryption is the correct approach. Both Microsoft Word and Adobe Acrobat support built-in password encryption that scrambles the file contents and requires the password to open or modify it.

In Microsoft Word, open the document, go to File > Info > Protect Document > Encrypt with Password, enter the password, and confirm it. The document will then require that password to open — a lock icon appears on the file, and anyone who tries to open it sees a password prompt before the contents load.

In Adobe Acrobat, open the PDF, go to Tools > Protect > Encrypt > Encrypt with a Password. You can choose whether the password controls document opening, permissions like printing and editing, or both. After encryption, the PDF displays a padlock icon in the navigation panel and prompts for the password or restricts the actions you selected.

Unlike hashing, these encryption methods are reversible — anyone with the password can recover the original file contents. That property is exactly what you need for document protection, and it is why encryption and hashing serve different purposes.

Encrypting Passwords in Build Tools

Development tooling sometimes needs to store credentials so automated builds can deploy artifacts to servers. Apache Maven supports server password encryption to protect credentials in settings.xml. Generate a master password with mvn --encrypt-master-password <password>, then encrypt individual server passwords with mvn --encrypt-password <password> and paste the output into the servers section of your settings.xml file.

This is true encryption — the credentials can be decrypted during the build process — and it is the correct approach because Maven needs the original password to authenticate with the deployment server. The master password protects the encrypted values at rest.

Common Mistakes That Undermine Password Security

• Using plain SHA-2 for password storage. SHA-2 is designed for integrity checking, not password hashing — it is fast enough to make brute-force attacks practical. Use an adaptive algorithm instead.
• Reusing the same salt for every password. A per-user salt defeats rainbow tables and precomputation attacks; a shared salt protects none of them.
• Ignoring bcrypt’s 72-byte input limit. Passwords longer than 72 bytes get silently truncated in most bcrypt implementations, which can produce unexpected authentication failures.
• Encrypting passwords in an authentication database. If the encryption key is compromised, all stored passwords can be decrypted wholesale. Hashing avoids this single-point-of-failure risk entirely.

Choosing the Right Method

The decision tree is straightforward. For user authentication in any application — web, mobile, or desktop — hash passwords using Argon2id (or bcrypt or PBKDF2 if your stack requires it) with a unique salt per user, enforce MFA where possible, and secure the transport layer with HTTPS. For protecting individual files — Word documents, PDFs, archives — use the application’s built-in password encryption, remembering that this is reversible by design. For build-tool credentials, Maven’s encryption feature is purpose-built for the job.

The single most important takeaway: encryption and hashing are not interchangeable. Using the correct one for the job keeps your own data accessible when it needs to be and your users’ credentials permanently out of reach.