Re: Public-Key authentication for websites

Oh, you are right. Looks like SSL/TLS is exactly what I want, I just
haven't known that you can create and use this certificates on the
client side too. I never saw that before, but I will take a deeper look
on it.

The only problem is that you must pay quite a lot for a trusted
certificate and that you aren't able to use existing Web-of-Trusts (if
you are using cacert). (Beside of that fact, that SSL/TLS doesn't
work on virtual hosts). And that nearly nobody owns a private
certificate (in comparison to GPG keys, which are well known in Linux
communities *g*).

Anyway many thanks for your answer :)

Christoph


On Fri, 2008-02-15 at 10:41 -0500, Johnathan Nightingale wrote:
> I'm not sure if this is the right list (nor how precisely, for that  
> matter, I got onto this list :) but how does your idea differ from  
> just using client certs?  Yes, that potentially means the format of  
> your GPG key might not be directly compatible, but there is pretty  
> widespread use of, for instance, government-issued non-repudiation  
> keys for e-government stuff.
> 
> As far as I know, though I haven't looked in detail, most modern  
> browsers allow sites to store client certs, and to request client  
> certificates as part of the TLS handshake.
> 
> Or am I totally missing your point?
> 
> Johnathan
> 
> 
> On 14-Feb-08, at 7:00 PM, Christoph Hack wrote:
> 
> >
> > Hiho everybody,
> >
> > today Public Keys are very popular and most Internet applications
> > support GPG-Keys (e.g. lots of Mail readers and Jabber). Those public
> > keys are much more secure and the user doesn't have transmit his
> > password and remember it.
> >
> > But up to now, there aren't any Web Browsers which support a way to
> > ask the user to sign something with his personal GPG Key. (please tell
> > me if I'm wrong). But I think if somebody could write a RFC or  
> > something
> > similar for that, there might be a chance of getting this feature into
> > some full-featured browsers :)
> >
> > Use Case:
> > A use case for that could be the authentication handling for a web  
> > site.
> > The websites must provide an (optional) way for the user to attach his
> > public keys to his profile and when the user wants to log-in, it's
> > enough if he is able to decrypt or sign a specific message.
> >
> > Benefits:
> > - the user must not remember different passwords
> > - it's probably much more secure than other password handling methods
> > - websites could use this as an alternative authentication method
> > - Bruce Force attacks against hashes in big databases (like recently  
> > on
> >   phpbb, woltlab, smf) aren't possible any more
> > - and yes, I know that this idea is similar to OpenID, but it doesn't
> >   require any additional services
> >
> > Problems:
> > You can't use static messages for signing or decrypting, because then
> > there is a high risk that somebody might collect and use the
> > authentication information again. On the other side, completely  
> > dynamic
> > keys allow the server to get any messages signed by the user, probably
> > with content the user don't want to sign. So there must be a well
> > defined format (for example a tuple including a general header to
> > describe the context, a domain and a secret (session)-key)...
> >
> > So, I am very interested in your opinion now. Do you think there is a
> > way to get a feature like that? Or is this idea just a crap?
> >
> > Regards,
> > Christoph Hack
> >
> >
> > PS: I hope this is the right ML to share this idea, if not please
> > redirect to the right one...
> >
> >
> >
> 
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
> 
>

Received on Friday, 15 February 2008 17:20:32 UTC