Internet DRAFT - draft-happel-password
draft-happel-password
Internet Engineering Task Force (Page 1)
INTERNET-DRAFT
Thomas J. Happel
Expires: January 2004
Submitted: July, 2003
Web Site Password Considerations for IETF Standard Protocols
<draft-happel-password-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other than
as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
User security has been compromised at many visited web sites due
to the wide variety of password construction requirements being
presented to Internet users. One single, flexible, password
construction requirement accepted throughout the global Internet
community would promote web site user security by establishing a
construct, wherein any user established password would be
universally acceptable to any web site contacted.
Defacto Standard
The original IP password construct used a simple sixteen
character alphanumeric requirement for providing user access to
the Internet. This construct permitted use of any combination of
alphabetic (not all lower case) or numeric characters to a
maximum length of sixteen.
Web Site Requirements
For every different web site password requirement, the user must
somehow document either the actual password used, or how the
rules differ so that a derivation of the user's original password
could apply, and could be reconstructed by knowing how the rules
differ from the rules that the user employed to construct the
original password. Most users it would seem, prefer to use the
same password at multiple sites to avoid security breakdown by
having to record actual different passwords used at each site.
Sometimes more than one password is required at a given site when
linked-to related sites have different requirements than the
parent site; avoidance of this problem would typically take
the form of using a password that complied with the most
restrictive rules encountered at a particular web site, which
would assure compatibility with all links encountered; in any
event the variance from the original user established password
would have to be documented, and security that passwords are
employed to provide (using this scenario) quickly disappears with
the ensuing documentation. The need for simple password construct
rules would seem to be obvious. Following are some of the
password construct rules that I have encountered at various web
sites visited:
* Use from 6 to 10 characters; at least one must be numeric.
* Use up to 10 alphanumeric characters.
* Use 4 numeric characters.
* Use 7 numeric characters (consider how many of these will be
phone numbers).
* Use 8 cryptic alphanumeric characters supplied by the web site.
* Use up to 16 alphanumeric characters.
* Use 8 alphabetic and numeric characters in prescribed password
positions.
* Use alphanumeric characters and supply other personal
information.
This list could go on and on.
For example, password "Sebastian2510" was developed using the
following rule:
"13 characters alphanumeric where the first character is
uppercase alphabetic and the following 8 characters are lowercase
alphabetic followed by 4 numeric characters". A visited web site
has the following rule:
"Use from 6 to 10 characters; at least one must be numeric". The
resultant password derived by application of the web site rule
would be: "Sebastian2". If the original password had been
"blumenthal" or "frog", then the process becomes even more
complicated. In the final analysis, user password documentation
will compromise security that the password itself was intended to
provide.
I favor the simplicity of using 4-16 alphanumeric characters
supported by a browser link which would provide user help for
construction of a reasonably secure, viable password, which would
be acceptable at all web sites requiring user password(s).
Author's Address (please reply by email):
Thomas J. Happel
1436 Woodlawn Commons
Grand Haven, MI 49417-2323
Email: tjsomerset@charter.net
Happel Expires January 2004 (Page 2)