Copy Link
Add to Bookmark
Report

uninformed 07 03

eZine's profile picture
Published in 
Uninformed
 · 4 years ago

  

Mnemonic Password Formulas
I)ruid, C²ISSP
druid@caughq.org
http://druid.caughq.org
5/2007

Abstract

The current information technology landscape is cluttered with a large
number of information systems that each have their own individual
authentication schemes. Even with single sign-on and multi-system
authentication methods, systems within disparate management domains
are likely to be utilized by users of various levels of involvement
within the landscape as a whole. Due to this complexity and the
abundance of authentication requirements, many users are required to
manage numerous credentials across various systems. This has given rise to
many different insecurities relating to the selection and management of
passwords. This paper details a subset of issues facing users and managers of
authentication systems involving passwords, discusses current approaches to
mitigating those issues, and finally introduces a new method for password
management and recalls termed Mnemonic Password Formulas.

1) The Problem

1.1) Many Authentication Systems

The current information systems landscape is cluttered with individual
authentication systems. Even though many systems existing in a distinct
management domain utilize single sign-on as well as multi-system
authentication mechanisms, multiple systems within disparate management
domains are likely to be utilized regularly by users. Even users at the most
casual level of involvement in information systems can be expected to
interface with a half a dozen or more individual authentication systems within
a single day. On-line banking systems, corporate intranet web and database
systems, e-mail systems, and social networking web sites are a few of the many
systems that may require their own method of user authentication.

Due to the abundance of authentication systems, many end users are required to
manage the large numbers of passwords needed to authenticate with these
various systems. This issue has given rise to many common insecurities related
to selection and management of passwords.

In addition to the prevalence of insecurities in password selection and
management, advances in authentication and cryptography assemblages have
instigated a shift in attack methodologies against authentication systems.
While recent headway in computing power have made shorter passwords such as
six characters or less (regardless of the complexity of their content)
vulnerable to cracking by brute force[4], common attack methodologies are moving
away from cryptanalytic and brute force methods against the password storage
or authentication system in favor of intelligent guessing of passwords such
as. This intelligent guessing might involved optimized dictionary attacks and
user context guesses, attacks against other credentials required by the
authentication system such as key-cards and password token devices, and
attacks against the interaction between the user and the systems themselves.

Due to all of the aforementioned factors, the user's password is commonly the
weakest link in any given authentication system.

1.2) Managing Multiple Passwords

Two of the largest problems with password authentication relate directly to
the user and how the user manages passwords. First, when users are not allowed
to write down their passwords, they generally will choose easy to remember
passwords which are usually much easier to crack than complex passwords. In
addition to choosing weaker passwords, users are more likely to re-use
passwords across multiple authentication systems.

Users have an inevitably difficult time memorizing assigned random
passwords[4] and passwords of a mandated higher level of complexity chosen
themselves. When allowed, they may write down their passwords in an insecure
location such as a post-it note stuck to their computer monitor or on a note
pad in their desk. Alternatively, they may store passwords securely, such as
a password encrypted file within a PDA. However, a user could just as easily
lose access to the password store. The user may forget the password to the
encrypted file, or the PDA could be lost or stolen. In this situation, the end
result would require some administrative interaction in the form of issuing a
password reset.

1.3) Poor Password Selection

When left to their own devices, users generally do not choose complex
passwords[4] and tend to choose easy to crack dictionary words because they
are easy to remember. Occasionally an attempt will be made at complexity by
concatenating two words together or adding a number. In many cases, the word
or words chosen will also be related to, or within the context of, the user
themselves. This context might include things like a pet's name, phone
number, or a birth date.

These types of passwords require much less effort to crack than a brute-force
trial of the entire range of potential passwords. By using an optimized
dictionary attack method, common words and phrases are tried first which
usually leads to success. Due to the high success rate of this method, most
modern attacks on authentication systems target guessing the password first
before attempting to brute-force the password or launch an in-depth attack on
the authentication system itself.

