RE: change password API

Gee you guys are taking a simple concept and complicating the hell out of
it.

The AS/400 encrypts the userid with a "massaged" password and stores it.
When you log on from to a green screen the password you enter is "massaged"
and used to encrypt the userid you entered.  This value is compared to the
stored encrypted value.  If they match you are in.  

Now lets say that you know what the stored encrypted value is and that you
know what the userid is.  You can't use it to log in.  You have to enter the
plain text password to gain access.  Unless you know the "massaging"
algorithm you can't perpetrate a dictionary attack and if you did a brute
force attack it would only yield the "massaged" password.

Now, the way the Signon Server works is that the workstation first
calculates the encrypted password the same way that the AS/400 does.  The
AS/400 and the workstation exchange a random number with each other.  This
random number, the userid and the encrypted password are used in a bunch of
other encryptions that yield a value that is sent to the AS/400.   The
AS/400 gets the stored encrypted value and does the same calculations and
compares that with what the workstation sent.  The value that is actually
sent over the net is highly encrypted and is VERY secure to brute force
attacks.  

In either case (network or terminal) the encrypted value is of no value
unless you know the algorithm used to process the password prior to
encrypting the userid.  Even then it requires a brute force attack.  The
keyspace for the encrypted value sent over the network has an available
keyspace contains 7.86432e+15 values.  At 1,000,000/second it will take over
91000 days to decrypt.  

Since the encrypted values are never decrypted DES could easily be changed
to any other encryption or message digest algorithm (SHA-1 or MD5).

PKI isn't necessary for securely exchanging this data.  

Here is what I would do to securely pass userid and password between 2
machines.  Go out to the net and search out a implementation of the
Diffie-Hellman key negotiation algorithm.  Use it to agree on a session key
between the 2 machines.  Use the session key to encrypt the userid and
password with DES.  Send the encrypted data to the other machine and it can
use the session key to decrypt it.  There is freely available code for
C/C++/Java for these algorithms.

The idea of replacing odd characters with a 1 and even ones with a 0 is an
encryption scheme and not a message digest.  It is ridiculously weak and
does not decrypt to the same value (not lossless).  A message digest would
for each unique input produce a unique output.  Using the 1/odd 0/even
approach AAACCC would give 111111.  CCCDDD would give 111111.  A message
digest would produce a different value for each string.  On decryption each
ciphertext would decrypt to AAAAAA which isn't desirable.  For the purpose
of password validation AAACCC and CCCDDD would be equivalent. (Duh) 

  

-----Original Message-----
From: Tim McCarthy [mailto:TimM@softwarejungle.com]
Sent: Thursday, December 30, 1999 11:56 AM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: change password API


Oh boy...
        >Tim, you do not need to be able to recover one on the
        >other end.
        The original question was regarding changing passwords. You can
do this without recovering the new password? Hmm.

        >Consider.  I encrypt the password on the PC
        >using the same encryption IBM uses in OS/400 (if I knew
        >what it was).
        DES

        >I then send the result of this, the encrypted
        >passed, to the AS/400 through the network.
        Why bother encrypting it? All you've done is swap one token for
another. Any hacker can now use this token to log on as you. Without
some form of challenge/response or PKCS you're compromised.

        >Lets take a very simple encryption scheme.  You give me any
word,
        >and for every letter in it I will put a 1 or a 0.  A 1 if it is
        >an odd number of the alphabet, a 0 if it's even.

        >so CAT = 111
        >DOG = 001
        >etc...
        Now you've delved into the ridiculous. What you're mixing up is
encryption v/s a message digest or signature. Unless the message digest
algorithm is know by both sides it's useless, and given that signatures
of known length/short strings aren't that hard to reverse.    

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---