









                                        VMODEM
                            Shared Secret Logon Technique



                        Copyright (c) 1995 by Raymond L. Gwinn
                                 12469 Cavalier Drive
                              Woodbridge, Virginia 22192
                                 All Rights Reserved

                                   January 13, 1995


                                CompuServe: 71154,575
                               InterNet: ray@gwinn.com
                                Voice: 1-703-494-4673
                                 FAX: 1-703-494-0595
                         BBS: 1-703-494-0098 or 199.248.240.2










                                     INTRODUCTION

          This document is intended for developers.

          I exchanged some Email messages with Steve Sneed, the author of
          the CompuServe Navigator, OzCIS.  I proudly told him how I am
          using Vmodem's outgoing Telnet ability and his program (OzCIS) to
          log onto CompuServe (at compuserve.com).  Steve made a comment
          that really got my attention.  He said "do you realize the your
          CIS password is being sent in the clear?".  The reader should
          note that CompuServe users can purchase many expensive items on
          CompuServe.  Steve also mentioned he had heard that sniffers have
          been used to obtain the users CompuServe ID and password.  I
          immediately logged onto CompuServe (via modem) and changed my
          password.

          This exchange made me realize the same problem existed for BBSes. 
          Since I am pushing Vmodem as the easiest way on earth to get a
          BBS onto Internet, I felt I should try to do something about
          passwords being sent in the clear.  I started looking for how
          this problem has been solved on the Internet.  I came across RFP
          1725 (POP3 Server) which in turn lead me to RFP 1321.  RFP 1725
          describes a "Shared Secret" method of logging onto a remote
          server using an algorithm described in RFC 1321.  The "Shared
          Secret" is simply another name for a (hopefully long) password.

          This "Shared Secret" method can work for BBSes, but it requires
          the cooperation of the BBS and the client (terminal) end.  When
          implemented, the users password is never sent in the clear.  In
          fact, the only string that is ever the same is the user's name.

          This document is intended to establish a procedure that may be
          implemented at the BBS end and hopefully in terminal programs. 
          Vmodem supports the "Shared Secret" log on documented here.  Thus
          any terminal program connecting to a BBS using Vmodem has the
          "Shared Secret" ability.

          The method described here can implemented on a BBS in a manner
          that is completely compatible with current BBS implementations. 
          BBS developers are encouraged to implement the methods described
          here.  If the "Shared Secret" ability  is coded into BBS
          software, terminal program authors will follow.

          The source of a highly optimized MD5 algorithm (in Assembly
          Language) is included to make the implementation easier.  This
          module (MD5.ASM) is hereby dedicated to the public domain with
          the requirement that the author (Ray Gwinn) be given credit as
          the author.







          ii

                                  TABLE OF CONTENTS

          OVERVIEW  . . . . . . . . . . . . . . . . . . . . . . . . . .   1

          THE UNIQUE STRING . . . . . . . . . . . . . . . . . . . . . .   2

          THE CLIENT'S RESPONSE . . . . . . . . . . . . . . . . . . . .   3

          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3







                                                                          1


                                       OVERVIEW

          RFC 1725 and RFC 1321 are included with this document.  The
          reader should read these documents, starting with RFC 1725, to
          gain an overview of previous implementations of the Shared Secret
          method of passing a password.  The whole idea is that the only
          string that is ever the same is the users name.

          Basically, the Shared Secret method works this way.  When a
          connection is detected by the host (or BBS) it should send a
          unique string of characters recognizable by the client
          (terminal).  The client appends the Shared Secret string to the
          received unique string and runs the resulting string through the
          MD5 algorithm.  The 128 bit result of the MD5 processing, called
          a digest, is then converted to ascii hex and send back to the
          host.  Note that the digest is always the same length.

          The BBS program also combines the unique string (that it sent to
          the client) with the Shared Secret string and runs it through the
          MD5 algorithm.  The host then compares the locally generated
          digest to that received from the client.  If the strings
          (digests) match, then both ends of the connection know and are
          using the same Shared Secret (password) and the same string is
          never sent across the network.

          Note that examples of strings and valid results for the MD5
          algorithm are given the RFC 1321.

          The critical thing for the BBS is to insure that the unique
          string is truly unique.  This is not really too hard to do, a
          method is described later.  For the user (client), the longer the
          password (Shared Secret) the more secure the transaction will be.

          A bit of digression to hopefully make things a little more
          understandable.  In the Vmodem implementation the Shared Secret
          (password) is specified in the dialing string, in quotes
          following the Internet address (and port number, if any).  For
          example:

               ATDT 199.240.248.20 "james cricket"

          In the above, james cricket is the Shared Secret (password).  In
          the Vmodem implementation, the specification of the Shared Secret
          in the dialing string will cause Vmodem to look for the unique
          string sequence from the host (BBS) and respond with the digest
          generated by the MD5 algorithm.  The response will only occur
          once.







          2

                                  THE UNIQUE STRING


          The unique string must be automatically generated by the host
          (BBS) computer.  The unique string is sent to the client enclosed
          in angle-brackets.  For example:

          <this could be a unique string, but not a very good choice>

          If you reviewed RFC 1725 you will see that it specifies using the
          computers clock to generate the unique string, seems good to me. 
          Note also that RFC 1725 specifies the inclusion of the process ID
          to make sure the string is unique for all programs running on the
          same computer.  The BBS port number could also be used instead of
          the process ID.  I suggest the following format of the unique
          string:

          <nn.yyyymmddhhuusscc-other>

          Where:
               nn = port number or process ID.
               yyyy = year.
               mm = month.
               dd = day.
               hh = hour of the day
               uu = minutes into the hour
               ss = seconds into the minute
               cc = hundredth of a second
               other = any other printable ascii you may want to add.

          Note that the unique string cannot include angle-brackets.

          The maximum length of the unique string is 80 characters,
          including the angle-brackets.  The angle-brackets are also
          included in the MD5 algorithm processing.

          The unique string must be sent very early in the connection. 
          Ideally, it would be the first thing sent by the host (BBS). 
          However, other handshaking (like FidoNet mail) may make it
          difficult to send the unique string as the very first thing.  In
          the Vmodem implementation, the testing for the unique string
          stops with the detection of the unique string or after 1024
          characters have been received from the host (BBS).

          The characters in the unique string are not suppressed.  That is,
          they are passed on to the application by the client.  This is
          done to prevent loss of data during a false detection.







                                                                          3

                                THE CLIENT'S RESPONSE


          Upon receiving the unique string sequence, the client uses the
          MD5 algorithm to generate the digest.  The digest is really a 128
          bit binary number.  The digest is sent to the host (BBS) as an
          ascii hex string in a format similar to the unique sequence. 
          That is, it is enclosed in angle-brackets.  Examples of digest
          strings being sent to the host are:

          <57EDF4A22BE3C955AC49DA2E2107B67A>

          or

          <57edf4a22be3c955ac49da2e2107b67a>

          Note that the above two strings represent the same digest.  The
          BBS should convert the string to upper case before comparing. 
          Also note that the returned digest is always the same length, 34
          characters counting the angle-brackets.

          The digest is sent to the host (BBS) low byte first and is sent
          immediately upon receiving the trailing angle-bracket ">" of the
          unique string from the host (BBS).  The digest is sent a one
          continuous string with no pauses between characters.

          After the BBS sends the unique string, which is in effect an
          invitation for the client to send the digest, the BBS will start
          monitoring for the "<" sequence and then begins saving the
          characters in the string.  The BBS should accumulate the string,
          but continue processing the characters normally in case it is a
          false start.  Noting that the digest is all ascii hex character,
          is a fixed length, and can be timed, false detection of a
          complete digest string is next to impossible.

          Upon receiving a valid digest sequence from the remote, the BBS
          save the string until the user has entered their name.  Once the
          BBS has the user name, a digest can be generated locally and
          compared the to one already received.  If the received digest is
          a match, the BBS continues without asking the user for their
          password.  BINGO!  No password sent in the clear.
