webgates-secrets
User-focused secret value and hashing primitives for the webgates ecosystem.
webgates-secrets is the secret and hashing layer of the workspace. It provides the server-side security building blocks used to hash credentials, verify them safely, and bind hashed secrets to account identifiers.
If webgates-core defines the domain model and webgates-repositories defines persistence, webgates-secrets defines how sensitive credential values are transformed into safe stored representations.
Who this crate is for
Use webgates-secrets when you want to:
- hash passwords or other secrets in framework-agnostic Rust code
- verify plaintext credentials against stored hashes
- construct
Secretvalues for repository storage - use Argon2id with sensible defaults
- build custom secret storage or authentication flows outside HTTP frameworks
- work directly at the secret boundary without pulling in higher-level crates
For typical application use, the secrets feature on the webgates composition crate re-exports the same types.
What you work with in this crate
Most developers only need to understand four pieces:
HashingServicedefines the hashing and verification boundaryArgon2Hasheris the provided implementation you will usually useHashedValueis the stored PHC-format hash stringSecretbinds that hash to an account identifier for persistence and verification flows
Install
Use the webgates composition crate if you want these types re-exported through the higher-level stack:
[]
= { = "1.0.0", = false, = ["secrets"] }
Or depend on the crate directly:
[]
= "1.0.0"
Minimum supported Rust version: 1.91.
The mental model
The easiest way to understand this crate is:
- plaintext secrets should never be stored directly
- a
HashingServiceturns plaintext into a stored hash and verifies candidate input later Argon2Hasheris the provided hashing implementationSecretties a stored hashed value to an account identifier- repositories or higher-level auth services persist and use those
Secretvalues
Quick start
Hash and verify a password
use VerificationResult;
use Argon2Hasher;
use HashingService;
let hasher = new_recommended.unwrap;
let hashed = hasher.hash_value.unwrap;
let result = hasher.verify_value.unwrap;
assert_eq!;
Create and verify a Secret
Secret ties a hashed credential to an account identifier and is the type typically stored in repositories.
use VerificationResult;
use Argon2Hasher;
use Secret;
use Uuid;
let account_id = now_v7;
let hasher = new_recommended.unwrap;
let secret = new
.map_err?;
let verification = secret
.verify
.map_err?;
assert_eq!;
# Ok::
Core concepts
1. HashingService is the abstraction
HashingService defines the small contract for:
- hashing a plaintext value
- verifying a plaintext value against a stored hash
This lets higher-level crates depend on a stable hashing interface without coupling directly to one algorithm implementation.
2. Argon2Hasher is the default implementation
Argon2Hasher is the provided HashingService implementation.
It uses Argon2id, which is a strong default for password hashing because it is designed to resist brute-force and hardware-accelerated attacks better than older password hashing schemes.
3. HashedValue is what you store
A HashedValue is the PHC-format string produced by the hashing implementation.
It is self-contained and typically includes:
- algorithm identifier
- version
- parameters
- salt
- hash
That means you can store it directly and use it later for verification.
4. Secret binds the stored hash to an account
Secret is the main value object you use when secret storage needs to be associated with an account identifier.
It stores:
account_idsecretas aHashedValue
This is usually the type repositories persist.
Security notes
- plaintext secrets are hashed immediately in
Secret::newand never stored in the resulting value Argon2Hasher::new_recommended()uses a production-safe preset; do not weaken it for production systems- store only
Secret::secretandSecret::account_id; never store plaintext passwords - avoid logging
HashedValuestrings; even hashed values should be treated as sensitive - use secure password-reset and credential-rotation flows outside this crate when credentials must change
Features
This crate has no optional features. All public types are available unconditionally.
Which crate should you use?
- use
webgates-secretswhen you need secret hashing and verification primitives directly - use
webgateswith thesecretsfeature when you want the same types through the higher-level composition crate - use
webgates-repositorieswhen you want repository implementations that persistSecretvalues - use
webgates-corewhen you only need the domain model and not the secret layer
Recommended onboarding path
If you are new to this crate, I recommend this order:
hashing::hashing_service::HashingServicehashing::argon2::Argon2Hasherhashing::HashedValueSecret- error types in
errorsandhashing::errors
Related crates
webgates- user-facing composition crate; exposes these types via thesecretsfeaturewebgates-core- domain types andVerificationResultwebgates-repositories- repository implementations that persistSecretvalues
License
MIT