Re: SAFE Forum--some comments
At 08:44 PM 7/2/96 -0700, Martin Minow wrote:
It's not quite that bad. Here are a few (more or less strong) crypto products you might not know you have:
1. Every Macintosh made since at least 1988 has a secure authentication client module in the AppleShare Chooser dialog. When you use it to connect to a remote server, it notes that the user information is "two-way scrambled." (The server sends a random number challenge that the client uses to encrypt the username and password. The encrypted information is sent to the server.) All Macintosh systems running System 7 or later have the corresponding server software. What is interesting about this is that the encryption is completely invisible to the user.
I hear this as the server sends out a key which the client uses to encrypt the username/password. This algorithm makes less sense than the one I thought I heard at the SAFE forum on Monday which was: (1) The server sends out a challenge/salt (different each time) (2) The client uses a secure hash to compute hash(salt||password) and returns the username and the hash. (3) The server computes hash(salt||password) and compares the hashes. Given that there is still some interest in algorithms and protocols on this list, can you describe what is really happening? Thanks - Bill ------------------------------------------------------------------------- Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting (408)356-8506 | regarded as a never-ending | 16345 Englewood Ave. frantz@netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA
-----BEGIN PGP SIGNED MESSAGE----- On Wed, 3 Jul 1996, Bill Frantz wrote:
I hear this as the server sends out a key which the client uses to encrypt the username/password. This algorithm makes less sense than the one I thought I heard at the SAFE forum on Monday which was:
True. That algorithm is completely useless.
(1) The server sends out a challenge/salt (different each time) (2) The client uses a secure hash to compute hash(salt||password) and returns the username and the hash. (3) The server computes hash(salt||password) and compares the hashes.
Given that there is still some interest in algorithms and protocols on this list, can you describe what is really happening?
That one makes more sense. If the salt is completely random, then an attacker will not be able to use a replay attack. Since the password is hashed, there is no way to find it out given the output. This does require the server to maintain a list of cleartext passwords, but that's not any worse then Kerberos which requires a KDC store everyone's DES key. - -- Mark =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= markm@voicenet.com | finger -l for PGP key 0xe3bf2169 http://www.voicenet.com/~markm/ | d61734f2800486ae6f79bfeb70f95348 "Freedom is the freedom to say that two plus two make four. If that is granted, all else follows." --George Orwell, _1984_ -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBMeAGBrZc+sv5siulAQEzGwQAp6rB1eJ5DIzn9Zs5LlEDFu3K7XFRcl7S /9MQ5ykCmvgnOqgN1Pud/KYLsZuY2x+G5W68EF0kTVfwarS2ZCT2wYVhH5cMaEQs 2YfxtoK9opB73GiMP3OJUTZlNPnwCCe/y/iHJN7HqAv/YLi+gdIc9rGXtfegE/eY sASbbC7C1oY= =NJSu -----END PGP SIGNATURE-----
participants (2)
-
frantz＠netcom.com -
Mark M.