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 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)