Re: Why couldn't Public keys replace Passwords on the Internet?

From: Dave (galt_57@hotmail.com)
Date: 01/26/03

  • Next message: Fireglyph: "Re: Password Cracking"
    From: galt_57@hotmail.com (Dave)
    Date: 25 Jan 2003 18:27:55 -0800
    
    

    "x y" <levinson_k@excite.com> wrote in message news:<#eWwoCJxCHA.1632@TK2MSFTNGP12>...
    > "Aaron Dodd" <aaron@aarondodd.com> wrote in message
    > news:pan.2003.01.24.17.36.49.985034@aarondodd.com...
    >
    > > > Storage of the private key on the client instead of the server and
    > > > relying on the client to authenticate the user seems like a step
    > > > backwards instead of forwards to me, certainly you'd need to do it
    > > > carefully to store the private key securely.
    >
    > > I think you're confusing the suggestion a little.
    >
    > You're probably right, I'm no expert here.
    >
    > > The site wouldn't store
    > > the private key at all, so there'd be no issue with the security of the
    > > private key (from the server's standpoint).
    >
    > Yes, agreed... I was referring to secure storage of the private key on the
    > client, to protect it from other users with local or remote access to the
    > client machine.
    >
    > One other possibly problem.. if the private key was lost, and not backed up
    > [which I'm sure it would not be in most cases], then confirming your
    > identity and re-generating a new key could require some thought [or at least
    > it's beyond me to figure out how it could work while preventing someone from
    > resetting your cert to hijack your identity]. Currently this is often done
    > by the server maintaining a database of previously shared information on the
    > user, such as maiden name or birthday plus email address.
    >
    > If the key WAS backed up, say to a floppy, that could be a potential source
    > of key compromises as well.

    There would be no storage of the private key anywhere. The user would
    only need to remember one password and some user-specific data to
    enter into and log into the browser. The browser would use those data
    items as a seed to generate and regenerate the user-specific public
    and private keys. The user would provide the browser with a password
    and desired web identity and the browser would then handle all the
    password and identification challenge and response interchanges with
    the various websites.

    These websites would be given the desired web identity, the public
    key, and the browser would provide time-keyed/root-web-address keyed
    responses to public key challenges.

    No passwords would be stored on websites. No passwords would be
    floating around the web. Users would not need to invent and remember
    and periodically change multiple passwords. Users would not need to
    enter login data at web sites. The web identity, challenge and
    response would be handled by the browser.

    The challenge and response data flowing on the web would be
    self-expiring due to the time-stamping and would prevent web-page
    faking by the root-web-address checking. The only thing that might be
    stored would be a permanently encrypted file containing the
    user-specific data; the additional data that would assure a good
    random seed, and this file would be stored on the user's own pc, and
    could be given a random name and hidden in a browser directory with
    fifty other similar looking files. The user's browser password and web
    identity would select the real file.