modperl-user_authentication_without_cookies

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



From: John Saylor <johns@WorldWinner.com>
To: Ian Frawley <ifrawley@acquist.co.uk>, modperl@apache.org
Subject: Re: Remembering Authentication
Date: Tue, 17 Oct 2000 09:24:51 -0400

From: "Ian Frawley" <ifrawley@acquist.co.uk>

> Is it possible to authenticate a user without having to use the
> unfriendly login box provided by browsers, without using cookies?

2 words: digital certificates

This probably means a lot of infrastructure [LDAP, CA, smart cards ...],
but it will let your users authenticate without doing anything more than
clicking the certificate they want to use for authentication.

===

From: John Saylor <johns@WorldWinner.com>
To: Ian Frawley <ifrawley@acquist.co.uk>, modperl@apache.org
Subject: Re: Remembering Authentication
Date: Tue, 17 Oct 2000 09:48:02 -0400

Ian Frawley" <ifrawley@acquist.co.uk> wrote: 

> Is it not just possible through a perl module as I am
> not very clued up on digital certificates.

Well, you have to have some credentials- and if it's not a cookie [bad
idea anyway], and if it's not a username/password- what would it be?

You could have IP address based authentication, but this is probably
more prone to misconfiguration and forgery than digital certificates.

How important is access control to your application? In other words,
where is the line on how much effort you [and your users] are going to
put into security at the expense of convenience?

===

Date: Tue, 17 Oct 2000 09:57:22 -0400
From: Shimon Rura <shimon@rura.org>
Subject: Re: Remembering Authentication
To: Ian Frawley <ifrawley@acquist.co.uk>
Cc: modperl@apache.org

On Tue, Oct 17, 2000 at 02:20:22PM -0500, Ian Frawley wrote:
> Hi all
> 
> Is it possible to authenticate a user without having to use the unfriendly
> login box provided by browsers, without using cookies?
> 
> I have managed to authenticate a user once through some text fields on a
> HTML page but unfortunately this does not make the browser remember the
> user's authentication information. On subsequent requests to the same
> secure area apache requires that the user enters their credentials again.
> 
> Is there a way around this? If so any help would be appreciated. 

There's no way to use basic authentication (the stuff inside HTTP) from web
pages... you can't tell a browser "use this form to ask your user for
passwords".  If you want to manage authentication in web pages, you have to
build the whole authentication/session management system yourself.  Since
you don't want to use cookies, you will have to preserve state on the server
side and redirect the client to all sorts of ugly URLs with unique IDs
embedded inside.  Or you could embed the username and password in the URLs,
which would probably be dangerous from the security perspective and would
probably make users cringe, but would let their browser send that
information at each request.

BUT if your only objection to basic authentication is the "unfriendly" login
box provided by their browser, you should probably accept that the web is
not a medium whereby you should expect or try to mold the complete user
interface.  The popup box that says "Enter password for Bob's Secure Area"
might not have your logos and banner ads, but the user will understand what
it means.  On some browsers they will even be able to do useful things like
save that password for future sessions.  Sure, you could program this whole
thing yourself, but unless you really need a more sophisticated user
structure this way really isn't that bad.

Remember: "less is more."

===

Date: Tue, 17 Oct 2000 10:05:16 -0400 (EDT)
From: Todd Chapman <modperl@chaka.net>
To: modperl@apache.org
Subject: Re: Remembering Authentication

John Saylor wrote:

> "Ian Frawley" <ifrawley@acquist.co.uk> wrote: 

> > Is it not just possible through a perl module as I am not very clued
> > up on digital certificates.

> Well, you have to have some credentials- and if it's not a cookie [bad
> idea anyway], and if it's not a username/password- what would it be?
> 
> You could have IP address based authentication, but this is probably
> more prone to misconfiguration and forgery than digital certificates.
> 
> How important is access control to your application? In other words,
> where is the line on how much effort you [and your users] are going to
> put into security at the expense of convenience?

