Twenty Year Anniversary


Posted Dec 21, 1999


tags | encryption
MD5 | 4f26c7375eb6817b2bc9837ddb94e0fd


Change Mirror Download
<title>SRP: History of Password Authentication</title>
<body fgcolor="#000000" bgcolor="#FFFFFF">
<h1>Protocols of the Past</h1>
Strong password authentication has remained a hard problem in
cryptography despite advances in both symmetric (secret-key) and
asymmetric (public-key) cryptosystems.
<a href="">Additional background
information</a> on the nature of the difficulty of this problem is available.
The history of password authentication is littered with examples of
weak, easily-compromised systems, most of which are still in use today.
Here are the major categories of password authentication systems,
along with some example implementations illustrating their flaws:
<a name="weak"><h2>Weak Authentication</h2></a>
In general, "weak" authentication systems are characterized by
protocols that either leak the password directly over the
network or that leak sufficient information while performing
authentication to allow intruders to deduce or guess at the
<h3>Cleartext Passwords</h3>
The most obvious (and insecure) method of authentication is to store
the password in a database somewhere on the server.
During authentication, the client sends the password directly to the
server, and the server compares this with the stored value.
The security problems with this are obvious.
<h3>Hashed Passwords</h3>
Several decades ago, it was discovered that a server did not have to
store a user's password in cleartext form anywhere on the system
in order to perform password authentication.
Instead, the user's password could be run through a one-way <i>hash</i>
function, which would convert it into a random-looking sequence of
Such a function would be difficult to invert: given a password, it would
be easy to compute its hash, but given a hash, it would be computationally
infeasible to compute the password itself.
Authentication consisted merely of running the hash function on a typed
password and comparing it to the stored value.
The password database itself could be made world-readable without fear
of an intruder being able to lift passwords from it.
This system is still being used to this day, primarily for UNIX systems.
Although the 56-bit DES cipher on which it is based is starting to show
signs of age, the most glaring problem with this system in a networked
environment is that it does not address the issue of how to transmit
the password securely to the server for verification.
Indeed, the vast majority of implementations today still send the password
completely in the clear.
To avoid revealing passwords directly over an untrusted network,
<i>challenge-response</i> systems were developed.
At their simplest, the server sends the user some sort of <i>challenge</i>,
which would typically be some sort of random string.
The user would then compute a <i>response</i>, usually some function
based on both the challenge and the password.
This way, even if an intruder captures a valid challenge-response pair,
it will not help him gain access to the system since future challenges
are likely to be different and thus require different responses.
Unfortunately, challenge-response systems as a whole suffer from
deficiencies that make them insecure for modern networked applications.
The <a href="issues.html">issues page</a> discusses three major
problems with these systems and gives some examples of how they
have been and will continue to be exploited.
There are a number of such protocols used in active systems today,
and nearly all of them suffer from the insecurities described on the
issues page.
<a name="stronger"><h2>Stronger Authentication</h2></a>
Although strong encryption has been with us for decades, the development
of truly strong two-party (direct) authentication protocols really only
started in 1990 with the publication of the EKE family of algorithms.
EKE describes a family of protocols that combine symmetric and
public-key cryptosystems to perform password authentication.
For the first time, protocols existed that could withstand dictionary
attacks and possibly provide forward secrecy without involving trusted
third parties or manual key-management.
EKE is discussed in <a href="references.html#BM92">[BM92]</a>.
<h3>DH-EKE, SPEKE</h3>
EKE can be implemented with different public-key systems, and each
implementation has its set of quirks and idiosyncracies depending on
the exact algorithms used.
The most well-known and secure forms of EKE involve exponential
key exchange, similar to the <i>Diffie-Hellman</i> key-exchange
DH-EKE, for example, is EKE implemented using Diffie-Hellman itself.
The only significant difference is that the messages exchanged under
DH are now encrypted with the shared password.
Likewise, <a href="">SPEKE</a>
is based on Diffie-Hellman, but the password is now
used to influence the selection of the generator parameter in the
session-key generation function.
Technical details on all these protocols can be found at the
<a href="">Integrity Science</a> Web site.
These protocols have been subjected to some analysis, which indicates
that they resist dictionary attacks and provide forward secrecy.
However, the EKE family does not address the problem of plaintext-
equivalence of passwords.
They operate on the assumption that the server knows the same password
as the client.
DH-EKE and SPEKE are described in
<a href="references.html#Jablon96">[Jablon96]</a>.
The designers of EKE proposed a modification of the EKE protocol
that they called "Augmented EKE", in which the server could store
a quantity that was not plaintext-equivalent to the user's password.
This protocol is the only other protocol known to this day that
resists to dictionary attacks and does not have a plaintext-equivalent
password database.
Unfortunately, A-EKE sacrifices forward secrecy in its attempt to
avoid plaintext-equivalence.
A-EKE is proposed in <a href="references.html#BM94">[BM94]</a>.
A vulnerability in A-EKE is covered in
<a href="references.html#STW95">[STW95]</a>.
<a name="inconvenient"><h2>Inconvenient Authentication</h2></a>
In the absence of strong, simple password authentication technology,
system designers in the 1980s turned to other techniques to ensure
password security.
Most of these systems were, of course, not entirely password-based,
and often required extra overhead on the part of users, administrators,
or both to operate smoothly.
<h3>One-time passwords</h3>
A <i>one-time password</i> is exactly that - a password that is valid only
once and then discarded.
The most famous of these systems is known as S/Key.
The security advantages of one-time passwords is clear: An intercepted
password is useless to an attacker.
The inconvenience of one-time passwords is equally clear: Users need
to manage either a list of passwords or client software that computes
the one-time passwords on the fly.
And then there is the problem of regenerating a list of passwords
every time the user runs out.
Kerberos is a distributed authentication service developed at
MIT Project Athena.
Authentication is granted through <i>tickets</i>, which are
generated by a central authentication server.
Kerberos maintains a set of secret keys, one for every entity to
be authenticated within a particular <i>realm</i>, or domain.
This means that the server must be kept extremely secure, as it
represents a single point of failure for the entire system and
all the nodes and users within it.
Kerberos requires a great deal of administrative overhead, and it
changes the fundamental authentication model for users, sacrificing
some transparency in the process.
It also does not handle authentication very well when the user and
host are in different administrative domains.
Kerberos is suited mostly for centrally-managed clustered networks,
where the same authentication service is needed for all users.
It is not well-suited for smaller clusters or standalone systems,
where the overhead of a separate, secure authentication server is
In 1989, the Kerberos 4 TGT protocol was broken and a dictionary
attack found against it by Bellovin and Merritt; see
<a href="references.html#BM89">[BM89]</a> for details.
In a sense, this places Kerberos in the uncomfortable position
of being both inconvenient and weak.
Kerberos V5, however, addresses this problem nicely by allowing
for preauthentication methods like SRP, which eliminate the
threat of dictionary attack.
<a name="ssh"><h3>Ssh</h3></a>
Recently, a new product called
<a href=""><b>ssh</b></a>
has made the rounds of the security community.
Ssh is basically an implementation of RSA written by non-US citizens,
so the version distributed from Finland escapes US export restrictions.
It offers host-based security and session encryption based on
host-generated RSA keys.
It is designed to replace the Berkeley 'r' commands like
<code>rsh</code> that use a system of trusted hosts.
Unlike Kerberos, ssh does not require a centralized authentication
server to operate.
Like Kerberos, however, ssh requires that users and administrators
learn new sets of commands and new key management techniques to
keep systems secure.
To negotiate a partially secure file transfer, for example, a
user must remember to do:
$ ssh -L remote-server
<i>(in a different window)</i>
$ ftp myhost 1234
instead of the customary
$ ftp remote-server
Although ssh also provides the <code>scp</code> command for copying
files between systems, it does not provide the same functionality
as full-blown FTP.
Nevertheless, the SRP distribution will be adding an <code>scp</code>-style
authenticated file copy command.
Ssh consists of a large amount of code, most of which runs either as root
or set-uid root.
This makes auditing and verification of code difficult and time-
SRP, by contrast, uses a non-setuid client, and the server code is a
small patch to existing daemons.
By emphasizing design simplicity, SRP minimizes the potential damage
that bugs can cause, and programs can be tested more easily for conformance
to specifications.
The final "issue" with ssh, though, is that it runs afoul of export
regulations and RSA patent issues once inside the US.
While it is legal for a US citizen to download ssh, he could not
write his own SSH-enabled application and re-export it from a Web site.
In addition, a commercial user would require a BSAFE license from
To be fair, export regulations also prevent the exportation of
SRP with strong encryption.
However, SRP can perform secure authentication without the benefit
of any encryption, while SSH needs encryption to protect the cleartext
passwords over the network.
This was, in fact, one of the original design parameters of SRP;
it was intended to offer as much security as possible in a configuration
that coexisted with export regulations.
In equation form:

(SRP Telnet/FTP) - (strong encryption) = protected password + clear session<br>
(SSH/SCP) - (strong encryption) = cleartext password + clear session = rlogin/rcp
It is somewhat disturbing to note that while the overall issue of
system security is beginning to attract an increased amount of
attention, most existing systems still do not employ strong forms
of authentication.
Since strong authentication had not been invented when the
Telnet protocol and other remote access standards were being
decided, the world was saddled with a huge installed base of
weak authentication mechanisms and all the security problems
associated with them.
Only the truly security-conscious users and administrators
have so far taken it upon themselves to install one of the forms of
"inconvenient but safe" authentication mechanisms in the form of
add-on software.
It is hoped that authentication systems like SRP will be able to
bring true security to a greater number of users and move beyond
the obsolete protocols of the past.
<a href="index.html">Back</a>


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

December 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    11 Files
  • 2
    Dec 2nd
    1 Files
  • 3
    Dec 3rd
    18 Files
  • 4
    Dec 4th
    40 Files
  • 5
    Dec 5th
    16 Files
  • 6
    Dec 6th
    50 Files
  • 7
    Dec 7th
    12 Files
  • 8
    Dec 8th
    1 Files
  • 9
    Dec 9th
    1 Files
  • 10
    Dec 10th
    15 Files
  • 11
    Dec 11th
    20 Files
  • 12
    Dec 12th
    0 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2018 Packet Storm. All rights reserved.

Security Services
Hosting By