Firewalls and iptables vs SSH hardening vs Password hashi
MUDs traditionally store player credentials in flat files or embedded databases using outdated crypt() algorithms vulnerable to offline cracking. When upgrading security, administrators must select a hashing library compatible with legacy C codebases while providing modern resistance to GPU-based attacks. This comparison evaluates four cryptographic implementations for integration with DikuMUD, CircleMUD, and derived codebases, prioritizing practical migration paths over theoretical security maxima.
OpenWall crypt_blowfish
Widely deployed bcrypt implementation for POSIX systems
Best for: Legacy MUDs requiring minimal code changes and hash migration
www.openwall.com/crypt/ ↗Argon2 Reference Implementation
PHC winner with memory-hard properties
Best for: New MUD projects or complete rewrites prioritizing offline cracking resistance
github.com/P-H-C/phc-winner-argon2 ↗libsodium
High-level cryptographic library with secure defaults
Best for: Administrators wanting modern cryptography without parameter configuration risk
doc.libsodium.org/ ↗OpenSSL EVP (PBKDF2)
FIPS-compliant derivation via standard library
Best for: Environments requiring compliance with enterprise cryptographic standards
www.openssl.org/docs/manmaster/man7/crypto.html ↗| Criterion | OpenWall crypt_blowfish | Argon2 Reference Implementation | libsodium | OpenSSL EVP (PBKDF2) | Winner |
|---|---|---|---|---|---|
Legacy Integration Effort Difficulty of replacing existing crypt() calls in ancient C codebases without breaking existing player files | Low - Drop-in crypt replacement with compatible signature | Medium - Requires new data structures and storage format | Medium - Clean API but requires external linking | High - Complex initialization and context management | OpenWall crypt_blowfish |
GPU and ASIC Resistance Resistance to parallelized brute force attacks using graphics cards or specialized hardware | Moderate - Cost factor adjustable but CPU-focused | High - Memory-hard design blocks GPU optimization | High - Defaults to Argon2id with memory hardness | Low - SHA256 vulnerable to ASIC acceleration | Argon2 Reference Implementation |
Side-channel Protection Protection against timing attacks and secure memory handling to prevent hash leakage | Moderate - Timing safe but no explicit secure zeroing | High - Explicit secure memory clearing functions | High - sodium_malloc with guard pages and canaries | Moderate - Depends on OpenSSL version and build flags | libsodium |
Build Dependency Complexity Additional libraries or build tools required for compilation on restricted hosting environments | Low - Single C file drop-in | Low - Self-contained C with minimal build system | Medium - Requires package installation or static linking | Low - Usually present but version varies | OpenWall crypt_blowfish |
Concurrent Login Performance CPU and memory impact during multiple simultaneous player authentications on single-core hosts | High - CPU intensive by design causing lag | Variable - Memory bound may swap on low-RAM hosts | High - Optimized but memory-hard causes delays | Moderate - CPU only iteration predictable | OpenSSL EVP (PBKDF2) |
Migration Path from Legacy crypt() Ability to verify existing DES or MD5 hashes while transparently upgrading active players | Native - Supports traditional crypt for backwards compatibility | None - Requires password reset or rehash on login | None - Green field only no legacy support | None - Requires complete rehashing of database | OpenWall crypt_blowfish |
Algorithm Parameter Control Granularity of control over cost parameters, memory usage, and algorithm variants | Moderate - Cost factor only adjustable | High - Memory, threads, and time independently tunable | Low - Sensible defaults locked to prevent misconfiguration | Moderate - Iteration count selectable | Argon2 Reference Implementation |
Long-term Maintenance Risk Likelihood of future vulnerabilities, API deprecation, or project abandonment | Low - Stable since 1990s minimal changes | Low - Standardized by RFC 9106 | Low - Active development with security focus | Medium - Legacy API facing deprecation in OpenSSL 3.0 | libsodium |
Our Verdict
OpenWall bcrypt offers the pragmatic path for legacy MUDs needing immediate security improvements without architectural changes or player password resets. Argon2 suits new development accepting migration complexity for superior offline protection. libsodium abstracts cryptographic choices but introduces dependency risks for statically-linked production binaries. OpenSSL PBKDF2 remains viable only where FIPS compliance mandates its use, offering inferior resistance to specialized cracking hardware compared to memory-hard alternatives.
Use-Case Recommendations
Scenario: Running DikuMUD derivative from 1990s with minimal C knowledge and no package manager access
→ OpenWall crypt_blowfish
Single C file compilation requires no external dependencies and preserves existing hash format for backwards compatibility during migration
Scenario: Building new MUD engine from scratch with modern development practices
→ libsodium
Prevents cryptographic misconfiguration through high-level API and includes secure memory primitives for handling sensitive player data
Scenario: High-security MUD handling real-world currency or sensitive personal data under compliance requirements
→ Argon2 Reference Implementation
Maximum resistance to offline cracking through memory-hard properties justifies the engineering cost of reauthentication implementation
Scenario: Shared hosting environment with OpenSSL available but no ability to install additional libraries
→ OpenSSL EVP (PBKDF2)
Ubiquitous availability outweighs security limitations when dependency installation is impossible and immediate protection required
.