home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 3 Comm / 03-Comm.zip / md5.zip / MD5.TXT < prev    next >
Text File  |  1995-01-13  |  11KB  |  268 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.                                         VMODEM
  12.                             Shared Secret Logon Technique
  13.  
  14.  
  15.  
  16.                         Copyright (c) 1995 by Raymond L. Gwinn
  17.                                  12469 Cavalier Drive
  18.                               Woodbridge, Virginia 22192
  19.                                  All Rights Reserved
  20.  
  21.                                    January 13, 1995
  22.  
  23.  
  24.                                 CompuServe: 71154,575
  25.                                InterNet: ray@gwinn.com
  26.                                 Voice: 1-703-494-4673
  27.                                  FAX: 1-703-494-0595
  28.                          BBS: 1-703-494-0098 or 199.248.240.2
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.                                      INTRODUCTION
  40.  
  41.           This document is intended for developers.
  42.  
  43.           I exchanged some Email messages with Steve Sneed, the author of
  44.           the CompuServe Navigator, OzCIS.  I proudly told him how I am
  45.           using Vmodem's outgoing Telnet ability and his program (OzCIS) to
  46.           log onto CompuServe (at compuserve.com).  Steve made a comment
  47.           that really got my attention.  He said "do you realize the your
  48.           CIS password is being sent in the clear?".  The reader should
  49.           note that CompuServe users can purchase many expensive items on
  50.           CompuServe.  Steve also mentioned he had heard that sniffers have
  51.           been used to obtain the users CompuServe ID and password.  I
  52.           immediately logged onto CompuServe (via modem) and changed my
  53.           password.
  54.  
  55.           This exchange made me realize the same problem existed for BBSes. 
  56.           Since I am pushing Vmodem as the easiest way on earth to get a
  57.           BBS onto Internet, I felt I should try to do something about
  58.           passwords being sent in the clear.  I started looking for how
  59.           this problem has been solved on the Internet.  I came across RFP
  60.           1725 (POP3 Server) which in turn lead me to RFP 1321.  RFP 1725
  61.           describes a "Shared Secret" method of logging onto a remote
  62.           server using an algorithm described in RFC 1321.  The "Shared
  63.           Secret" is simply another name for a (hopefully long) password.
  64.  
  65.           This "Shared Secret" method can work for BBSes, but it requires
  66.           the cooperation of the BBS and the client (terminal) end.  When
  67.           implemented, the users password is never sent in the clear.  In
  68.           fact, the only string that is ever the same is the user's name.
  69.  
  70.           This document is intended to establish a procedure that may be
  71.           implemented at the BBS end and hopefully in terminal programs. 
  72.           Vmodem supports the "Shared Secret" log on documented here.  Thus
  73.           any terminal program connecting to a BBS using Vmodem has the
  74.           "Shared Secret" ability.
  75.  
  76.           The method described here can implemented on a BBS in a manner
  77.           that is completely compatible with current BBS implementations. 
  78.           BBS developers are encouraged to implement the methods described
  79.           here.  If the "Shared Secret" ability  is coded into BBS
  80.           software, terminal program authors will follow.
  81.  
  82.           The source of a highly optimized MD5 algorithm (in Assembly
  83.           Language) is included to make the implementation easier.  This
  84.           module (MD5.ASM) is hereby dedicated to the public domain with
  85.           the requirement that the author (Ray Gwinn) be given credit as
  86.           the author.
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.           ii
  95.  
  96.                                   TABLE OF CONTENTS
  97.  
  98.           OVERVIEW  . . . . . . . . . . . . . . . . . . . . . . . . . .   1
  99.  
  100.           THE UNIQUE STRING . . . . . . . . . . . . . . . . . . . . . .   2
  101.  
  102.           THE CLIENT'S RESPONSE . . . . . . . . . . . . . . . . . . . .   3
  103.  
  104.           . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.                                                                           1
  113.  
  114.  
  115.                                        OVERVIEW
  116.  
  117.           RFC 1725 and RFC 1321 are included with this document.  The
  118.           reader should read these documents, starting with RFC 1725, to
  119.           gain an overview of previous implementations of the Shared Secret
  120.           method of passing a password.  The whole idea is that the only
  121.           string that is ever the same is the users name.
  122.  
  123.           Basically, the Shared Secret method works this way.  When a
  124.           connection is detected by the host (or BBS) it should send a
  125.           unique string of characters recognizable by the client
  126.           (terminal).  The client appends the Shared Secret string to the
  127.           received unique string and runs the resulting string through the
  128.           MD5 algorithm.  The 128 bit result of the MD5 processing, called
  129.           a digest, is then converted to ascii hex and send back to the
  130.           host.  Note that the digest is always the same length.
  131.  
  132.           The BBS program also combines the unique string (that it sent to
  133.           the client) with the Shared Secret string and runs it through the
  134.           MD5 algorithm.  The host then compares the locally generated
  135.           digest to that received from the client.  If the strings
  136.           (digests) match, then both ends of the connection know and are
  137.           using the same Shared Secret (password) and the same string is
  138.           never sent across the network.
  139.  
  140.           Note that examples of strings and valid results for the MD5
  141.           algorithm are given the RFC 1321.
  142.  
  143.           The critical thing for the BBS is to insure that the unique
  144.           string is truly unique.  This is not really too hard to do, a
  145.           method is described later.  For the user (client), the longer the
  146.           password (Shared Secret) the more secure the transaction will be.
  147.  
  148.           A bit of digression to hopefully make things a little more
  149.           understandable.  In the Vmodem implementation the Shared Secret
  150.           (password) is specified in the dialing string, in quotes
  151.           following the Internet address (and port number, if any).  For
  152.           example:
  153.  
  154.                ATDT 199.240.248.20 "james cricket"
  155.  
  156.           In the above, james cricket is the Shared Secret (password).  In
  157.           the Vmodem implementation, the specification of the Shared Secret
  158.           in the dialing string will cause Vmodem to look for the unique
  159.           string sequence from the host (BBS) and respond with the digest
  160.           generated by the MD5 algorithm.  The response will only occur
  161.           once.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.           2
  170.  
  171.                                   THE UNIQUE STRING
  172.  
  173.  
  174.           The unique string must be automatically generated by the host
  175.           (BBS) computer.  The unique string is sent to the client enclosed
  176.           in angle-brackets.  For example:
  177.  
  178.           <this could be a unique string, but not a very good choice>
  179.  
  180.           If you reviewed RFC 1725 you will see that it specifies using the
  181.           computers clock to generate the unique string, seems good to me. 
  182.           Note also that RFC 1725 specifies the inclusion of the process ID
  183.           to make sure the string is unique for all programs running on the
  184.           same computer.  The BBS port number could also be used instead of
  185.           the process ID.  I suggest the following format of the unique
  186.           string:
  187.  
  188.           <nn.yyyymmddhhuusscc-other>
  189.  
  190.           Where:
  191.                nn = port number or process ID.
  192.                yyyy = year.
  193.                mm = month.
  194.                dd = day.
  195.                hh = hour of the day
  196.                uu = minutes into the hour
  197.                ss = seconds into the minute
  198.                cc = hundredth of a second
  199.                other = any other printable ascii you may want to add.
  200.  
  201.           Note that the unique string cannot include angle-brackets.
  202.  
  203.           The maximum length of the unique string is 80 characters,
  204.           including the angle-brackets.  The angle-brackets are also
  205.           included in the MD5 algorithm processing.
  206.  
  207.           The unique string must be sent very early in the connection. 
  208.           Ideally, it would be the first thing sent by the host (BBS). 
  209.           However, other handshaking (like FidoNet mail) may make it
  210.           difficult to send the unique string as the very first thing.  In
  211.           the Vmodem implementation, the testing for the unique string
  212.           stops with the detection of the unique string or after 1024
  213.           characters have been received from the host (BBS).
  214.  
  215.           The characters in the unique string are not suppressed.  That is,
  216.           they are passed on to the application by the client.  This is
  217.           done to prevent loss of data during a false detection.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.                                                                           3
  226.  
  227.                                 THE CLIENT'S RESPONSE
  228.  
  229.  
  230.           Upon receiving the unique string sequence, the client uses the
  231.           MD5 algorithm to generate the digest.  The digest is really a 128
  232.           bit binary number.  The digest is sent to the host (BBS) as an
  233.           ascii hex string in a format similar to the unique sequence. 
  234.           That is, it is enclosed in angle-brackets.  Examples of digest
  235.           strings being sent to the host are:
  236.  
  237.           <57EDF4A22BE3C955AC49DA2E2107B67A>
  238.  
  239.           or
  240.  
  241.           <57edf4a22be3c955ac49da2e2107b67a>
  242.  
  243.           Note that the above two strings represent the same digest.  The
  244.           BBS should convert the string to upper case before comparing. 
  245.           Also note that the returned digest is always the same length, 34
  246.           characters counting the angle-brackets.
  247.  
  248.           The digest is sent to the host (BBS) low byte first and is sent
  249.           immediately upon receiving the trailing angle-bracket ">" of the
  250.           unique string from the host (BBS).  The digest is sent a one
  251.           continuous string with no pauses between characters.
  252.  
  253.           After the BBS sends the unique string, which is in effect an
  254.           invitation for the client to send the digest, the BBS will start
  255.           monitoring for the "<" sequence and then begins saving the
  256.           characters in the string.  The BBS should accumulate the string,
  257.           but continue processing the characters normally in case it is a
  258.           false start.  Noting that the digest is all ascii hex character,
  259.           is a fixed length, and can be timed, false detection of a
  260.           complete digest string is next to impossible.
  261.  
  262.           Upon receiving a valid digest sequence from the remote, the BBS
  263.           save the string until the user has entered their name.  Once the
  264.           BBS has the user name, a digest can be generated locally and
  265.           compared the to one already received.  If the received digest is
  266.           a match, the BBS continues without asking the user for their
  267.           password.  BINGO!  No password sent in the clear.
  268.