motivation.html
283c4e73f0a2e21b06359dbbd909f6e7eab96c3e10f860a8e303dd557e1cf22b<html>
<head>
<title>SRP: Reasons to Upgrade</title>
</head>
<body fgcolor="#000000" bgcolor="#FFFFFF">
<h1>Motivation for Using SRP</h1>
Now that we have this new password-authentication protocol,
you might be wondering what the big deal is.
After all, new security-related protocols and algorithms seem to be
invented all the time.
What is so revolutionary about SRP that distiguishes it from
the rest of the pack?
This page will attempt to answer that question while at the same
time advancing concrete proposals regarding possible immediate
uses for SRP.
<p>
<hr>
<h2>The Status Quo is Unacceptable</h2>
It is generally accepted wisdom among the security community that
no one really cares about security until something bad happens to
them.
Whether the loss is tangible (destruction of critical data or financial
losses) or intangible (downtime or embarrassment),
it almost always happens because existing systems were thought
to be "good enough" to withstand at least casual attack.
Recent years have seen a dramatic improvement in the resources
available to potential intruders, along with an increase in the
value of data and systems on the Internet.
Not surprisingly, incidents involving weak password security are
becoming increasinly common, causing more damage with each new
breakin.
For example, incidents at <a href="http://daily.stanford.org/Daily96-97/4-9-97/NEWS/NEWemail09.html">Stanford University</a>
and <a href="http://the-tech.mit.edu/V115/N14/sniff.14n.html">MIT</a>
show that even the best-run facilities are vulnerable.
<a href="http://www.cert.org/">CERT</a>, in its 1994 annual report,
noted the threat of network-based attack in a document entitled,
<a href="http://www.cert.org/pub/annual-reports/cert_rpt_94.html">Ongoing
Network Monitoring Attacks</a>.
Jeff Schiller of MIT believes that "just about every open network in a medium-to-large institution has sniffers on it."
<p>
In an environment where the Internet is increasingly open to
eavesdroppers, weak password systems are security incidents
waiting to happen.
Even choosing a "good" password will not protect it
from a packet sniffer.
And although Kerberos is starting to gain acceptance as a secure
distributed authentication system,
the initial ticket-granting protocols in both
Kerberos V4 and V5 (without pre-authentication) have been
broken, permitting anyone with network access to the authentication
server to run a password-cracker against the master password list.
<p>
The intention of this section is not to scare anyone, but instead
to point out the seriousness of existing security weaknesses and
to dispel the notion that it isn't worth the trouble to upgrade to
a stronger system.
Indeed, the cost of <i>not</i> upgrading will undoubtedly be far
higher than any amount of time installing the SRP distribution,
especially since it requires practically no change or other
inconvenience for users.
Dr. John D. Howard, in a paper analyzing Internet security incidents,
recommended that: "Internet suppliers should provide protocols and
software that encrypt these data at the source, or provide alternative
systems that do not require passwords to be sent in the clear across the
Internet."
<p>
<hr>
<h2>The Unix Password File Format</h2>
For over two decades, the Unix operating system has used the same
format for storing passwords.
A file named <code>/etc/passwd</code> held a password entry for each
user on the system that looked like:
<pre>
tjw:BUbc2vSLYq9Ls:501:100:Tom Wu:/home/tjw:/bin/ksh
</pre>
The second field contains a base-64 representation of a hash of
the plaintext password.
The advantage of storing passwords in this form instead of as
plaintext is that the password file can be made world-readable
without leaking password information to other users on the system.
<p>
Unix traditionally uses a DES-based hashing function to generate
the password field.
Although 56-bit DES is starting to show signs of age (it is believed
that routine brute-forcing of DES keys will become practical within
five to ten years),
the most glaring problem with this password authentication scheme is
that it does not handle authentication over a network very well.
Ironically, the most secure authentication protocol using the
standard Unix hash is simply to send the plaintext directly over
the network and have the server perform the hash and comparision.
This is the only way in which the password file can be used without
making its entries plaintext-equivalent to the password.
<p>
Sending a password across a public network unencrypted has been
shown time and time again to be a major, easily-exploited security
deficiency.
It is surprisingly easy to set up both general-purpose computers
and specialized hardware to monitor a TCP/IP network and
"sniff" packets belonging to someone else's login session.
This is a common method of attack, and one that has been
<a href="http://daily.stanford.org/Daily96-97/4-9-97/NEWS/NEWemail09.html">carried out</a>
repeatedly and effectively here at Stanford University.
Both the Distributed Computing Environment and various departmental
computer clusters have been targeted by intruders who proceed to
install "sniffers" in strategic locations and manage to capture
hundreds of passwords as they are sent in the clear, including some
super-user passwords and "Kerberized" login passwords.
Of course, the original Unix system security designers can't really be
blamed for this sorry state of affairs, since they did not design the
original system with networking in mind.
<h3>Temporary Fixes and Workarounds</h3>
Clearly, standard Unix password file authentication is unacceptable for
a networked environment, especially as the amount and value of information
exchanged over the Internet rises.
In response to this threat, a number of security-related products
have been developed in the last decade or so in an attempt to improve
the security of password authentication.
Since no simple, secure two-party password-only authentication systems
existed when these products were designed, they worked around the problem
in one of two ways:
Either they used a centralized authentication server that was assumed
to be secure, thus moving the burden from the individual workstation
to some centralized authority,
or they negotiated some form of host-based secure channel before
allowing standard Unix authentication to take place.
Kerberos is an example of the former, while <code>ssh</code> is an
example of the latter.
These products are discussed in a separate page.
<p>
Although these products have been around for many years,
they have not managed to gain widespread use and acceptance
outside the computer security community.
A recent sampling of network traffic in and around Stanford
showed that the vast majority (over 90%) of login sessions,
even those occurring between two points on campus, used neither
secure authentication nor session encryption.
This despite the fact that both Kerberos and <code>ssh</code>
are supported here.
<p>
Why have users been so reluctant to adopt strong security measures
to protect themselves?
Simply stated, secure products are a pain to use.
Kerberos, <code>ssh</code>, and products like them present users
with a myriad of confusing new
<a href="history.html#ssh">commands and options</a> for them to
memorize.
Users are constantly reminded that they are using a "security
product" and invariably need to change some of their behavior
to use such software effectively, since they are based on technology
that does not mesh transparently with the familiar password-only
authentication model that most users are accustomed to.
This translates into users who either balk at the introduction
of secure software or who revert to using conventional, insecure
software after a short while.
The end result is that only the "power users" who are security-conscious
end up using the secure software, which is exactly what has happened
at Stanford.
Many users think, "I don't need to worry about security; I don't
have anything that valuable in my account anyway."
In fact, that is often true, but even one user logging in insecurely
is enough for a password-sniffing attacker to gain access to your system
to compromise other, less forgiving users.
<p>
It has been said that main cost of security is not necessarily the
cost of the secure software itself, but the cost of re-educating all
the users and teaching them how to use the new software.
Users like security, but they have in general proven very unwilling
to sacrifice convenience to obtain it.
Systems like Kerberos and <code>ssh</code> are wonderful utilities
and programs that offer good security for those willing to put up with
them.
The next generation of secure systems will take things a step further,
integrating security into applications like remote logins and file
transfers at a level completely transparent to the user.
Secure connections will gradually become the lowest common denominator,
and network security will be as ubiquitous as networking itself is today.
<p>
<hr>
<h2>A Better Way to Store Passwords</h2>
It should be clear to the casual reader by now that the Unix password
file format needs updating if we want to place the system on the network
and be able to sleep at night.
It should also be clear that we want to avoid encumbering users with
extraneous issues like key generation, private/public key files,
or certificates if we expect our system to be used by any significant
population of users.
<p>
If we model the algorithm used to turn plaintext passwords into
hashes as a function <code>f()</code> that accepts the password as its
argument,
we can analyze the password file format in mathematical terms.
The DES-based hash used by Unix, when represented as a function,
does not have a useful mathematical structure.
In other words, the mapping between the input and output, while
deterministic, does not possess any interesting mathematical
properties that might allow it to participate in a secure
authentication protocol without being plaintext-equivalent to the
password.
Its only property of note is that it is difficult to invert.
<p>
Instead of using a "dead" one-way function for <code>f()</code>,
our proposal is to substitute a more mathematically interesting,
but secure, function for <code>f()</code>.
The new <code>f()</code> is defined as:
<pre>
f(p) = g ** H(s, p) (mod N)
</pre>
where <code>H()</code> is a one-way hash, <code>s</code> is a random salt, and
<code>g</code> and <code>N</code> are system-wide parameters.
Astute readers will note that the output of <code>f()</code> corresponds
exactly to the value <code>v</code> in the SRP protocol,
while the term <code>H(s, p)</code> is merely <code>x</code>.
Although <code>x</code> is plaintext-equivalent to the password,
the final computation in <code>f()</code> performs an exponentiation
in a prime field to calculate <code>v</code>.
Taking <code>v</code> and inverting the exponentiation to obtain
<code>x</code> is known as the "Discrete Logarithm Problem" and is
believed to be very time-consuming.
As long as this holds true, <code>v</code> is not plaintext-equivalent
to the password.
<p>
To store the values <code>v</code> and <code>s</code> in a file,
we convert them to base 64 ASCII.
The password database itself is stored in a file named
<code>/etc/tpasswd</code>.
Its entries resemble the following:
<pre>
tjw:C7.3L96NpXtYOOtS0MjVCBo9vMOOxgj3uVp.3i.vZDurfI2Il4r5aNP2YmO2QAkF:g8uXvjuoWitxTpITPiItL:1
</pre>
The first field contains the username, the second field contains the
encoded value of <code>v</code>, the third field contains the encoded
salt, and the last field indicates which set of parameters to use for
<code>N</code> and <code>g</code>.
The list of parameters is stored in a separate file,
<code>/etc/tpasswd.conf</code>,
whose entries look like:
<pre>
1:kCiZAR85BB8zgUQpiIhPUWGLsDcnJD64K6kxXvQrxJLPM/hD3sMkeNlsFuqxvCv/:IaJGJcoVxLVU7hY1OKD6ODEq1YdPogtv74FZdYUvlyM1r5B1LNT2CiARrJOelgLu
</pre>
The first field corresponds to the index field in the password database,
while the second and third fields hold <code>N</code> and <code>g</code>
respectively.
The <code>/etc/tpasswd</code> file does not actually replace the old
<code>/etc/passwd</code> file entirely.
It simply holds the password information for each user, and it can
be made either world-readable or readable only to privileged system
code.
It is the analogue of the shadow password file <code>/etc/shadow</code>
found on most newer Unix systems.
<p>
In a standalone environment, this new password file format isn't all that
different from what we had before.
We've used a different one-way hash function to generate the hashed
passwords, and passwords can still be set and verified by running the
plaintext through the hash function.
The new exponentiating hash function also has the nice feature that
the field size can be increased to make either a brute-force discrete-log
attack or a dictionary attack on the password file more difficult.
Still, the new format is fundamentally similar to the standard Unix
password file format.
<p>
The big benefit comes when you add networking to the picture.
The password database now contains all the information a server
needs to negotiate the server side of the SRP protocol.
The careful choice of the "live" hash function <code>f()</code>
enables the server to construct a challenge that can only be
answered correctly by a client who knows the actual password.
Since the SRP protocol also exchanges session keys while
authenticating, the client and server can also encrypt their
communications once authentication succeeds.
The end result is a password file format that can survive
being compromised (stolen) by an intruder yet can be used
to verify passwords securely over an untrusted network.
<h3>Securing system services</h3>
With this new password file format in place, it is now possible for
networked services like Telnet (remote login) and FTP (file transfer)
to perform secure, password-only authentication over the network.
Since this authentication is password-only, it can be done in a
manner completely transparent to the user.
Had SRP been developed a few years earlier, the ongoing effort to
incorporate it into existing applications might not be necessary today.
<p>
Prototype implementations of SRP-enhanced Telnet and FTP have been
written and deployed in our local research group.
More detailed information on each of these utilities will be provided
on a separate page.
Recent traffic analysis within our group's local network indicates
that over half the session traffic is now encrypted, and we
expect that figure to increase as SRP-enabled systems and
utilities become more widely used around Stanford and in the
outside world.
<p>
SRP authentication doesn't stop with just Telnet and FTP, either.
The protocol can be used to secure any service with a password.
POP (mail), IMAP, NNTP (news), and HTTP (Web) are just some examples
of protocols that can benefit from secure authentication and encryption
services.
Services like Kerberos, NIS, and NIS+ can also be upgraded to support
the SRP-aware password system, thus enabling interoperability with
existing SRP implementations.
SRP's greatest contribution to the field of secure networking is its
ability to negotiate both strong authentication and encryption with
nothing more than a password from the user.
The user can go about his business, knowing that his communications
are being encrypted and that his password is safe from prying eyes,
but not having to do anything special to make it happen.
<p>
<hr>
<a href="index.html">Back</a>
</body>
</html>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed