Why APR1-MD5 is not one of the format options#
APR1-MD5 is Apache's own variant of the MD5-crypt algorithm — a specific, iterative construction that has to be reproduced exactly, byte for byte, to interoperate with real Apache installations. Getting a detail of that iteration wrong produces a hash that looks plausible but silently fails to authenticate anyone, and the failure mode is nearly impossible to debug from the outside. Rather than ship a hand-rolled implementation of an algorithm this easy to get subtly wrong, this tool offers bcrypt — the format Apache's own documentation recommends as the current default — and the much simpler {SHA} format for legacy compatibility.
bcrypt versus {SHA}: pick bcrypt unless you have a specific reason not to#
{SHA} is just a single, unsalted SHA-1 hash of the password — a legacy format kept around for compatibility, not because it's a good choice today. Unsalted means the same password always produces the exact same hash, which is exactly the property a good password hash should not have (it makes precomputed rainbow-table attacks trivial). bcrypt, by contrast, includes a random salt and deliberately expensive repeated hashing (the "cost factor"), specifically designed to resist both of those attacks. Use {SHA} only if the receiving server genuinely does not support anything newer; bcrypt is the right default otherwise.
Why the same input produces a different bcrypt hash every time#
A fresh random salt is generated on every single click, mixed into the hash before the expensive part of the algorithm runs — this is intentional and correct. Two different bcrypt hashes for the identical password are not a bug; they will both verify correctly against that password, and the randomness is exactly what keeps two users who happen to choose the same password from having identical, comparable hashes in the file.