What if the user added his username and password to the URL? If they are
valid the application could add those parameters to all links/form
actions, but the plaintext password would be replaced with some parameter
that would be good for the next access and expire after a specified period
of time. The inital URL could be generated from a fill-out form.

===

Date: Tue, 17 Oct 2000 16:37:27 +0200 (CEST)
From: Nicolas MONNET <nico@monnet.to>
To: Shimon Rura <shimon@rura.org>
Subject: Re: Remembering Authentication

On Tue, 17 Oct 2000, Shimon Rura wrote:

|There's no way to use basic authentication (the stuff inside HTTP) from web
|pages... you can't tell a browser "use this form to ask your user for
|passwords". 

#untested code
use URI::Escape;
use CGI;
$q=new CGI;
$l=uri_escape($q->param('login'),'^A-Za-z0-9');
$p=uri_escape($q->param('password'),'^A-Za-z0-9');
print $q->redirect("http://$login:$password@$ENV{HTTP_HOST}/path");

===

Date: Tue, 17 Oct 2000 16:41:02 +0200 (CEST)
From: Nicolas MONNET <nico@monnet.to>
To: Shimon Rura <shimon@rura.org>
Subject: Re: Remembering Authentication

Nicolas MONNET wrote:

|Shimon Rura wrote:
|
||There's no way to use basic authentication (the stuff inside HTTP) from web
||pages... you can't tell a browser "use this form to ask your user for
||passwords". 
|
|#untested code
|use URI::Escape;
|use CGI;
|$q=new CGI;
|$l=uri_escape($q->param('login'),'^A-Za-z0-9');
|$p=uri_escape($q->param('password'),'^A-Za-z0-9');
|print $q->redirect("http://$login:$password@$ENV{HTTP_HOST}/path");


ouch:
print $q->redirect("http://$l:$p\@$ENV{HTTP_HOST}/path");

===

Date: Tue, 17 Oct 2000 22:53:03 +0800
To: "Ian Frawley" <ifrawley@acquist.co.uk>,
From: Gunther Birznieks <gunther@extropia.com>
Subject: Re: Remembering Authentication

I should probably place a plug and say that the open source extropia 
authentication framework for Perl handles digital certificates, session's 
with and without cookies, the unfriendly login screen, form-based logon 
screens in it's default capacity.

As a company working on real projects, we've also adapted it to 3rd party 
authentication schemes so our applications could plug into proprietary auth 
mechanisms including a couple banks and a WAP portal (where asking 
passwords is a pain for WAP users).

The free stuff is in the extropiaperl project at sourceforge.net and the 
docs are at http://www.extropia.com/ExtropiaObjects/ including an extremely 
detailed chapter on the basic choices you basically have related to auth on 
the web.

Later,
    Gunther

PS It was mentioned you probably need LDAP for certs. The key word is 
probably. But it does add an additional layer of security and many 
*IMPLEMENTATIONS* of using digital certificates require the use of LDAP as 
a lookup data store to double check that the cert has not been revoked in 
real-time.

However, digital certs are not for the faint of heart, they aren't cross 
browser friendly, are a pain in the ass to mint unless you have bought a 
3rd party digital cert mechanism (or force the user to get one at 
Verisign), and require the use of SSL throughout the entire user session.



===

Date: Tue, 17 Oct 2000 16:56:56 +0200 (CEST)
From: Nicolas MONNET <nico@monnet.to>
To: Rodney Broom <rbroom@home.com>
Subject: Re: Remembering Authentication

On Tue, 17 Oct 2000, Rodney Broom wrote:

|From: "Nicolas MONNET" <nico@monnet.to>
|
|> print $q->redirect("http://$l:$p\@$ENV{HTTP_HOST}/path");

Like what?



===

From: Simon_Wilcox@williamslea.com
To: "Ian Frawley" <ifrawley@acquist.co.uk>
Date: Tue, 17 Oct 2000 16:05:13 +0100
Subject: Re: Remembering Authentication

