Re: change password API

[Jim Langston <jlangston@xxxxxxxxxxxxxxxx>]

My 111 001 example was just that, an example.  Although I do
have source code in C for a lot of encryption programs and
have used them for a PC, I didn't feel like going into the
algorithms used for one, as they are not that easy to grasp.

The only flaw with the random seed sent by the AS/400 to the
PC is that any packet sniffer looking for password packets
can also catch this seed, then catch the password packet and
have the same info as the PC.  Although it is a bit more secure.

The best I think we could hope for would be for the PC to
use the same encryption as the AS/400 for the password, although
this has been shown to be breakable, and pass that to the
AS/400 and just have the AS/400 store the encrypted string
to the user profile without every even attempting to decrypt
it.

I don't think you can put too much security on a 10 character
maximum password.

Regards,

Jim Langston

Kurt Goolsbee wrote:

> 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)

+---
| 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
+---