1.4) Failing Stupid

When a user cannot remember their password, likely because they have too many
passwords to remember or the password was forced to be too complex for them to
remember, many authentication systems provide a mechanism that the author has
termed ``failing stupid.''

When the user ``fails stupid,'' they are asked a reminder question which is
usually extremely easy for them to answer. If answered correctly, users are
presented with an option to either reset their password, have it e-mailed to
them, or perform some other password recovery method. When this type of
recovery method is available, it effectively reduces the security of the
authentication system from the strength of the password to the strength of a
simple question. The answer to this question might even be obtainable through
public information.

1.4.1) Case Study: Paris Hilton Screwed by Dog

A well publicized user context attack[2] was recently executed against the
Hollywood celebrity Paris Hilton in which her cellular phone was compromised.
The account password recovery question that she selected for use with her
cellular provider's web site was "What is your favorite pet's name?" Many fans
can most likely recollect from memory the answer to this question, not to
mention fan web sites, message boards, and tabloids that likely have this
information available to anyone that wishes to gather it. The attacker simply
"failed stupid" and reset Hilton's online account password which then allowed
access to her cellular device and its data.

2) Existing Approaches

2.1) Write Down Passwords

During the AusCERT 2005 information security conference, Jesper Johansson,
Senior Program Manager for Security Policy at Microsoft, suggested[1] reversing
decades of information security best practice of not writing down passwords.
He claimed that the method of password security wherein users are prohibited
from writing down passwords is absolutely wrong. Instead, he advocated
allowing users to write down their passwords. The reasoning behind his claim
is an attempt at solving one of the problems mentioned previously: when users
are not allowed to write down their passwords they tend to choose easy to
remember (and therefore easy to crack) passwords. Johansson believes that
allowing users to write down their passwords will result in more complex
passwords being used.

While Mr. Johansson correctly identifies some of the problems of password
security, his approach to solving these conundrums is not only short-sighted,
but also noncomprehensive. His solution solves users having to remember
multiple complex passwords, but lso creates the aforementioned insecure
scenarios regarding written passwords which are inherently physically less
secure and prone to require administrative reset due to loss.

2.2) Mnemonic Passwords

A mnemonic password is a password that is easily recalled by utilizing a
memory trick such as constructing passwords from the first letters of easily
remembered phrases, poems, or song lyrics. An example includes using the
first letters of each word in a phrase, such as: "Jack and Jill went up the
hill," which results in the password "JaJwuth". For mnemonic passwords to be
useful, the phrase must be easy for the user to remember.

Previous research has shown[4] that passwords built from phrase recollection like
the example above yield passwords with complexity akin to true random
character distribution. Mnemonic passwords share a weakness with regular
passwords in that users may reuse them across multiple authentication systems.
Such passwords are also commonly created using well known selections of text
from famous literature or music lyrics. Password cracking dictionaries have
been developed that contain many of these common mnemonics.

2.3) More Secure Mnemonic Passwords

More Secure Mnemonic Passwords[1] (MSMPs), are passwords that are derived from
simple passwords which the user will remember with ease, however, they use
mnemonic substitutions to give the password a more complex quality.
``Leet-speaking'' a password is a simple example of this technique. For
example, converting the passwords ``beerbash'' and ``catwoman'' into
leet-speak would result in the passwords ``b33rb4sh'' and ``c@w0m4n'',
respectively.

A unique problem of MSMPs is that not all passwords can be easily transformed
which limits either the choice of available passwords or the password's
seemingly complex quality. MSMPs also rely on permutations of an underlying
dictionary words or sets of words which are easy to remember. Various cracking
dictionaries have been developed to attack specific methods of permutations
such as the "leet-speak" method mentioned above. As with mnemonic passwords,
these passwords might be reused across multiple authentication systems.

2.4) Pass Phrases

