This research note is restricted to the personal use of dquayle@hamilton.edu G00238344
Best Practices in User ID Formation, 2012 Update Published: 28 August 2012
Analyst(s): Ant Allan
Poor user ID formats create usability, operational and security problems. Enterprises introducing new global user-naming conventions should follow these best practices to maximize benefits.
Key Challenges ■
Enterprises often struggle with an inconsistent set of user ID formats across multiple platforms, which burdens users with multiple, disparate user IDs and increases the chance of errors in manual user administration arising from conflating different users.
■
There is no single best format. Each offers different trade-offs of key criteria.
■
User IDs cannot be considered confidential; thus, they must not impart information that may identify the user as a potential target, or otherwise be exploited by an attacker.
Recommendations ■
Evaluate the need for a new standard user ID format, considering benefits, costs and impacts.
■
Choose a format that provides the best balance of uniqueness, persistency, neutrality, universality and memorability.
■
If you choose a name-based format, ensure that it is acceptable to all users, especially international users.
■
If you choose an arbitrary format, ensure that it can meet persistency and consistency requirements.
■
Avoid using a structured format.
■
Ensure that your chosen format extends sensibly to administrator and shared accounts.
■
Relax requirements for customer user IDs to improve customers' user experience.
Table of Contents
This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Introduction............................................................................................................................................ 2 Analysis.................................................................................................................................................. 3 Evaluate the Need for a New Standard User ID Format, Considering Benefits, Costs and Impacts .........................................................................................................................................................3 Choose a Format That Provides the Best Balance of Uniqueness, Persistency, Neutrality, Universality and Memorability............................................................................................................4 If You Choose a Name-Based Format, Ensure That It Is Acceptable to All Users, Especially International Users............................................................................................................................4 Name-Based User ID Strengths..................................................................................................5 Name-Based User ID Limitations................................................................................................ 5 International Considerations........................................................................................................5 If You Choose an Arbitrary Format, Ensure That It Can Meet Persistency and Consistency Requirements................................................................................................................................... 6 Arbitrary User ID Strengths......................................................................................................... 6 Arbitrary User ID Limitations........................................................................................................6 Avoid Using a Structured Format...................................................................................................... 7 Structured User ID Strengths......................................................................................................7 Structured User ID Limitations.................................................................................................... 7 Ensure That Your Chosen Format Extends Sensibly to Administrator and Shared Accounts............. 7 Relax Requirements for Customer User IDs to Improve Customers' User Experience....................... 8 Assigning Arbitrary User IDs........................................................................................................8 Using Users' Email Addresses.................................................................................................... 8 Allowing Users to Choose Their Own User IDs............................................................................8 Recommended Reading.........................................................................................................................9
List of Figures Figure 1. Example of Name Change From Unicode Into ASCII-Only User IDs......................................... 5
Introduction A user identifier (user ID; see Note 1) is used to uniquely identify a user of a system at login, during administration, in audit logs and so on. However, many enterprises lack a uniform user ID format across all systems, and are often constrained by differences in valid formats among disparate systems. Poorly chosen and inconsistently applied formats give rise to usability, operational and security problems. Is there a format that can minimize these problems and maximize benefits?
Page 2 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
While there is no single best format, this research presents best practices that will help enterprises choose a format, providing a balance of different criteria.
Analysis Evaluate the Need for a New Standard User ID Format, Considering Benefits, Costs and Impacts First and foremost, is implementing a new standard format really necessary? A global format, consistent across multiple systems, can help with user-to-account correlation, promote end-user "goodwill," achieve cost savings through the reduction of help desk calls caused by forgotten user IDs, and reduce administration errors and consequent operational and security issues. Another source of cost savings is directory consolidation, since conflicting standards inhibit directory consolidation that would enable greater cost-efficiencies in various areas supported by 1
directory services.
A global format is not, however, a prerequisite for enterprise single sign-on (ESSO) or password management, since such tools keep track of all user ID mappings for each person. In addition, ESSO tools alleviate the need for the user to remember all login user IDs, except for his or her network login user ID.
2
Retrofitting a new standard format across multiple systems isn't limited to renaming user accounts and profiles. Changing a user ID can have additional costs and impacts: ■
In some systems, "renaming" might require cloning the old user account, with all its attributes and entitlements, and perhaps copying personal files and other resources, and then deleting the 3
original. (However, in some systems — especially email — it may be possible to simply set up the new user ID as an alias for the old.) ■
There might be problems with pipeline transactions tagged with the old user ID, and these 4
cannot be completed if the old user ID is deleted. ■
There might be segregation of duties issues: A dishonest person with the appropriate entitlements may take advantage of the change by, for example, raising a purchase order under his or her old user ID and approving it under his or her new one.
Nonetheless, enterprises commonly include a global format within a user administration or other identity and access management (IAM) project so that, in the long term, benefits can be realized for new users and applications. Furthermore, an enterprise might wish to introduce a new format to avoid problems (such as those discussed later) with existing formats.
Page 3 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Choose a Format That Provides the Best Balance of Uniqueness, Persistency, Neutrality, Universality and Memorability User IDs should be: ■
Unique — Necessarily so within each namespace, but preferably across the enterprise. Additionally, a user ID should not be reused at least within a period shorter than the retention period for audit records. Reuse can result in the new user gaining entitlements previously assigned to that user ID, and can erode the forensic value of old audit trails.
■
Persistent — A user should use the same user ID throughout his or her lifetime in the enterprise, regardless of changes in employment status (see Note 2). Having a persistent user ID avoids the costs and impacts of changing a user ID, as discussed above.
■
Neutral — The format should not carry information that would be useful to an attacker, such as employment status or any particular role, entitlements or privileges.
■
Universal — The format should be the same across all systems and be usable across all endpoint devices. However, this is limited by what is valid on each system and endpoint — there is no industry consensus. To ensure maximum universality, user IDs should be limited to the Basic Latin character set (see Note 3).
■
Memorable — A user, especially one with multiple user IDs across multiple systems, should not be overburdened with hard-to-remember user IDs.
The formats that might be used for user IDs fall into the following categories: 1.
The user's common name or something derived from it, such as ant.allan.
2.
A wholly arbitrary or sequential number or alphanumeric string, such as an employee number.
3.
A structured user ID that concatenates a role or organizational unit code with either of the previous two formats. (Gartner deprecates this format; see below.)
In addition, a growing number of enterprises enable end users to create their own free-format user IDs. Typically, this procedure is allowed for lower-risk consumer environments. The best practice approaches for these formats are discussed below. Note that, as user IDs are used in too many "public" ways, enterprises should not consider them to be confidential information (but see Note 4), or rely on "obscure" user IDs for access control (see Note 5).
If You Choose a Name-Based Format, Ensure That It Is Acceptable to All Users, Especially International Users Name-based formats are very common in email names (such as ant.allan@gartner.com). There are standard formats for email addresses (see Note 6), but other nonstandard variants are common (see Note 7).
Page 4 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Name-Based User ID Strengths ■
It is memorable and neutral (except for named officers of the company).
■
It is easy to recognize the user on reports, audit logs and other documentation.
Name-Based User ID Limitations ■
It is not unique by default. Duplicates can often arise and will be more common the more abbreviated the user ID is. In some cases, a shorter form is imposed by the limitations of a given system. The enterprise must deal with duplicates effectively: While middle initials can be used, that doesn't always solve the problem. The most common approach is to add an increasing suffix to the user ID — for example, leigh.brackett2, robertehoward3, kwagner4. Some enterprises go much further, using only initials with a longer sequential number — for example, lb040, rh025, kw073 — but this significantly reduces memorability.
■
It is not always persistent. The enterprise may need to address changes of legal names (typically due to a change in marital status). It may be difficult to avoid user ID reuse.
■
Enterprises should take care with concatenated and truncated forms so that the resulting user ID does not form a word that's offensive or otherwise inappropriate.
International Considerations The enterprise needs a consistent way of dealing with names that include characters outside the Basic Latin character set. Common names that require other character sets for proper presentation may have different possible transliterations into Basic Latin user IDs. International enterprises need to be sensitive to different language conventions when choosing different possible transliterations (see Figure 1). Figure 1. Example of Name Change From Unicode Into ASCII-Only User IDs
Source: Gartner (August 2012)
Page 5 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Apple's Mac OS X, a Unix OS, forms the short name borisstrugackij in the second example. Enterprises should consider whether to follow such system defaults or override them in favor of a more widely accepted transliteration. Furthermore, the firstname.lastname syntax often doesn't reflect cultural norms (see Note 8). Enterprises based wholly in one country will do what is locally accepted. International enterprises need to be sensitive to local conventions. All enterprises need to be sensitive to the expectations of users from different cultural backgrounds.
If You Choose an Arbitrary Format, Ensure That It Can Meet Persistency and Consistency Requirements Arbitrary formats are those that contain no readily discernable semantic data (see Note 9). Such user IDs are typically (but not necessarily) numeric.
Arbitrary User ID Strengths ■
It is unique.
■
It is generally persistent and neutral for employees (but note the limitations).
■
It satisfies a principle of data analysis: Any identifier should carry no information about the object it identifies.
Arbitrary User ID Limitations ■
It may not be easily memorable.
■
An enterprise using an employee number for employees must decide what contractors and other temporary staff will use. The enterprise must consider what happens when a temporary worker assumes a permanent position: Must the user be assigned a new user ID (which violates the persistency requirement)? Furthermore, can this format meet the neutrality requirement?
■
Because there's no semantic content to arbitrary user IDs, it is very easy to mistype them — for example, because an administrator has misheard a character (such as "5" for "9") or simply transposed consecutive characters — resulting in a different, but valid, user ID. This can have operational and security impacts — for example, the wrong user's password being reset or the wrong user being given certain entitlements. While a check digit (see Note 10) can be used to trap such errors, the systems being administered will likely not have native check-digit checking capability.
■
It doesn't conform to the World Electronic Messaging Association's (WEMA's) standard for email addresses (see Note 6).
5
Page 6 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Avoid Using a Structured Format Examples include "functional" formats (such as sysadm3 for a system administrator) and "hierarchical" formats (such as department code | section code | initials | distinguishing number yielding — for example, itadaa2). In general, the limitations of this format greatly outweigh the strengths, and Gartner deprecates its use.
Structured User ID Strengths ■
Unique and may be neutral (but note the limitations).
■
The user's function or position with the enterprise is clear (but note the limitations).
Structured User ID Limitations ■
Not persistent. It creates a huge administrative burden for frequently changing employee roles, and it requires bulk changes during reorganizations. It may be difficult to avoid user ID reuse.
■
It may not be easily memorable.
■
It may not be strictly neutral. The user's position or function with the enterprise is clear, so
3
6
6
entitlements or privileges may be implied, giving attackers a target.
Ensure That Your Chosen Format Extends Sensibly to Administrator and Shared Accounts Where users continually need full superuser privileges, Gartner recommends the use of a different 7
account from users' base accounts. In line with the consistency principle, user IDs for such accounts should adhere to the naming convention for other user accounts. Where name-based user IDs are used, this means that a user's administrator account should have the user ID that would be given to another user with the same name. For example, if Robert Howard were an administrator, then his base user ID might be robert.howard and his administrator user ID robert.e.howard. There are several kinds of shared account. The default superuser and administrator accounts — Administrator in Windows, root in Unix OSs and so on — necessarily have system-defined names. These are well-known targets for an attacker, and passwords should be managed accordingly.
7
Another kind of shared account encompasses administrator-defined accounts intended for use by designated users in special circumstances — for example, a "firecall" account used to resolve critical problems outside normal working hours. These shared accounts may have full superuser or other elevated privileges — and passwords should be managed as for default superuser accounts.
Page 7 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
However, enterprises have a free choice of user IDs for these accounts, and those should comply with the enterprise's naming convention. Where name-based user IDs are used, administrators should assign user IDs as if the shared accounts were personal accounts, and invent plausible names for them (a tactic often used for dummy email accounts used in marketing campaigns). However, well-known fictional character names (such as george.kaplan) should be avoided because they make obvious targets for a wily attacker. For additional personal administrator accounts and shared accounts, where an arbitrary format is used, the accounts should be treated like contractor accounts.
Relax Requirements for Customer User IDs to Improve Customers' User Experience Common practices for external users are to: ■
Assign users arbitrary user IDs.
■
Use users' email addresses (for example, robert.howard@example.net).
■
Allow the users to choose their own names (for example, fightingbob).
Assigning Arbitrary User IDs Arbitrary user IDs have the same strengths and limitations for external users as for internal users — however, especially for consumers, greater weight should be given to the limitation that such user 5
IDs may not be easily memorable. Thus, this format is likely best avoided for consumers.
Using Users' Email Addresses A third-party email address in any format is very attractive. It has all the strengths of a name-based user ID and is guaranteed to be unique. However, care must be taken to differentiate email-addressas-a-user-ID from email-address-as-an-email-address — the latter should be held as a separate data item. This allows a user to choose a different email address for correspondence at a later date, without having to create a new account or change a user ID. This is more appropriate for consumer websites than for client and partner extranets.
Allowing Users to Choose Their Own User IDs This option appears attractive: Such user IDs might be expected to be memorable. However, there may often be a problem choosing a unique user ID: It can be frustrating for a user to have to go through several variations before finding one that hasn't already been used. Some users might choose names that are offensive or otherwise inappropriate. However, user-chosen names are appropriate in forums and collaborative sites so as not to expose email addresses. Of course, an email address might still be used as a login user ID, with a different username being displayed to others.
Page 8 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Recommended Reading Some documents may not be available as part of your current Gartner subscription. "Magic Quadrant for User Administration/Provisioning" "MarketScope for Enterprise Single Sign-On" "Ten Best Practices for Managing Privileged Accounts" Evidence 1
See "Q&A: Consolidation of Active Directory Forests and Domains."
2
See "MarketScope for Enterprise Single Sign-On."
3
The author's first employer used a user ID format for IT users that meant the user ID had to change whenever the user moved between IT groups. Changing a user ID meant creating a new mainframe user profile, renaming often numerous personal datasets, optionally setting up new dataset profiles in the mainframe security system, and finally deleting the old user profile. All in all, this could take a help desk operator up to one hour, even with third-party administration tools in place. 4
The author has firsthand experience of such a problem, albeit in a somewhat different context. Because the submitting user ID was no longer valid, pipeline transactions were rejected, which had a direct financial impact on the business, in addition to the cost of resubmitting the transactions. 5
The author's online banking user ID has this format and he has no idea what it is; instead, he relies on secure "password wallet" software to "remember" it for him. 6
Although structured user IDs are less memorable, the author remembers all of his from his first employer: T391, T991 and T6AA. The first two characters were a group identifier. T6 indicated the group that included information security, which would have been useful information to a potential attacker. 7
See "Ten Best Practices for Managing Privileged Accounts."
Note 1 User Identifiers A user identifier (user ID or userID) is a character string used within a system to uniquely identify a user. Some systems call it a user name or username — which is somewhat confusing, since other systems use that label for the field holding the user's given name (or common name). Some systems use a single, unique user ID for each user. Others use different "login" and "internal" identifiers. Both of these should be unique (internal identifiers are automatically assigned by some systems and are guaranteed unique, at least within a domain), and one or both might be used to
Page 9 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
assign resource access, ownership and so on, depending on the system. The distinctions between these and the user's common name are sometimes blurred. Note 2 Persistent User IDs In addition to the goal discussed in the text, we note that some enterprises (especially media companies, in our experience) seek to use the same user ID for a user who leaves, but later returns to, the enterprise. This may reinforce usability benefits for the user (if he or she remembers his or her old user ID), and may provide better accountability through continuity with the user's previous work and online activity within the enterprise. However, there are two drawbacks: 1.
If the person is working in a completely different role, then he or she may regain entitlements that were previously assigned to him or her under his or her old role (similar to the user ID reuse concern).
2.
This approach requires good record keeping or a reliably consistent way of generating a user ID from other persistent attributes. To the latter end, one client we have spoken to was seeking to derive "arbitrary" user IDs using a hash function with the person's nationality (using ISO 3166-1 two-letter codes), U.S. Social Security number, U.K. National Insurance number or local equivalent, and date of birth as inputs (also see Note 9). Many enterprises might not see that such effort is justified.
Note 3 Basic Latin Character Set ■
Space
■
Special characters: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ / ] ^ _ ` { | } ~
■
Digits: 0 1 2 3 4 5 6 7 8 9
■
Uppercase letters: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
■
Lowercase letters: a b c d e f g h i j k l m n o p q r s t u v w x y z
See the Unicode document "C0 Controls and Basic Latin, Range: 0000-007F." Codes 0000-001F and 007F are control characters (such as "backspace" and "bell"). Not all of these are valid for user IDs. Most systems don't allow spaces in user IDs, and many allow only a restricted set of special characters. Some may not allow lowercase letters. Note 4 User IDs as Personal Data Strictly speaking, name-based user IDs are personal data because they clearly identify human individuals. As such, they are subject to many countries' privacy laws.
Page 10 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
However, Gartner is unaware of any case in which an organization was given a severe fine simply because it used name-based user IDs without paying attention to the law. Nevertheless, to prevent or respond to such situations, organizations should ensure that users who sign up for a user ID give consent to processing of personal data at the same time, usually when signing the terms and conditions of the service. Note 5 User IDs Don't Provide User Authentication Such phrases as "authentication by user ID and password" perpetuate an IAM myth. (Unfortunately, they still creep into Gartner research.) A user ID is just that: an identifier â&#x20AC;&#x201D; a unique name for the user account or profile (a digital identity). A user ID cannot practicably be treated as confidential. Within an enterprise, user IDs will be held in plain text in identity stores, will appear in reports and so on, so many people with legitimate access will be able to "discover" them. Therefore, the user's knowledge of his or her user ID is not privileged. It is not something that "only the user knows" (see "Defining Authentication Strength Is Not as Easy as 1, 2, 3; Update"), so it adds no real value to authentication (the corroboration of the claimed identity named by the user ID). Treating user IDs as if they are authentication data can confuse users. A user is told to keep his or her user IDs and passwords confidential; however, if he or she has a problem and contacts the help desk, then the help desk operator will ask him or her for his or her user ID. So how can the user respond without breaking that confidentiality? However, if a user observes that it is OK to reveal a supposedly confidential user ID, then he or she will be less inclined to treat his or her password with the proper respect for confidentiality. Gartner believes that one source of confusion stems from a commonly found security policy rule that states, "User IDs must not be shared." The real issue is not that the ID shouldn't be disclosed to another, but that a user should not let someone else log in with his or her user ID. To do that, the user would need to disclose his or her password as well. Note 6 Email-Type Formats The World Electronic Messaging Association (WEMA) developed an international naming convention for email usernames. However, this sets out only the basic formats and provides no guidance for more complex use cases. (In the examples following, the @example.com part is omitted for brevity.) The simplest conventional format is firstname.lastname â&#x20AC;&#x201D; for example, leigh.brackett for Leigh Brackett. Many enterprises use this convention, which is simple to remember and provides a unique name for all users in many enterprises. A "preferred first name" may be used in cases in which the person is better known by that name â&#x20AC;&#x201D; for example, bob.howard for Robert Ervin Howard.
Page 11 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
Where duplication occurs, a middle initial can be used in the second and subsequent instances of the name: firstname.middleinitial.lastname — for example, karl.e.wagner for Karl Edward Wagner. Further duplicates may be differentiated by a number. While email names may include hyphens and apostrophes, it is suggested that the "unpunctuated" username be defined as an alias. For example, Robert O'Brien would have the username robert.o'brien and the alias robert.obrien. In some implementations, the WEMA-standard format is used only as an alias, with the root name having a more compact form, such as aallan with the alias ant.allan. This approach allows for an easy change of alias, without having to re-create accounts and mailboxes. (It can also mask administrator error — for example, the author's compact name is aanthony because the administrator mistook "Allan" to be his forename and "Anthony" to be his surname.) Aliases might also be set up for other reasons; for example, ant.allen is set up to ensure correct delivery of email from senders who misspell the author's name. Of course, in a larger firm, or with a common name that is more common, such an alias might collide with the real name of another user. Note 7 Other Name-Based Formats Other styles of name-based formats include: ■
A WEMA email username style, but without delimiters — leighbrackett, bobhoward, karlewagner
■
Family name, one or more initials — brackettl, howardre, wagnerke — or with a delimiter — brackett.l, howard.re, wagner.ke
■
Initial of (first) given name, first seven (for example) letters of family name — lbracket (one "t"), rhoward, kwagner (this is common in z/OS and older Unix OSs, in which the user ID is limited to eight characters)
■
First name, initial letter of last name — leighb, roberth, karlw
■
Only initials — lb, reh, kew
■
Nicknames or informal names — leigh, bob, teddy
Even though these formats don't conform to the WEMA standard, they can be — and are — used for email addresses. Note 8 Names That Don't Conform to the firstname.lastname Syntax In Spain and in many countries with Spanish speakers, people use the father's and the mother's surnames (for example, Arturo Uslar Pietri, the son of Arturo Uslar Santamaría and Helena Pietri Paúl). Many possibilities arise: arturo.uslarpietri, arturo.uslar-pietri or simply asturo.uslar (using just the paternal surname). Similar variants are possible for truncated forms, such as uslarpietria or auslar. The situation is similar in Portugal and Brazil, except that the order of surnames is reversed. Page 12 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
In many Asian, African and some Eastern European countries, the family name is normally written before the given name(s). For example, a Mandarin speaker would say Xu (family name) Zhimo (given name), whereas English speakers would expect Zhimo Xu. Using a user ID like xu.zhimo might be acceptable in Mandarin-speaking countries, but it would be confusing in an international enterprise with English as its first language, in which case zhimo.xu might be preferred. Some Asian people choose to "Westernize" their names, in which case name-based user IDs will conform to the norms discussed in the text; for example, Lee Jun-fan becomes bruce.lee. Note 9 Arbitrary Formats This style of formats includes the following examples. ■
A sequential number, such as 63812, which may be a payroll or other HR-assigned employee number.
■
A string generated algorithmically from other identity data. A drawback of this approach is that there may be collisions resulting in nonunique user IDs. Among the advantages are that it is possible to regenerate the user ID for a given person (for example, if he or she returns to the enterprise) and that it avoids possible consistency and persistence limitations (also see Note 2).
Note 10 Check Digits A check digit is a form of redundancy check that can trap transcription errors, such as transposition errors (for example, "12" → "21") or phonetic errors (for example "60" → "16"). It consists of a single digit (or letter) computed from the other digits in the message. Familiar examples of codes incorporating a check digit include payment card account numbers, Universal Product Codes (UPCs) and International Standard Book Numbers (ISBNs; note that the check "digit" of a 10-digit ISBN can be "X," representing a value of 10). Other schemes can yield check "digits" that are always letters (such a scheme was used by the author's first employer, yielding an employee number and user ID of 63812E). Check digit schemes generally apply to numeric codes, but may be extended to address alphanumeric user IDs as well. The Wikipedia article "Check Digit" covers this topic fairly well.
Page 13 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu
This research note is restricted to the personal use of dquayle@hamilton.edu
GARTNER HEADQUARTERS Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 USA +1 203 964 0096 Regional Headquarters AUSTRALIA BRAZIL JAPAN UNITED KINGDOM
For a complete list of worldwide locations, visit http://www.gartner.com/technology/about.jsp
© 2012 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see “Guiding Principles on Independence and Objectivity.”
Page 14 of 14
Gartner, Inc. | G00238344 This research note is restricted to the personal use of dquayle@hamilton.edu