[3105] in WWW Security List Archive
HTTP password "uuencoded"?
daemon@ATHENA.MIT.EDU (KPJ)
Fri Sep 27 13:22:34 1996
To: www-security@ns2.rutgers.edu
Date: Fri, 27 Sep 1996 17:44:11 +0200
From: KPJ <kpj@sics.se>
Errors-To: owner-www-security@ns2.rutgers.edu
Michael Brennen <mbrennen@fni.com> wrote:
|>|You are both right. Passwords are encoded in the .htaccess with crypt(),
|>|the standard password encryption routine. However, when transferring the
|>|keyed in password from the browser to the server, the p/w is uuencoded.
SUMMARY:
========
The HTTP password is _NOT_ in uuencoded format.
The HTTP password encoding is as defined by the PEM standard (RFC 1421).
The MIME base64 encoding is as defined by the PEM standard (RFC 1421),
but eliminates the "*" mechanism for embedded clear text.
Neither of the above are equal to the UUENCODE encoding.
Here are the facts:
==================
The Basic Protection Scheme for the WWW
<URL: http://www.w3.org/pub/WWW/AccessAuthorization/Basic.html>
specifies the standard HTTP password scheme as follows:
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Step 2: Client Authenticates Himself
After receiving Unauthorized status code, the browser prompts for user name
and password (if they are not already given by the user), and constructs a
string containing those two separated by a colon:
username:password
This string is then encoded into printable characters [1], and sent it along
with the next request in the Authorization: field as follows:
Authorization: Basic encoded_string
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
[1] above is the URL
<URL: ttp://www.w3.org/pub/WWW/AccessAuthorization/Uuencode.html>
which simply contains:
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Printable Encoding
Encoding into printable characters is done as defined in RFC 1421.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
So, the password in encoded as specified by RFC 1421, "Privacy Enhancement
for Internet Electronic Mail: Part I: Message Encryption and Authentication
Procedures", which is part of PEM (Privacy Enhanced Mail).
The MIME standard RFC 1521, "MIME (Multipurpose Internet Mail Extensions)
Part One: Mechanisms for Specifying and Describing the Format of Internet
Message Bodies" states", on page 20:
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
5.2. Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable. The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data. This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
The base64 encoding is adapted from RFC 1421, with one change: base64
eliminates the "*" mechanism for embedded clear text.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
RFC 1421 specifies this table for the
encoding:
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Printable Encoding Characters
Table 1
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Compare this to the UUENCODE algorithm below, to see that they are different:
ALGORITHM:
---------
While not end of file:
Read up to 45 bytes from input file.
Store that length (45 or less) as an encoded byte.
Store the data (45 bytes or less) like this:
Take three consecutive input bytes A1, A2, A3
Convert them into four bytes B1, B2, B3, B4
In a C-like pseudo-syntax:
B1 = A1 >> 2
B2 = (A1 << 2) & 060 | (A2 >> 4) & 017
B3 = (B2 << 2) & 074 | (A3 >> 6) & 3
B4 = A3 & 077
Output B1, B2, B3, B4 as encoded bytes
[Each encoded byte is created by adding octal 40 to the byte.]
The output from the above algorithm are stored thus:
-----------------------
begin <mode> <filename>
<length><xxxx>...<xxxx>
...
end
-----------------------
NOTES:
(1) The last line before 'end' is a line consisting of a SPACE only.
This must be there, or you get a 'Short file' error.
This represents a zero length data block. If the input file was
empty, this is the only data between the 'begin' and 'end' lines.
(2) If the input file length is not a multiple of three (3), then
the last output line will be padded, as if the last byte was
followed by enough zero bytes (NULs) to become a multiple of 3.
This does not matter since the UUDECODE software will use the
<length> byte to see how many bytes there really are.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/kpj
____________
KPJ Jaakkola Internet: kpj@sics.se
Swedish Institute of Computer Science (SICS) Tel: +46 87 52 15 66
PO Box 1263, S-164 28 KISTA Fax: +46 87 51 72 30
SWEDEN WWW: http://www.sics.se/~kpj/ Pager: +46 74 01 71 61 3
