.htpasswd file Generator

---

htpasswd file creator

Limit 100 chars. Any character allowed other than :

Username: Password: Realm: (for digest)

---

Apache Servers recognize 4 formats for basic-authentication passwords.

1. PLAIN TEXT (i.e. unencrypted) Windows, BEOS, & Netware only.
2. CRYPT Unix only. Uses the traditional Unix crypt function with a randomly-generated 32-bit salt (only 12 bits used) and the first 8 characters of the password.
3. SHA1 {SHA} + Base64-encoded SHA-1 digest of the password.
4. MD5 $apr1$ + an Apache-specific algorithm using an iterated (1,000 times) MD5 digest of various combinations of a random 32-bit salt and the password

Basic Authentication

Access Authentication Framework

HTTP provides a simple challenge-response authentication mechanism that MAY be used by a server to challenge a client request and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.

auth-scheme    = token auth-param     = token "=" ( token | quoted-string )

The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and MUST include a Proxy- Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.

challenge   = auth-scheme 1*SP 1#auth-param

Note: User agents will need to take special care in parsing the WWW- Authenticate or Proxy-Authenticate header field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.

The authentication parameter realm is defined for all authentication schemes:

realm       = "realm" "=" realm-value realm-value = quoted-string

The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.

A user agent that wishes to authenticate itself with an origin server–usually, but not necessarily, after receiving a 401 (Unauthorized)–MAY do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy–usually, but not necessarily, after receiving a 407 (Proxy Authentication Required)–MAY do so by including a Proxy- Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication information of the client for the realm of the resource being requested. The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge.

credentials = auth-scheme #auth-param

Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include Basic if it is minimally acceptable.

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.

If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.

The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.

Proxies MUST be completely transparent regarding user agent authentication by origin servers. That is, they must forward the WWW-Authenticate and Authorization headers untouched, and follow the rules found in section 14.8. Both the Proxy-Authenticate and the Proxy-Authorization header fields are hop-by-hop headers.

Basic Authentication Scheme

The “basic” authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.

For Basic, the framework above is utilized as follows:

challenge   = "Basic" realm credentials = "Basic" basic-credentials

Upon receipt of an unauthorized request for a URI within the protection space, the origin server MAY respond with a challenge like the following:

WWW-Authenticate: Basic realm="WallyWorld"

where “WallyWorld” is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond with the same challenge using the Proxy-Authenticate header field.

To receive authorization, the client sends the userid and password, separated by a single colon (”:”) character, within a base64 [7] encoded string in the credentials.

basic-credentials = base64-user-pass base64-user-pass  =
<base64 [4] encoding of user-pass, except not limited to 76 char/line>
user-pass   = userid ":" password userid      = *
<TEXT excluding ":">
password    = *TEXT

Userids might be case sensitive.

If the user agent wishes to send the userid “Aladdin” and password “open sesame”, it would use the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See section 4 for security considerations associated with Basic authentication.

---

---

Please read about more Apache Password Protection Options.

This program is not safe as a setuid executable Do not make it
setuid

htpasswd is a simple program for manipulating password file for the Apache HTTP server. Originally by Rob McCool

1. Failure file accesspermission problem
2. Failure command line syntax problem usage message issued
3. Failure password verification failure
4. Failure operation interrupted such as with CTRLC
5. Failure buffer would overflow username filename or computed too
6. Failure username contains illegal or reserved acters
7. Failure file is not a valid htpasswd file

CHARSET_EBCDIC
CHARSET_EBCDIC
MAX_STRING_LEN 256
ALG_PLAIN
ALG_CRYPT 1
ALG_APMD5 2
ALG_APSHA 3
FILEPERM 1
SYNTAX 2
PWMISMATCH 3
INTERRUPTED 4
OVERFLOW 5
BADUSER 6
INVALID 7
APHTP_NEWFILEAPHTP_NOFILE 2
APHTP_NONINTERACTIVE 4
APHTP_DELUSER  8
file_t errfile
file_t ftemp
NL EOL_STR
itoa64 63 ASCII 64
".0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
while-n
s itoa64[v0x3f]
v 6

Make a password from the given information. A zero indicates success failure means that the output buffer contains an error message instead.
mk user  passwd
pwin[MAX_STRING_LEN]
pwv[MAX_STRING_LEN]
salt[9]

passwd
pw passwd
password_get "New password: " pwin
sn "password too $"
SIZE_T_FMT "" pwin
password_get "Re-type new password: " pwv
pwin pwv
 
"password verification error"
PWMISMATCH
ALG_APSHA:
XXX 28 sha1 s fixed len SHA
sha1_base64 pw
ALG_APMD5:
srand time time_t
to64 salt rand 8
salt[8]
md5_encode pw salt
ALG_PLAIN:
XXX this len limitation is not in sync with any HTTPd len.
ALG_CRYPT:
srand time time_t
to64 salt rand 8
salt[8]
crypt pw salt
 
Check to see the buffer is large enough to hold the username
hash and delimiters.
user
"resultant too "
OVERFLOW
user
":"

htpasswd [-cmdpsD] passwordfile username
htpasswdb[cmdpsD] passwordfile username
 