Ian,

      Using cookies is just one way of overcoming the stateless nature of http.
      The other ways that I know of are to modify the url in some way or to put
      a hidden field in a form.

      The latter only works if you're processing forms of course so for general
      viewing, you need to modify the URL. There are two ways that I have heard
      about.

      1. modify the url to include a session key in the path. To serve html
      pages you'd need to write a custom content handler to rewrite all your
      outgoing page links to include the session key. I haven't seen one on
      CPAN, please let me know if you find one, I could use it too !

      2. authenticate the users and then redirect to a fake host
      session.www.somecorp.com/page/you/wanted/. Then you use a custom handler
      at the translation phase to strip the session key and recover the user
      name from whatever session store you're using.

      I haven't got beyond cookies myself but these are both avenues I need to
      explore in the next few months.

      HTH,

      Simon Wilcox

Hi all

Is it possible to authenticate a user without having to use the unfriendly login
box provided by browsers, without using cookies?

I have managed to authenticate a user once through some text fields on a HTML
page but unfortunately this does not make the browser remember the user's
authentication information. On subsequent requests to the same secure area
apache requires that the user enters their credentials again.

Is there a way around this? If so any help would be appreciated.

Thanks

Ian


===

From: "Rodney Broom" <rbroom@home.com>
To: "mod_perl list" <modperl@apache.org>
Subject: Re: Remembering Authentication
Date: Tue, 17 Oct 2000 08:14:38 -0700

From: "Nicolas MONNET" <nico@monnet.to>

> print $q->redirect("http://$l:$p\@$ENV{HTTP_HOST}/path");

Ack! Can anybody find a bigger security hole than this?



===

Date: Tue, 17 Oct 2000 11:45:01 -0400 (EDT)
From: "Sean D. Cook" <sdc@edutest.com>
To: modperl@apache.org
Subject: Re: Remembering Authentication


Why not just write the app to use session and store to the db.  It is not
hard to do.  Auth to db/ldap cook up a digest with $$, username, and
remote_ip.  Store all userinfo in Storable object in the db/ldap.  

GET http://some.where.net/?sessionID=<md5 digest>

POST <input type=hidden name=sessionID value=<md5 digest>>

No worrying about browser type, client configuration... you should be all
set.  Stay away from cookies.  Cookies are bad when you have paying
customers!!



===

From: Simon_Wilcox@williamslea.com
To: "Ian Frawley" <ifrawley@acquist.co.uk>
Date: Tue, 17 Oct 2000 18:58:29 +0100
Subject: Re: Remembering Authentication

AuthCookie won't help you here, it still sends a cookie back to the client.
Whatever you do, you will need to modify the response to the client to contain a
session id somewhere where you can get it back.

      From what you've said, you will need to modify the url in some way. It
      doesn't matter whether you store information in a server-side store or in
      the session key itself, you still need to stick it in the url somewhere
      and make sure that all relative links contain that key.

      Is there a handler out there that can munge relative urls in this way for
      static pages, perhaps as part of an Apache::Filter chain ?



The problem for me with cookies is the fact that we are going to be serving WAP
phones that don't like cookies for obvious reasons.

The only thing I can think of is using server side cookies that are destroyed at
the end of the user session. Perhaps relating the server side cookie to a
Session ID storing the users password and username to compare against.

The problem with this is that I can't seem to install the AuthCookie module from
cpan. DOH!!!

===

From: "Ian Frawley" <ifrawley@acquist.co.uk>
To: "John Saylor" <johns@WorldWinner.com>, <modperl@apache.org>
Subject: Re: Remembering Authentication
Date: Tue, 17 Oct 2000 15:01:16 -0500

