mailing list archives
Re: Network Solutions Crypt-PW Authentication-Scheme vulnerability
From: Len Sassaman <rabbi () quickie net>
Date: Fri, 8 Jun 2001 12:48:46 -0700 (PDT)
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 8 Jun 2001, Peter Ajamian wrote:
Do not use the Crypt-PW authentication-scheme. Instead use the MAIL_FROM
or PGP scheme instead.
Neither of these are very good options either. The problems with MAIL-FROM
are the obvious flaws you find in any MAIL-FROM scheme. The PGP scheme is
worth discussing, however.
When the owner of a handle account attempts to associate a PGP key with
his account, he is asked to do so by providing the "PGP KEY ID". However,
the input box only allows eight characters. v4 PGP keys (key generated
with PGP versions 5.x and greater, as well as GnuPG) have key-ids that are
64 bits long, rather than 32 bits. This is because of the well-known fact
that it is trivial to generate keys with a specific 32 bit key-id
(allowing duplication.) Search the archives for the DEADBEEF attack.
One can deduce that the NSI PGP-auth scheme works as follows:
- - User uploads his key to NSI's server.
- - User associates his 32 bit key-id with his handle and specifies
- - User signs future modification requests with the key he specified.
- - The signature is verified, and the 32 bit key-id is compared to the one
specified in the handle.
- - If the signature is good and the IDs match, the modification is made.
The problem with this is that an attacker could create a key with the same
32 bit key-ID, and upload it to the NSI server. I have to guess on the
system's behavior now, since I have not actually tried this.
In the best-case scenario, NSI's key server would reject a key with a
duplicate 32 bit key-id. This will cause problems for legitimate users
with 32 bit key-id collisions.
In the more dangerous of possibilities, both keys would reside on the
server, and an attacker would be able to forge modification requests by
signing message with a key bearing the same key-id as the legitimate
contact. Or the attacker's key would replace the legitimate key, giving
the attacker control of the account while stripping the legitimate user of
This entire problem can be corrected by avoiding the use of key-ids
altogether, and requiring the user to input the key fingerprint instead.
I reported this to NSI in 1999.
Security Architect |
Technology Consultant | "Let be be finale of seem."
http://sion.quickie.net | --Wallace Stevens
-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.
-----END PGP SIGNATURE-----