how to use the gnupg for authenticated logins
Fri Aug 8 20:06:02 2003
Content-Description: signed data
On Thursday 07 Aug 2003 11:40 am, Sharad Sahu wrote:
> 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=
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=
2003 19:18:32 -0400):
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.
> 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 -=
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.=
Just match the data with what was sent (to stop people sending any old sign=
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=
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
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=
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=
the correct secret key is available on the client) and puts the password in=
the HTML form. A big problem with this is that the password is clear text a=
this point. Biglumber advises members to use a new password each time and c=
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=
only allows logged-in users to affect listings of their own keys or events,=
any interference should be obvious. (It's not a good idea for the server to=
try and limit the number of connections or to detect a second user. It coul=
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=
while the length makes it difficult for someone in the same room to memoris=
the mixed upper-case/lower-case/numeral string. Deleting (or invalidating)=
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=
login form on a https:// server.
The Biglumber method involves the least work for the client but requires a=
configured email client as well as a browser.
IMHO, Eugene's method involves better overall authentication if a https://=
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=
was actually some random text that had to be signed by the client. That wou=
remove the risk of the password being overseen, but would needlessly=20
duplicate the verification of the key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----