Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Zozi96/hash-forge/llms.txt
Use this file to discover all available pages before exploring further.
HashManager is the central orchestrator in Hash Forge. It holds one or more hasher instances, routes verification to the correct algorithm automatically, and exposes a consistent API for hashing, verifying, migrating, and inspecting password hashes regardless of which algorithm produced them. Every feature in the library — async support, the builder pattern, configuration loading, and password policies — is ultimately surfaced through HashManager.
Creating a HashManager
There are four ways to obtain aHashManager instance. Choose the one that fits how your application manages configuration.
String-based factory
HashManager.from_algorithms() is the quickest way to get started. Pass one or more algorithm name strings and the factory creates the appropriate hasher objects for you using default parameters.
Direct instantiation
Construct hashers yourself for full control over every parameter, then pass them directly toHashManager.
Config-driven
HashManager.from_config() reads algorithm parameters from a HashForgeConfig object — loaded from environment variables, a JSON file, or a dict — and wires up the hashers for you.
Policy-driven
HashManager.from_policy() creates a manager that enforces a PasswordHashPolicy profile. The policy controls which algorithm is preferred, which are permitted for verification, and whether deprecated algorithms are blocked.
Core Operations
Hashing a password
hash() always delegates to the preferred hasher — the first hasher provided during construction.
Verifying a password
verify() inspects the hash string to determine which algorithm produced it, dispatches to that hasher, and returns True or False. You never need to specify the algorithm manually.
Checking if a rehash is needed
needs_rehash() returns True when the hash was produced with parameters that no longer match the current hasher configuration, or when the algorithm used is not the preferred one.
The first hasher added to
HashManager is always the preferred hasher. All calls to hash() use this hasher, and needs_rehash() returns True whenever the stored hash was not produced by the preferred hasher.Advanced Operations
Rotate — verify then re-hash
rotate() combines verify() and hash() into a single call. If verification succeeds it immediately re-hashes with the preferred hasher and returns the new hash. If verification fails it returns None — no exception, no exposure of plaintext to the caller.
Verify and update
verify_and_update() returns a two-element tuple: a bool indicating whether verification succeeded, and either a new hash string (if a rehash is required) or None (if the stored hash is already up to date).
tuple[bool, str | None].
Inspect a hash
inspect() returns a dictionary of metadata about a stored hash without revealing the raw digest or salt. The dictionary always contains:
| Key | Type | Description |
|---|---|---|
algorithm | str | Canonical algorithm name |
category | str | One of password, legacy, digest, deprecated |
deprecated | bool | True if the algorithm is deprecated |
iterations for PBKDF2, rounds for bcrypt) are included when available.
List registered algorithms
list_algorithms() returns the algorithm names registered in the current manager instance, in insertion order.
Quick Hash
HashManager.quick_hash() is a static method for one-off hashing without creating a persistent manager instance. It accepts an optional algorithm argument (defaults to "pbkdf2_sha256") and passes any remaining keyword arguments to the underlying hasher.
quick_hash creates a single-use hasher instance and discards it after hashing — it is not suitable for verification workflows where you need to persist the manager.