Forward secrecy limits the damage from later compromise of a long-term authentication key. For a correctly authenticated ephemeral Diffie-Hellman exchange, that key alone does not reveal earlier session secrets. The claim assumes those ephemeral secrets were not also captured. It does not make a compromised endpoint, key log, or recorded plaintext safe. ...
Linux applications normally obtain cryptographic randomness from a kernel generator, rather than consuming one newly collected physical bit for every output bit. Initialization and state reuse still matter. A busy machine is not automatically safe, and a quiet machine is not automatically broken. Diagnose the interface, kernel version, and boot or cloning process before deciding that a counter proves a security failure. ...
You do not choose a hash for the database; you choose it for the attacker who reads the database. Dedicated password hashes trade speed for resilience to increase the cost of offline guessing after a leak. Salt separates work; cost slows each guess. Verify with the stored parameters first, and consider a stronger rehash only after successful authentication. Weak passwords and server availability still set limits. Fast is the wrong goal Speed is the enemy here. General-purpose hashes such as SHA-256 are intentionally fast, allowing offline attackers to test guesses efficiently; actual rates depend on algorithm and hardware. Purpose-built password algorithms (bcrypt, scrypt, Argon2id) add a tunable cost factor plus per-user salt, so guesses require deliberate work and independently salted accounts have different stored values even with a shared password. The added per-guess work is the feature; its benefit still depends on the selected parameters and password strength. Choose an algorithm that is memory-hard where feasible, and pick a cost that stays high yet tolerable on the hardware that has to verify every login. ...