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

• Previous message: Lyal Collins: "Re: Password Cracking"
• In reply to: x y: "Re: Why couldn't Public keys replace Passwords on the Internet?"
• Next in thread: Aaron Dodd: "Re: Why couldn't Public keys replace Passwords on the Internet?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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.

• Next message: Fireglyph: "Re: Password Cracking"
• Previous message: Lyal Collins: "Re: Password Cracking"
• In reply to: x y: "Re: Why couldn't Public keys replace Passwords on the Internet?"
• Next in thread: Aaron Dodd: "Re: Why couldn't Public keys replace Passwords on the Internet?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]