how to use the gnupg for authenticated logins

Fri Aug 8 20:06:02 2003

--Boundary-02=_gc+M/6dhgZa9Y7o
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Thursday 07 Aug 2003 11:40 am, Sharad Sahu wrote:
> Hi,
> I want to use the gnupg in a client server environment. Client  request to
> server to create a session for  him.  Server authenticate the client  bas=
ed

As always in Linux, there are alternative methods. Here are just two:

As previously suggested on this list (From: Eugene Smiley, Date: Thu, 24 Ju=
l=20
2003 19:18:32 -0400):
<quote>
I'd think this could be a simple script. Start with a login page that
displays a random selection of text to be signed. The user copies
the text and signs it and pastes it into a textbox. On submit, the
script runs gpg (or gpgv) to verify the signature on the contents of
the textbox. Extract the email address for the login ID. Drop your
info into a session cookie to keep the state as the user surfs your site.
</quote>
> on the signature provided by the client and issue a license to him .i want
> to  transfer  the singature  safely  to the client.

Did you mean to the server, rather than to the client? The client sends=20
authentication to the server, the server sends the licence to the client -=
=20
probably in the form of a cookie.=20

You could ask the client to encrypt the random text but as long as it is=20
random, it is the signature of the data that matters, not the data itself.=
=20
Just match the data with what was sent (to stop people sending any old sign=
ed=20
data), verify a good signature (which verifies the correct secret key is=20
available at that client) and complete authentication.

> Let me know how can I use the gnupg .

It wasn't quite what I was looking for when I posted my query (contains more
activity than I'd like for frequent logins - at least if people aren't usin=
g=20
some kind of GUI GnuPG frontend like KGpg), but I think it would suit=20
infrequent logins very well. (I may still use it, I'm open to other=20
alternatives.)

One alternative is the way that www.biglumber.com operates - the client=20
requests a login token from the site after completing registration. The=20
server retrieves an email address from a UID of the public key already in t=
he=20
server's private keyring as part of registration and sends an encrypted=20
password via email to the client. The client decrypts the email (proving th=
at=20
the correct secret key is available on the client) and puts the password in=
to=20
the HTML form. A big problem with this is that the password is clear text a=
t=20
this point. Biglumber advises members to use a new password each time and c=
an=20
delete the cookie when the user logs out. The remaining weakness only=20
involves two different people logged in at the same time, but as biglumber=
=20
only allows logged-in users to affect listings of their own keys or events,=
=20
any interference should be obvious. (It's not a good idea for the server to=
=20
try and limit the number of connections or to detect a second user. It coul=
d=20
just be the one user viewing in two browser windows.) Biglumber uses (I=20
think) 32 character passwords and using email makes it easy to copy and pas=
te=20
while the length makes it difficult for someone in the same room to memoris=
e=20
the mixed upper-case/lower-case/numeral string. Deleting (or invalidating)=
=20
the cookie makes the email itself useless once the correct user logs out.

The biglumber method could be enhanced if you have SSL available and put th=
e=20
login form on a https:// server.

The Biglumber method involves the least work for the client but requires a=
=20
configured email client as well as a browser.
IMHO, Eugene's method involves better overall authentication if a https://=
=20
connection isn't available and clients are likely to be logging in using=20
machines in public areas.

The two methods could be combined if the 'password' in the biglumber method=
=20
was actually some random text that had to be signed by the client. That wou=
ld=20
remove the risk of the password being overseen, but would needlessly=20
duplicate the verification of the key.

=2D-=20

Neil Williams
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://www.codehelp.co.uk
http://www.dclug.org.uk

http://www.biglumber.com/x/web?sn=3DNeil+Williams

--Boundary-02=_gc+M/6dhgZa9Y7o
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA/M+cgiAEJSii8s+MRAqJiAKCR+wEze4AwNiSdNTXj8szR1U9yGACg1/TZ
TZXmdbZM3uYYeCTAPI/i1ps=
=GY4O
-----END PGP SIGNATURE-----

--Boundary-02=_gc+M/6dhgZa9Y7o--