"John Saylor" <johns@WorldWinner.com> wrote: 
>
> "Ian Frawley" <ifrawley@acquist.co.uk> wrote: 
>
> > Is it not just possible through a perl module as I am not very clued
> > up on digital certificates.
>
> Well, you have to have some credentials- and if it's not a cookie [bad
> idea anyway], and if it's not a username/password- what would it be?
>
> You could have IP address based authentication, but this is probably
> more prone to misconfiguration and forgery than digital certificates.
>
> How important is access control to your application? In other words,
> where is the line on how much effort you [and your users] are going to
> put into security at the expense of convenience?

Security is very important as the user will be buying something and I have
to distinguish if the user is a casual browser[rules out smart cards] or a
regular shopper. Casual browsers need to be told how wonderful our content
is and asked 1)do they want to sign up or 2) Do they want to make an
immediate credit card payment[rules out smart cards again]. Where as regular
shoppers(subscribers) can just login.

===

From: "Ian Frawley" <ifrawley@acquist.co.uk>
To: <Simon_Wilcox@williamslea.com>, <modperl@apache.org>
Subject: Re: Remembering Authentication
Date: Tue, 17 Oct 2000 16:30:13 -0500

The problem for me with cookies is the fact that we are going to be =
serving WAP phones that don't like cookies for obvious reasons.

The only thing I can think of is using server side cookies that are =
destroyed at the end of the user session. Perhaps relating the server =
side cookie to a Session ID storing the users password and username to =
compare against.=20

The problem with this is that I can't seem to install the AuthCookie =
module from cpan. DOH!!!


===

Date: Tue, 17 Oct 2000 20:21:23 -0700
To: modperl@apache.org
From: Bill Moseley <moseley@hank.org>
Subject: Re: Remembering Authentication

At 06:58 PM 10/17/00 +0100, Simon_Wilcox@williamslea.com wrote:
>
>AuthCookie won't help you here, it still sends a cookie back to the client.
>Whatever you do, you will need to modify the response to the client to
contain > a session id somewhere where you can get it back.
>
>  From what you've said, you will need to modify the url in some way. It
>  doesn't matter whether you store information in a server-side store or in
>  the session key itself, you still need to stick it in the url somewhere
>  and make sure that all relative links contain that key.
>
>  Is there a handler out there that can munge relative urls in this way for
>  static pages, perhaps as part of an Apache::Filter chain ?

Not as part of an Apache::Filter chain, but feel free to play with
http://www.hank.org/modules/AuthCookieURL-0.02.tar.gz

===

Date: Thu, 19 Oct 2000 01:08:10 +0100 (BST)
From: Matthew Byng-Maddick <mbm@colondot.net>
To: modperl@apache.org
Subject: Re: Remembering Authentication

On Tue, 17 Oct 2000, John Saylor wrote:
> From: "Ian Frawley" <ifrawley@acquist.co.uk> 
> > Is it not just possible through a perl module as I am not very clued
> > up on digital certificates.
> Well, you have to have some credentials- and if it's not a cookie [bad
> idea anyway], and if it's not a username/password- what would it be?

Form based authentication. Rather than the HTTP Basic box that the browser
provides.

> You could have IP address based authentication, but this is probably
> more prone to misconfiguration and forgery than digital certificates.

Yes. You forgot proxying and cacheing.

What you also appear to have forgotten is that mod_perl provides you with
a fantastic handle - PerlTransHandler - where you can really have some fun
with the Translation.

| # some test code....
| sub handler
|     {
|     my $r=shift;
|     my $uri=$r->uri();
|     if(extract_crypto(\$uri))
|         {
|         # push the credentials into the notes table, or the
|         # %ENV or similar at this point.
|         $r->uri($uri);
|         }
|     return DECLINED;

This can still be cryptographically secure - requires the transmission of
username/password pair once - which can be done over https if required.
Thereafter you can do what you like to identify a session....

> How important is access control to your application? In other words,
> where is the line on how much effort you [and your users] are going to
> put into security at the expense of convenience?

I think that the usage of digicerts is not wide enough yet that the use of
them is probably an inconvenience. Plus it doesn't work if someone
physically steals the computer. :)

===



the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu