Re: Network Solutions Crypt-PW Authentication-Scheme vulnerability

From: Len Sassaman (rabbiat_private)
Date: Fri Jun 08 2001 - 12:48:46 PDT

  • Next message: Peter W: "Re: Network Solutions Crypt-PW Authentication-Scheme vulnerability"

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    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
    PGP-auth.
    
    - - 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
    any control.
    
    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.
    
    __
    
    Len Sassaman
    
    Security Architect            |
    Technology Consultant         |  "Let be be finale of seem."
                                  |
    http://sion.quickie.net       |           --Wallace Stevens
    
    
    
    
    
    
    
    
    -----BEGIN PGP SIGNATURE-----
    Comment: OpenPGP Encrypted Email Preferred.
    
    iD8DBQE7ISwpPYrxsgmsCmoRAkl8AKCcq0NwWdCUBN2DWXDE0jQwkGjIswCgz8TY
    DxI4w1GLvJCPanLfMUpw5o4=
    =8Q+E
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Sun Jun 10 2001 - 15:23:58 PDT