|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.