Pass phrases[3] are essentially what is used as the root of a mnemonic password.
They are easier to remember and much longer which results in a password being
much more resilient to attack by brute force. Pass phrases tend to be much
more complex due to the use of upper and lower case characters, white-space
characters, as well as special characters like punctuation and numbers.

However, pass phrases have their own sets of problems. Many authentication
systems do not support lengthy authentication tokens, thus resulting in pass
phrases that are not consistently usable. Like the aforementioned methods,
the same pass phrase may be reused across multiple authentication systems.

3) Mnemonic Password Formulas

3.1) Definition

A Mnemonic Password Formula, or MPF, is a memory technique utilizing a
predefined, memorized formula to construct a password on the fly from various
context information that the user has available.

3.2) Properties

Given a well designed MPF, the resultant password should have the following
properties:

- A seemingly random string of characters
- Long and very complex, therefore difficult to crack via brute force
- Easy to reconstruct by a user with knowledge of only the formula,
themselves, and the target authentication system
- Unique for each user, class of access, and authenticating system

3.3) Formula Design

3.3.1) Syntax

For the purposes of this paper, the following formula syntax will be used:

- <X> : An element, where <X> is meant to be entirely replaced by something known as described by X.
- | : When used within an element's angle brackets (< and >), represents an OR value choice.
- All other characters are literal.

3.3.2) A Simple MPF

The following simple formula should be sufficient to demonstrate the MPF
concept. Given the authenticating user and the corresponding authenticating
system, a formula like that shown in the following example could be
constructed. This example formula contains two elements: the user and
the target system identified either by hostname or the most significant octet
of the IP address.

<user>!<hostname|lastoctet>

The above MPF would yield such passwords as:

- "druid!neo" for user druid at system neo.jpl.nasa.gov
- "intropy!intropy" for user intropy at system intropy.net
- "thegnome!nmrc" for user thegnome at system nmrc.org
- "druid!33" for user druid at system 10.0.0.33

This simple MPF schema creates fairly long, easy to remember, passwords that
contain a special character. However, it does not yield very complex
passwords. A diligent attacker may include the target user and hostname as
some of the first combinations of dictionary words used in a brute force
attack against the password. Due to the fact that only the hostname or last
octet of the IP address is used as a component of the schema, passwords may
not be unique per system. If the same user has an account on two different web
servers, both with hostname "www", or two different servers with the same last
address octet value within two different sub-nets, the resultant passwords
will be identical. Finally, the passwords yielded are variable in length and
may not comply with a given systems password length policies.

3.3.3) A More Complex MPF

By modifying the simple MPF above, complexity can be improved. Given the
authenticating user and the authenticating system, an MPF with the following
components can be constructed:

<u>!<h|n>.<d,d,...|n,n,...>

The more complex MPF contains three elements: <u> represents the first letter
of the username, <h|n> represents the first letter of the hostname or first
number of the first address octet, and <d,d,...|n,n,...> represents the first
letters of the remaining domain name parts or first numbers of the remaining
address octets, concatenated together. This MPF also contains another special
character in addition to the exclamation mark, the period between the second
and third element.

The above MPF would yield such passwords as:

- "d!n.jng" for user druid at system neo.jpl.nasa.gov
- "i!i.n" for user intropy at system intropy.net
- "t!n.o" for user thegnome at system nmrc.org
- "d!1.003" for user druid at system 10.0.0.33

The modified MPF contains two special characters which yields more complex
passwords, however, the passwords are still variable length and may not comply
with the authenticating system's password length policies. The example MPF is
also increasing in complexity and may not be easily remembered.

3.3.4) Design Goals

The ideal MPF should meet as many of the following design goals as possible:

- Contain enough elements and literals to always yield a minimum password
length
- Contain enough complex elements and literals such as capital letters and
special characters to yield a complex password
- Elements must be unique enough to yield a unique password per
authenticating system
- Must be easily remembered by the user

3.3.5) Layered Mnemonics

Due to the fact that MPFs can become fairly complex while attempting to meet
the first three design goals listed above, a second layer of mnemonic
properties can be applied to the MPF. The MPF, by definition, is a mnemonic
technique due to its property of allowing the user to reconstruct the password
for any given system by remembering only the MPF and having contextual
knowledge of themselves and the system. Other mnemonic techniques can be
applied to help remember the MPF itself. This second layer of mnemonics may
also be tailored to the user of the MPF.

Given the authenticating user and the authenticating system, an adequately
complex, long, and easy to remember MPF like the following could be
constructed:

<u>@<h|n>.<d|n>;

This MPF contains three elements: <u> represents the first letter of the
username, <h|n> represents the first letter of the hostname or first number of
the first address octet, and <d|n> represents the last letter of the domain
name suffix or last number of the last address octet. The modified MPF also
contains a third special character in addition to the exclamation mark and
period: the semicolon after the final element.

The above MPF would yield such passwords as:

- "d@n.v;" for user druid at system neo.jpl.nasa.gov
- "i@i.t;" for user intropy at system intropy.net
- "t@n.g;" for user thegnome at system nmrc.org
- "d@1.3;" for user druid at 10.0.0.33

Unlike the previously discussed MPFs, the one mentioned above employs a
secondary mnemonic technique by reading in a natural way and is thus easier
for a user to remember. The MPF can be read and remembered as ``user at host
dot domain,'' which is equatable to the structural format of an email address.
Also, a secondary mnemonic technique specific to the user of this MPF was used
by appending the literal semicolon character. This MPF was designed by a C
programmer who would naturally remember to terminate her passwords with
semicolons.

3.3.6) Advanced Elements

MPFs can be made even more complex through use of various advanced elements.
Unlike simple elements which are meant to be replaced entirely by some static
value like a username, first letter of a username, or some part of the
hostname, advanced elements such as repeating elements, variable elements, and
rotating or incrementing elements can be used to vastly improve the MPF's
output complexity. Note, however, that overuse of these types of elements may
cause the MPF to not meet design goal number four by making the MPF too
difficult for the user to remember.

- Repeating Elements

MPFs may yield longer passwords by repeating simple elements. For
example, an element such as the first letter of the hostname may be
used twice:

<u>@<h|n><h|n>.<d>;

Such repeating elements are not required to be sequential, and
therefore may be inserted at any point within the MPF.

- Variable Elements

MPFs can yield more complex passwords by including variable elements. For
example, the MPF designer can prepend the characters "p:" or "b:" to the
beginning of the to include an element indicating whether the target system
is a personal or business.

<p|b>:<u>@<h|n>.<d|n>;

To further expand this example, consider a user who performs system
administration work for multiple entities. In this case the variable
element being prepended could be the first letter of the system's managing
entity:

<x>:<u>@<hi|n>.<d|n>;

<x> could be replaced by ``p'' for a personal system, ``E'' for a system
within Exxon-Mobil's management domain, or ``A'' for a system managed by
the Austin Hackers Association. Most of the elements used thus far are
relatively simple variable elements that derive their value from other
known contextual information such as user or system name. The contrast is
that elements are capricious only in how their value changes when the MPF
is applied to different systems. Variable elements change values in
relation to the context of the class of access or due to a number of other
factors outside the basic ``user/system'' context.


To illustrate this concept, the use of the same MPF for a super-user and an
unprivileged user account on the same system may result in passwords that
only differ slightly. Including a variable element can help to mitigate
this similarity. Prepending the characters ``0:'' or ``1:'' to the
resultant password to indicate super-user versus unprivileged user access.
Respectively, by inclusion of an additional variable element in the MPF
will result in the password's increased complexity as well as indicating
class of access:

Variable elements are not required to prepend the beginning of the formula
as with the examples above; they can be easily appended or inserted
anywhere within the MPF.

- Rotating and Incrementing Elements

