Browse Prior Art Database

Logon/Logoff Scheme for Dos Database Requester Which Works In Both Real And Protect Mode

IP.com Disclosure Number: IPCOM000120868D
Original Publication Date: 1991-Jun-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 4 page(s) / 177K

Publishing Venue

IBM

Related People

Sirkin, MJ: AUTHOR

Abstract

The LOGON and LOGOFF programs shipped with OS/2* EE 1.2 for DOS Database requester do not work in the protected mode of the 80x86 Intel processors. This is a problem as much of the new software (including Windows 3.0) uses protect mode to extend past the 640K DOS barrier. CURRENT SCHEME

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 35% of the total text.

Logon/Logoff Scheme for Dos Database Requester Which Works In Both
Real And Protect Mode

      The LOGON and LOGOFF programs shipped with OS/2* EE 1.2
for DOS Database requester do not work in the protected mode of the
80x86 Intel processors.  This is a problem as much of the new
software (including Windows 3.0) uses protect mode to extend past the
640K DOS barrier.
CURRENT SCHEME

      There are several problems with the current LOGON/LOGOFF scheme
for the DOS Database Requester:
 1) LOGON is a Terminate and Stay Resident (TSR) Program which
accesses low memory directly.  It will not work in protect mode.
This means that it cannot be run on the same machine at the same time
as a DOS extender (which allows up to 16 Megabytes of addressable
memory for DOS).  These extenders are becoming very common (Windows
3.0 and DOS 16/M are two examples).  DOS Database Requester needs to
work with these environments.
 2) The current UserID and Password for LOGON/LOGOFF is stored in RAM
as simple strings.  A program (or user) can look at the proper place
in memory and discover the UserID and Password of another user.  This
is a security problem.
NEW LOGON/LOGOFF SCHEME

      The new LOGON/LOGOFF scheme is actually much simpler than the
current one.  It takes care of the two problems listed above, and
provides several new features for free which we may choose to use
later.

      The core of the scheme is that UserIDs and Passwords are stored
in a disk file, not in RAM memory.  The file is stored in the
DBDRQLIB directory which we must have for DOS Database Requester.  It
is named XXXXXXXX.@#$, where XXXXXXXX is the workstation name for the
DOS requester workstation.  This naming scheme provides for:
 1) If we are using redirected drives (LAN requester/server) each
workstation has its own UserID and Password file.
 2) The file name contains DOS "illegal characters". This means that
common command-line commands (such as type) do not work on the file.

      In addition, the file will be hidden (have the hidden attribute
turned on), and will have both the UserID and Password encrypted with
a simple encryption algorithm (with different encryption used for the
UserID and Password).  All of this makes the UserIDs and Passwords
much more secure than in the current scheme.

      Using a file to store UserIDs and Passwords means that UserIDs
and Passwords are accessed in the following way:
 1) LOGON - Queries the user for UserID and Password. Creates the
file, encrypts the data and writes it to the file.
      2) LOGOFF - Deletes the file of UserID and Password.
      3) Start Using Database - Checks to see if there is a file. If
not, returns an error.  If there is, it unencrypts the UserID and
Password, and uses them.
NETBIOS INTERFACE

      Consider the following scenario:  A system administrator uses
DOS Database requester on a workstation. Without logging off, he
turns off the machine.  Another employ...