password
htpasswdn[mdps] username
htpasswdnb[mdps] username password
c Create a new file.
n Dont update file display results on stdout.
m Force MD5 encryption of the password
d Force CRYPT encryption of the password
p Do not encrypt the password plaintext.
s Force SHA encryption of the password.
 
b Use the password from the command line rather than prompting for it.
D Delete the specified user.

“On Windows NetWare and TPF systems the “-m” flag is used by ” “default.”

“On all other systems the “-p” flag will probably not work.”

Check to see the specified file can be opened for the given access.

algorithm user pwfilename
password

• APHTP_NEWFILE
• APHTP_NOFILE
• ALG_APMD5
• ALG_APSHA
• ALG_PLAIN
• ALG_CRYPT
• APHTP_NONINTERACTIVE
• APHTP_DELUSER

APHTP_NEWFILE APHTP_NOFILE
“username:passwordc andn options conflict”

APHTP_NEWFILE APHTP_DELUSER
“username:passwordc andD options conflict”

APHTP_NOFILE APHTP_DELUSER
“username:passwordn andD options conflict”

Make sure we still have exactly the right number of arguments left the filename the username and possibly the passwordb was specified.

- args_left
usage

APHTP_NOFILE
i–

PATH_MAX
“username:password filename too “

pwfilename pstrdup
MAX_STRING_LEN
“username:password username too $d”
MAX_STRING_LEN

user pstrdup
arg strchr user “:”
“username:password username contains illegal “
“acter “$c”" arg
BADUSER

APHTP_NONINTERACTIVE
MAX_STRING_LEN
“username:password password too $d”
MAX_STRING_LEN

password pstrdup

Lets do it. We end up doing a lot of file opening and closing but what do we care? This application isnt run antly.

password
pwfilename
user
tn “htpasswd.tmp.XXXXXX”

scratch cp[MAX_STRING_LEN]

algorithm CRYPT

existing_file
CHARSET_EBCDIC
xlate_t to_ascii

CHARSET_EBCDIC
xlate_open to_asci “ISO-8859-1″ DEFAULT_CHARSET

“xlate_open to ASCII-$d”

SHA1InitEBCDIC to_ascii

“SHA1InitEBCDIC$d”

MD5InitEBCDIC to_ascii

“MD5InitEBCDIC$d”

CHARSET_EBCDIC
algorithm user pwfilename password

algorithm CRYPT
algorithm APMD5
“Automatically using MD5 format.”

algorithm PLAIN
“Warning: storing passwords as plain text ” “might just not work on this platform.”

Only do the file checks were supposed to frob it.

APHTP_NOFILE
existing_file exists pwfilename
existing_file

Check that this existing file is readable and writable.

accessible pwfilename READ APPEND
"username:password cannot open file username:password for "
"readwrite access" pwfilename
FILEPERM

Error outc was omitted for this non-existant file.

APHTP_NEWFILE

"username:password cannot modify file username:password use "-c" to create it"
pwfilename
FILEPERM

As it doesnt exist yet verify that we can create it.

accessible pwfilename CREATE WRITE
"username:password cannot create file username:password"
pwfilename
FILEPERM

All the file access checks any have been made. Time to go to work try to create the for the username in question. If that fails theres no need to waste any time on file manipulations. Any error message text is ed in the buffer since the mk routine doesnt have access to .

APHTP_DELUSER
mk user
password
"username:password username:password"
APHTP_NOFILE
"username:password" record

We can access the files the right way and we have a record to add or update. Lets do it..

temp_dir_get  SUCCESS
 
"username:password could not determine temp dir"
ps "username:passwordusername:password" tn
file_mktemp ftemp SUCCESS
"username:password unable to create temporary file username:password"

If were not creating a new file copy records from the existing one to the temporary file until we find the specified user.

existing_file APHTP_NEWFILE
file_open fpw pwfilename READ BUFFERED
OS_DEFAULT SUCCESS
"username:password unable to read file username:password"
 
pwfilename
colon
cp line
scratch cp
while isspace scratch
scratch
scratch scratch ""
putline ftemp line
continue

See this is our user.

colon strchr scratch “:”

If we”ve not got a colon on the line this could well not be a valid htpasswd file. We should bail at this point.

"username:password The file username:password does not appear "
 
"to be a valid htpasswd file."
pwfilename
file_close fINVALID
user scratch
putline ftemp line
continue

APHTP_DELUSER We the user we were looking for. Add him to the file.

“Updating ” putline ftemp record

We the user we were looking for. Delete them from the file.

“Deleting “

file_close f
APHTP_DELUSER
"Adding "
 
putline ftemp record
APHTP_DELUSER
"User username:password not " user
"password for user username:password" user

The temporary file has all the data just copy it to the new location.

file_copy pwfilename FILE_SOURCE_PERMS
SUCCESS
"username:password unable to update file username:password"
 
pwfilename

• htaccess rewritecond
• htaccess caching
• htaccess https

---

Related Articles

• CSS Background Image Sprites
• .htaccess - Wikipedia
• Online Dojo JavaScript Compressor/Obfusc
• Troubleshooting Apache .htaccess Authent
• Apache Authentication in htaccess