how to use the gnupg for authenticated logins
Sun Aug 10 12:31:01 2003
Content-Description: signed data
On Sunday 10 Aug 2003 1:55 am, Carl L. Gilbert wrote:
> > > > The server sends the token to the client, encrypted with the trusted
> > > > client key. Once this is verified, the process can be automated from
> > > > the client end:
> > > >
> > > > 1. Client requests connection.
> > > > 2. Server sends a token encrypted with the trusted client key. (Fail
> > > > if no trusted key)
> > > > 3. Client can decrypt this token (preferably using a human entered
> > > > passphrase) and then return the token re-encrypted to the trusted
> > > > server key. (Fail if decrypted token doesn't exactly match text sent
> > > > to the client identified by the token.)
> > >
> > > can't this fall to a record and playback attack?
> > The token has to be a one-off. The random text in the token would only
> > authenticate one client and the server maintains a list of outstanding
> > tokens and the keyID's used to encrypt them. Upon successful
> > authentication, the token is invalidated by the server and deleted from
> > the outstanding list. Together with the need for successful verification
> > of the client signature on the returned token, this should mean that a
> > recorded token is useless as soon as the server receives the real one. A
> > diverted token may be a different problem - have to see if diversion
> > could be defeated by the signature, perhaps include a route/network
> > address inside the signed token. A spoof token cannot be created before
> > the client replies, so the options for record and playback should be
> > limited.
Would you agree that the invalidation of the token and the use of random te=
can give some reassurance about replay attacks on this system (should I eve=
get it operating)?
> > But SSH keeps to the same key - once verified, the key details don't
> > change and any MITM attack can be detected. SSH still leaves the
> > possibility of the client connecting to a false server that first time.
> For me, the fingerprint could be on the receipt in my package when I
> receive my merchandise from the store. Or it could be displayed on the
> website. Or I could walk into the bank and pick up a copy, etc.
I agree, the fingerprint used by SSH can be confirmed at this stage using=20
secondary sources - signed emails, packages etc.
Have we worked out a working idea then? Could the trusted key / keysigning =
random text / encrypted token scheme work as a protocol? (It'll need a bett=
I just need to work out how to implement it. As far as I can see, the=20
semi-automated human authentication should work fine using existing scripti=
languages. The only output to a browser is the ASCII armoured encrypted tok=
=2D the client can copy it to the clipboard and verify, sign, encrypt and=20
return via a HTML form. It's a fair bit of work for the client though,=20
compared with a username/password, so there would need to be some real=20
goodies to play with once logged in.
The automated form would need some form of daemon and client, this is where=
GnuPG could win over existing users of username/password combinations - the=
authentication could be transparent and the client would only need to provi=
their GnuPG passphrase to the local client program. An identification cooki=
could be set when the token is requested and the cookie updated when the=20
browser refreshes the page after authentication via the client. Would that=
work? (The cookie ID string could be included in the token.)
Provided it is clear to all users that the passphrase DOES stay local and t=
all network traffic is encrypted, I think users would be happy. Perhaps a=20
configurable output, much like KMail, where the signed/encrypted data is=20
displayed for user reassurance before transmission. Users who have built up=
trust in the software can later set an option in the client config to let t=
authentication proceed with just the passphrase being entered.
My knowledge of daemons/clients isn't up to doing this well, (better to be=
honest here!), anyone here willing to help?=20
I'd like a daemon that can be queried by PHP/Perl and output the ID string =
the cookie before authentication. PHP/Perl could then ask the daemon again=
when the page is refreshed. When the daemon/client have completed=20
authentication, the daemon would output a new ID that PHP could use to=20
maintain authentication between pages alongside the usual sessionID. Only i=
the sessionID and the cookieID match would PHP continue the session.
Could the daemon actually be a perl script - started by the token request a=
quitting after authentication or a time-out? The ID itself could be put int=
a database for verification during the session and deleted at logout. This=
would simplify implementation on existing web servers - requesting a whole=
new (untested) service is not going to be easy!
I'm willing to implement the daemon/client if someone can help with the cod=
(This whole idea only started because there's a chicken:egg problem with=20
devising a new protocol.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----