Choose a cryptographic tool by the property you need: use a fast hash for a fingerprint or integrity check, a password-hashing function to store password verifiers, authenticated encryption to keep data confidential and detect tampering, and a digital signature to establish authenticity and integrity. These jobs are not interchangeable: in particular, password hashing is not encryption, and encryption alone does not prove who created data.
Which cryptographic primitive should you use?
| Application need | Use | Reversible? | Key or secret handling |
|---|---|---|---|
| Fingerprint data or check integrity against a trusted expected digest | Cryptographic hash, such as SHA-256 | No | No secret key for an ordinary hash. A digest by itself does not prove who supplied the data. |
| Check whether a submitted password matches a stored verifier | Adaptive password-hashing function, such as Argon2id | No | Store the function’s parameters and salt with the verifier; do not store the password. |
| Keep application data confidential and detect unauthorized changes | Authenticated encryption, such as AES-GCM | Yes, with the key | Protect the encryption key; generate a fresh nonce for each encryption under the same key. |
| Prove data was signed by a holder of a private key and detect changes | Digital signature | No; verification is separate from decryption | Protect the private signing key; distribute the corresponding public key securely. |
The Node.js crypto API documentation describes the available interfaces; OWASP explains the distinct password-storage and encryption requirements in its Password Storage and Cryptographic Storage guidance.
How do you hash data in Node.js?
Use createHash() when you need a repeatable digest for a file, message, or other data. For example, a SHA-256 digest can help compare a downloaded file with a digest obtained through a trusted channel. If an attacker can replace both the file and the expected digest, the comparison does not establish authenticity; use a signature or another trusted mechanism for that.
In Node.js, the basic pattern is createHash('sha256').update(data).digest('hex'). The hexadecimal representation is for storage or display; digests are bytes, not ordinary Unicode text. Keep cryptographic output as bytes where possible, or choose an explicit encoding such as hexadecimal or base64 for a defined transport or storage format. Node.js cautions that crypto output is pseudorandom bytes and should not be treated as text.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
Availability depends on the Node.js version and its OpenSSL build or providers. Check the documentation for the major version actually deployed and verify that the needed algorithm is available in that runtime. An algorithm appearing in an API is not by itself a recommendation to use it: Node.js assigns developers responsibility for choosing algorithms and key sizes. MD5 and SHA-1 are not suitable where collision resistance is required, including digital signatures.
How do you hash a password in Node.js?
Do not store plaintext passwords, encrypt passwords for later recovery, or store a fast digest such as SHA-256 as the password verifier. A fast digest makes it cheap for an attacker with a stolen password database to test many guesses offline. Password storage needs a deliberately expensive, salted, adaptive function so each guess costs more. OWASP states: “Passwords should never be stored in plain text.” See its password-storage guidance for current recommendations.
Rank #2
Choose and configure a password-hashing function
OWASP recommends Argon2id first. Its current Password Storage Cheat Sheet lists a minimum configuration of 19 MiB of memory, 2 iterations, and 1 degree of parallelism. OWASP gives scrypt as an alternative, with minimum CPU/memory cost parameter 217, block size 8 (1024 bytes), and parallelization 1. These are recommendations in the linked guidance, not performance measurements or universal settings: recheck the live sheet and select parameters that fit the application’s security and workload requirements.
Where the deployment has a FIPS-140 compliance requirement, OWASP lists PBKDF2 with HMAC-SHA-256 at a work factor of 600,000 or more. For legacy bcrypt systems, it recommends a work factor of 10 or more and notes the 72-byte password limit. These constraints are reasons to check the applicable guidance and implementation carefully, not reasons to select a legacy function for a new system by default.
Rank #3
Store a verifier, not a recoverable password
Use a well-maintained implementation that supports the selected function and parameters for the Node.js version you deploy. Store the resulting verifier with the salt and the parameters needed to verify it; use the library’s verification routine rather than comparing a newly computed fast hash. Do not invent a shared salt or use a password as an encryption key without a suitable key-derivation design. A password verifier is for checking a login attempt, not for retrieving the original password or directly encrypting application data.
How do you encrypt data with Node.js crypto?
For data that must remain secret, use authenticated encryption so the recipient can also detect tampering. OWASP identifies GCM and CCM as preferred authenticated modes and recommends AES keys of at least 128 bits, ideally 256 bits. Use an explicit-key and IV API such as Node.js createCipheriv(); do not use the legacy password-based createCipher() and createDecipher() pattern. The historical password derivation for those helpers used MD5, one iteration, and no salt, making it unsuitable. See the OWASP Cryptographic Storage Cheat Sheet and the Node.js cipher and decipher API documentation.
Rank #4
Handle keys, nonces, and authentication tags as protocol data
- Generate encryption keys and nonces or IVs using cryptographically secure randomness, such as Node.js crypto random APIs, not
Math.random(). - Never reuse a GCM nonce with the same key. Treat the nonce and authentication tag as required parts of the encrypted record, not incidental metadata.
- Define a format for storing or transporting the algorithm identifier, key identifier if applicable, nonce or IV, ciphertext, and tag. Preserve binary values as bytes or encode each field deliberately.
- During decryption, do not expose or act on plaintext until authentication succeeds and the cipher’s finalization step completes. In Node.js, decryption is not complete until
final()succeeds; authenticated-mode tag handling must also be correct. - Keep keys separate by purpose. A key used for encryption should not casually double as a signing or other application key.
If deriving an encryption key from a password is genuinely necessary, use an appropriate key-derivation function and explicit-key/IV APIs rather than the legacy cipher helpers. Keep password verification and encryption-key derivation conceptually separate: the first checks a login, while the second produces key material for reversible encryption.
How do you sign and verify data in Node.js?
A digital signature provides authenticity and integrity, not confidentiality. The holder of a private key signs the data; a verifier uses the corresponding public key to check the signature and confirm that the signed data has not changed. Anyone with the public key may be able to verify, so a signature does not hide the message.
Recommended Free Tools
Node.js provides signing and verification APIs in its crypto documentation. Choose a scheme, key type, key size, and encoding to match current standards and the deployment’s requirements; the right selection depends on context, so do not infer it merely from an algorithm being available in the runtime. Protect the private key and establish how verifiers obtain and trust the associated public key.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common mistakes that weaken a Node.js crypto design
- Using SHA-256 for password storage: ordinary fast hashing is designed for speed, not to slow down password guessing.
- Encrypting passwords so they can be recovered: login systems should normally verify a one-way adaptive password hash rather than decrypt a stored password.
- Using unauthenticated encryption or ignoring authentication failure: confidentiality without integrity checks can leave tampering undetected; never consume plaintext before authenticated decryption finishes successfully.
- Reusing a GCM nonce with a key: generate a fresh nonce for every encryption under that key.
- Using legacy password-based cipher helpers: use explicit key and IV APIs with a suitable derivation function where a password-derived key is required.
- Treating bytes as strings or assuming an algorithm is available: encode binary values deliberately and validate the target Node.js runtime and its providers.
- Using one secret for every job: keep key material distinct by purpose and define how it is protected, rotated, and retired.
Plan key management as part of the implementation
Even a sound primitive cannot protect data if its key is exposed or mishandled. Generate keys with cryptographically secure randomness, restrict access, keep keys distinct by purpose, and decide how keys will be rotated and decommissioned before deploying a format that depends on them. Applications that need centralized access control, auditing, or managed rotation may benefit from a dedicated key-management system, balanced against its added complexity and administrative overhead. OWASP discusses that trade-off in its Cryptographic Storage Cheat Sheet.
Implementation checklist
- Write down whether the requirement is fingerprinting, password verification, confidentiality, authenticity, or a combination.
- Use the primitive intended for that property; do not substitute a hash, cipher, or signature for another.
- Check the live OWASP guidance and the crypto documentation for the exact Node.js major version deployed.
- Specify the stored format for salts, parameters, nonces or IVs, tags, encodings, and key identifiers where applicable.
- Define key access, rotation, backup, revocation, and decommissioning procedures.
- Test failure paths, especially incorrect passwords, unavailable algorithms, modified ciphertext, invalid tags, and untrusted signatures.
Primary references: Node.js Crypto documentation (v25.x), OWASP Password Storage Cheat Sheet, and OWASP Cryptographic Storage Cheat Sheet.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
