Htpasswd Generator

Choose bcrypt

htpasswd supports MD5-crypt, SHA-1, crypt and bcrypt. Only bcrypt is appropriate now: it is deliberately slow and carries a tunable cost factor, so brute-forcing a stolen file is expensive. Plain SHA-1 entries are unsalted and fall to a rainbow table immediately, and traditional crypt truncates to eight characters, silently discarding the rest of a long password.

Nginx and Apache differ on support

Apache supports bcrypt from 2.4. Nginx relies on the system crypt implementation, so bcrypt works on Linux with glibc but not universally — a file that authenticates under Apache can fail under Nginx on a different base image. Testing after any move between servers is worth the minute.

Basic auth sends credentials on every request

The header carries base64-encoded username and password with each request. Base64 is encoding, not encryption, so over plain HTTP the credentials are readable in transit and in any proxy log. Basic auth is only acceptable over HTTPS, without exception.

What it is good for

Blocking staging environments from crawlers and casual visitors, protecting internal dashboards, and adding a layer in front of an application with weak native auth. It has no session, no lockout, no rate limiting and no password reset, so it is not a substitute for application authentication.

File placement matters

The password file must sit outside the web root. A .htpasswd inside a served directory can be fetched over HTTP unless explicitly denied, which hands over every hash in it. Restricting file permissions to the web server user is the second half of that.