If the server protection hierarchy is clear and the browser sophisticated enough to figure out right away if a document is protected, first step is visited very seldom (possibly only once) during the entire browsing session for each protected server.
A discussion of the basic protection scheme follows this information.
Once a server receives a request without an
Authorization: field to access a document that is
protected, it sends an Unauthorized 401 status code, and
a set of WWW-Authenticate: fields containing valid
authentication schemes and their scheme-specific parameters.
In Basic scheme the reply is following:
HTTP/1.0 401 Unauthorized -- authentication failed WWW-Authenticate: Basic realm="CollabName"
where realm specifies used password file; same server can use
different password file for different trees of documents (this is the
server-id specified in CERN server protection setup
file). Client can thus figure out which password to use at any given
time.
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, and sent it along with the next request in the
Authorization: field as follows:
Authorization: Basic encoded_string
When the server receives a request to access a document protected by
the Basic Scheme, and the request is a full request containing
Authorization: field which contains the Basic Scheme
information, it will execute the following Access Request Validation Procedure:
Authorization: field with the
scheme name Basic and encoded authorization string.
Unauthorized 401 status with
WWW-Authenticate: field containing appropriate scheme
name (Basic) and realm name is sent back (as if no
authorization information was given).
Unauthorized 401
status with appropriate WWW-Authenticate: field is sent
back.
Unauthorized 401 status and
WWW-Authenticate: field etc.
mask-group
(if) specified in protection setup file (using group file).
.www_acl (if any).
mask-group nor ACL, or if ACL exists,
but there is no entry for that file, access is denied with a
Frobidden 403 status code.
Unauthorized 401 status etc. is sent.
Not found 404 status is sent back.
This printable encoding step is applicable to PEM message types ENCRYPTED and MIC-ONLY. The same processing is also employed in representation of certain specifically identified PEM encapsulated header field quantities as cited in Section 4.6. Proceeding from left to right, the bit string resulting from step 3 is encoded into characters which are universally representable at all sites, though not necessarily with the same bit patterns (e.g., although the character "E" is represented in an ASCII-based system as hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the local significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure.
To represent the encapsulated text of a PEM message, the encoding function's output is delimited into text lines (using local conventions), with each line except the last containing exactly 64 printable characters and the final line containing 64 or fewer printable characters. (This line length is easily printable and is guaranteed to satisfy SMTP's 1000-character transmitted line length limit.) This folding requirement does not apply when the encoding procedure is used to represent PEM header field quantities; Section 4.6 discusses folding of PEM encapsulated header fields.
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group extracted from the output of step 3, each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. These characters, identified in Table 1, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
| Printable Encoding Characters | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Value Encoding | |||||||||||||||
| 0 | A | 8 | I | 16 | Q | 24 | Y | 32 | g | 40 | o | 48 | w | 56 | 4 |
| 1 | B | 9 | J | 17 | R | 25 | Z | 33 | h | 41 | p | 49 | x | 57 | 5 |
| 2 | C | 10 | K | 18 | S | 26 | a | 34 | i | 42 | q | 50 | y | 58 | 6 |
| 3 | D | 11 | L | 19 | T | 27 | b | 35 | j | 43 | r | 51 | z | 59 | 7 |
| 4 | E | 12 | M | 20 | U | 28 | c | 36 | k | 44 | s | 52 | 0 | 60 | 8 |
| 5 | F | 13 | N | 21 | V | 29 | d | 37 | l | 45 | t | 53 | 1 | 61 | 9 |
| 6 | G | 14 | O | 22 | W | 30 | e | 38 | m | 46 | u | 54 | 2 | 62 | + |
| 7 | H | 15 | P | 23 | X | 31 | f | 39 | n | 47 | v | 55 | 3 | 63 | / |
| Padding Character is = | |||||||||||||||
Because the password flies (almost) unencrypted through the Internet, anyone who is listening to the Internet traffic can find out people's user names and corresponding passwords. Thus this kind of a telnet-level protection only protects from accidental viewing of classified documents.
You migth think of this as a door. If you really want to get in, you can always break the lock, and get what you want, but the bottom line then is that then you have broken something, and that is wrong.
Thus the Basic Protection Scheme only provides the means of telling people that a document is a protected one; it does not prevent the document from being accessed by someone who wants it badly enough to go through the trouble of listening to the Internet traffic, finding out which printable encoding scheme we use, and decoding your username and password.
However, using IP address masking together with usernames ("only these people from these internet addresses") makes it more secure, because an intruder would also have to have access to the machine having the required IP address.
12 December 1993
Free Spam Protection Android ORM Simple Java Zip JMX using HTTP Great Eggnog Recipe