Rotating and incrementing elements can be included to assist in managing
password changes required to conform to password rotation policies. A
rotating element is one which rotates through a predefined list of values
such as "apple", "orange", "banana", etc. An incrementing element such as
the one represented below by is derived from an open-ended linear sequence
of values incremented through such as "1", "2", "3" or "one", "two",
"three". When a password rotation policy dictates that a password must be
changed, rotate or increment the appropriate elements:

<u>@<h|n>.<d|n>;<\#>

The above MPF results in passwords like "d@c.g:1", "d@c.g:2", "d@c.g:3",
etc. To further illustrate this principle, consider the following MPF:

<u>@<h|n>.<d|n>;<fruit>

The above MPF, when used with the predefined list of fruit values mentioned
above, yields passwords like "d@c.g:apple", "d@c.g:orange", "d@c.g:banana",
etc.

The only additional pieces of information that the user must remember other
than the MPF itself is the predefined list of values in the rotating
element, and the current value of the rotating or incrementing element.

In the case of rotating elements this list of values may potentially be
written down for easy reference without compromising the security of the
password itself. Lists may further be obscured by utilizing certain
values, like a grocery list or a list of company employees and telephone
extensions that may already be posted within the user's environment. In
the case of incrementing elements, knowledge of the current value should be
all that is required to determine the next value.

3.4) Enterprise Considerations

Large organizations could use MPFs assigned to specific users to facilitate
dual-access to a user's accounts across the enterprise. If the enterprise's
Security Operations group assigns unique MPFs to it's users, Security Officers
would then be able to access the user's accounts without intrusively modifying
the user's account or password. This type of management could be used for
account access when user is absent or indisposed, shared account access among
multiple staff members or within an operational group, or even surveillance of
a suspected user by the Security Operations group.

3.5) Weaknesses

3.5.1) The ``Skeleton Key'' Effect

The most significant weakness of passwords generated by MPFs is that when the
formula becomes compromised, all passwords to systems for which the user is
using the respective MPF schema are potentially compromised. This situation is
no worse than a user simply using the same password on all systems. In fact,
it is significantly better due to the resultant passwords being individually
unique. When using a password generated by an MPF, the password should be
unique per system and ideally appear to be a random string of characters. In
order to compromise the formula, an attacker would likely have to crack a
significant number of system's passwords which were generated by the formula
before being able to identify the correlation between them.

3.5.2) Complexity Through Password Policy

A second weakness of MPF generated passwords is that without rotating or
incrementing elements, they are not very resilient to password expiration or
rotation policies. There exists a trade-off between increased password
security via expiring passwords and MPF complexity. However, the trade-off is
either to have both, or neither. The more secure option is to use both,
however, this practice increases the complexity of the MPF potentially causing
the it to not meet design goal number four.

6) Conclusion

MPFs can effectively mitigate many of the existing risks of complex password
selection and management by users. However, their complexity and mnemonic
properties must be managed very carefully in order to achieve a comfortable
level of password security while also maintaining memorability. Users may
reintroduce many of the problems MPFs intend to solve when they become too
complex for users to easily remember.

References

[1] Bugaj, Stephan Vladimir. More Secure Mnemonic-Passwords: User-Friendly Passwords for Real Humans
http://www.cs.uno.edu/Resources/FAQ/faq4.html

[2] Kotadia, Munir. Microsoft Security Guru: Jot Down Your Passwords
http://news.com.com/Microsoft+security+guru+Jot+down+your+passwords/2100-7355_3-5716590.html

[3] McWilliams, Brian. How Paris Got Hacked?
http://www.macdevcenter.com/pub/a/mac/2005/01/01/paris.html

[4] Williams, Randall T. The Passphrase FAQ
http://www.iusmentis.com/security/passphrasefaq/

[5] Jeff Jianxin Yan and Alan F. Blackwell and Ross J. Anderson and Alasdair Grant. Password Memorability and Security: Empirical Results
http://doi.ieeecomputersociety.org/10.1109/MSP.2004.81

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT