Re: authentication via login form

[Ofer Inbar]

Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Oct 1999, Ofer Inbar wrote:
> 
> > Eugene Sotirescu <[EMAIL PROTECTED]> wrote:
> [...snipped...]
> > 
> > When a browser session comes in without appropriate authentication
> > cookies, they get a login screen.  When they post username and
> > password, check that against the locally stored user table, and if
> > they match, issue a set of authentication cookies.  These hold three
> > pieces of information:
> >  - the username
> >  - the date-time (seconds since epoch) these cookies were issued
> >  - an MD5 hash
> > 
> > The hash is of: username, per-user secret, application secret,
> >  application's version number, IP address of browser session, and
> >  time cookies were issued.
> > 
> [...lots more snipped...]
> 
> I am curious because I've seen this sort of statement a couple times.
> 
> Wouldn't passing the username and time of the cookie issuance weaken the
> MD5 hash since you would be giving a perpetrator more information to
> create the MD5 hash themselves? It seems to me that at the very least,
> don't pass the time to the user because that doesn't add value to the
> client side.

Including the time and username in a readable form is necessary,
because without it, there's no way for the web application to *read*
those values when the user accesses the site again and sends in the
cookies.  If all you can read is a hash, how do you know who they're
trying to authenticate *as*?  Read every user out of the database and
try them all one by one?  But if you're not given the time, you can't
even try that brute force strategy, unless you repeat it for every
possible (or likely) time the hash might have been encoded with.  You
need to be able to read the user to know who they're claiming to be,
and you need the time to know whether their cookie set is expired or
not, and you need to know *both* in order to test the hash at all.

Now, by the avalanche property of MD5, every single bit of the input
should have a 50% chance of affecting each bit in the resulting hash.
So, letting the user know some of those bits shouldn't help them be
able to break the hash, as long as the stuff they *don't* know is hard
enough to break.

So, of course, the security of this hash is not based on the user not
being able to figure out their own username and the time they got the
cookies, and their IP address.  Heck, they could figure all that stuff
out whether they were handed it in a cookie or not.  The security is
based on the fact that they can't guess their per-user secret and the
application's global secret.  If you want to, you can also add some
other semi-random possibly hard to guess value to the mix, perhaps
your process ID (which by itself is somewhat guessable, but does add a
bit more uncertainty when combined with the secrets).

The reason all that other information (username, time, IP), that the
user does know or can figure out, is in the hash, is to ensure that
they cannot change it.  Otherwise, they could log in as one user, then
come back with a perfectly valid hash but pretending to be some other
user, and get that other user's privileges.  Or, they could keep
coming back with the current time, so their hash never expired.  But
if those values are included in the hash, and the user changes them,
unless they can guess the secrets and come up with a new hash, their
cookie set is no longer valid.

  --  Cos (Ofer Inbar)  --  [EMAIL PROTECTED] http://www.leftbank.com/CosWeb/
  --  WBRS (100.1 FM)   --  [EMAIL PROTECTED] http://www.wbrs.org/
   A cos is an abstraction for a stream or datagram channel, used in BSD
   and BSD derivatives.  -- Ben Tober <[EMAIL PROTECTED]>

Re: authentication via login form

[Gunther Birznieks]

On Mon, 11 Oct 1999, Ofer Inbar wrote:

> Eugene Sotirescu <[EMAIL PROTECTED]> wrote:
[...snipped...]
> 
> When a browser session comes in without appropriate authentication
> cookies, they get a login screen.  When they post username and
> password, check that against the locally stored user table, and if
> they match, issue a set of authentication cookies.  These hold three
> pieces of information:
>  - the username
>  - the date-time (seconds since epoch) these cookies were issued
>  - an MD5 hash
> 
> The hash is of: username, per-user secret, application secret,
>  application's version number, IP address of browser session, and
>  time cookies were issued.
> 
[...lots more snipped...]

I am curious because I've seen this sort of statement a couple times.

Wouldn't passing the username and time of the cookie issuance weaken the
MD5 hash since you would be giving a perpetrator more information to
create the MD5 hash themselves? It seems to me that at the very least,
don't pass the time to the user because that doesn't add value to the
client side.

Later,
  Gunther

Re: authentication via login form

[Rauznitz Balazs]

--- "Randal L. Schwartz" <[EMAIL PROTECTED]> wrote:
> I was actually looking at a PerlTransHandler that I'd drop into
> my site-wide files that would do something like the following:
> 
>   my $uri = $r->uri;
>   if ($uri =~ s#/@@(\d+)@@/#/#) {
> $session = $1;
> $r->uri($uri);
> $r->header(Session => $session);
>   }
> 
> This way, a session ID could be generated of the form
> 
>   /some/path/@@123456@@/foo/bar.html
> 
> And could be universally included in *any* URL handed to the user,
> but only those things that generate HTML and wish to maintain the 
> session would notice and re-include $session = $r->header(Session) in

> their strings.

A while ago I put together 4-5 rewriterules (mod_rewrite) to automate
passing of user IDs in the URL. This works for static files too and
doesn't require any change to the site. Something like this:

1. if the URI contans @@ID123456@@, then strip it and set enviroment
variable USERID
2. if HTTP_REFERER contains it, then issue an external redirect with
the same URI plus @@ID123456@@. (needed for absolute links)
There was also a rule for images and a special directory (/forgetid)
plus a rule to let other handlers grab the URI too.

My 2 cents

Balazs

__
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Re: authentication via login form

[Ofer Inbar]

Eugene Sotirescu <[EMAIL PROTECTED]> wrote:
> I'd like to authenticate users via a login form (username, password
> text fields) instead of using the standard dialog box a browser pops
> up in response to a 401 response code.

Here's what I do in an application I'm currently working on...

Application has a table of users stored locally, and along with the
usual /etc/passwd-ish sort of info stored, each user row also has a
random per-user secret.  The application also has its own secret
stored in the source code (and changed from time to time).

When a browser session comes in without appropriate authentication
cookies, they get a login screen.  When they post username and
password, check that against the locally stored user table, and if
they match, issue a set of authentication cookies.  These hold three
pieces of information:
 - the username
 - the date-time (seconds since epoch) these cookies were issued
 - an MD5 hash

The hash is of: username, per-user secret, application secret,
 application's version number, IP address of browser session, and
 time cookies were issued.

If a session comes in with these cookies already set, they are
checked.  Application reads the username and time from the cookies,
the IP address from the Apache request object, then looks up the
per-user secret in the local users table, and using the secret and
version number already known to it, recomputes the MD5 hash.  If this
matches the hash read from the cookie, the cookie set is valid.

If the cookie set is invalid, treat the user as if they had no cookies
and send them to the login screen.  If the cookie set is valid,
compare the cookie time to current time, and see if the difference is
greater than some configurable "expire" (say, 30 minutes).  If the
difference is lesser, then compute a new set of cookies with a new
time, and issue them to the browser with this page.  If the difference
is greater than the expire, send them to a screen that says the login
is expired and asking the user to resubmit username/password.

Finally, use SSL to protect the whole mess from sniffing.  SSL is a
reasonable protection against the initial username/password submission
from being sniffed.  It's also a protection against the cookie set
being copied and used by another user, along with the IP address.  In
this particular situation, the application is not for the general
public, and we can safely assume that all legitimate users will have
consistent IP addresses for the life of a browser session,a nd will
have cookies enabled on their browser.

The real key to using cookies this way, I think, and the one that
transfers well to a more public environment, is the expiration, which
is *not* under browser control.  Any authentication cookie set handed
out by this application is good only for a limited time, so if anyone
can "break" it it'll only do them good if they can do it within that
time period (hence attacks against SSL & MD5 are impractical).  Since
both the time encoded in the cookie hash, and the time it is compared
against, are both from the server's clock, the client can't affect
this by futzing with its own clock.  The tradeoff between convenience
and security can be controlled by changing the expire period.

Note that since a new set of cookies is issued for *every* access, a
valid login will not actually "expire" until the user fails to load
any new pages within the application for the duration of an expire
period.  Even if you set the expire to something really short, say a
minute, a user can continue using it without resubmitting
login/password as long as they do at least one thing that causes a new
HTTP access every minute.  As soon as they step away for a minute,
when they come back they'll be expired and have to log in again at the
next access.

I didn't use any modules for this, so I don't know if modules are
available for it, but the basic cookie generation and checking code
was rather short and simple.  The login & expired login page and
dealing with those form submissions took some more time to write, but
that's the sort of thing you probably want to design yourself anyway.

Thorough testing of every possible path through the login code is
essential here!  Remember also that users can "submit forms" that you
never gave them.  Test every possible path through the code to make
sure you're making the right decisions about a user's authentication
status, and do not limit the testing to only those form submissions
that make sense given what forms you present the user with.  This is
easy to overlook but you don't have security without it, if anyone
ever sees your code (and it's good to assume that someone will see it).

  -- Cos (Ofer Inbar)  --  [EMAIL PROTECTED] http://www.leftbank.com/CosWeb/
  -- Exodus Professional Services -- [EMAIL PROTECTED] http://www.exodus.net/
 Now, for the Quote out of Context(TM), from Mike Haertel <[EMAIL PROTECTED]>
 "I think it's pretty clear that Unix is dead as a research system."

Re: authentication via login form

[James G Smith]

Dave Hodgkinson <[EMAIL PROTECTED]> wrote:
>
>Michael Peppler <[EMAIL PROTECTED]> writes:
>
>> Don't use the IP address. Some proxy systems have a non-static IP
>> address for requests coming from the same physical client (some of
>> AOLs proxies work that way, if I remember correctly...)
>
>"...or something..." ;-)

I've been trying to put together a ticket scheme for authentication here and 
one of the issues is security and knowing someone else can't copy the ticket.  
I went ahead and made the IP address an optional part of the ticket -- the 
user can choose strong, medium, and weak security to include their IP, their 
network, or no IP information at all.  Might be something to consider -- 
default to something sane for some well-known networks like AOL.
-- 
James Smith <[EMAIL PROTECTED]>, 409-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: authentication via login form

[Dave Hodgkinson]

Michael Peppler <[EMAIL PROTECTED]> writes:

> Don't use the IP address. Some proxy systems have a non-static IP
> address for requests coming from the same physical client (some of
> AOLs proxies work that way, if I remember correctly...)

"...or something..." ;-)

-- 
David Hodgkinson, Technical Director, Sift PLChttp://www.sift.co.uk
Editor, "The Highway Star"   http://www.deep-purple.com
Dave endorses Yanagisawa saxes, Apache, Perl, Linux, MySQL, emacs, gnus

Re: authentication via login form

[Michael Peppler]

Dave Hodgkinson writes:
 > 
 > "Jamie O'Shaughnessy" <[EMAIL PROTECTED]> writes:
 > 
 > > 
 > > On 11 Oct 99 15:05:23 +0100, you wrote:
 > > 
 > > >I was actually looking at a PerlTransHandler that I'd drop into
 > > >my site-wide files that would do something like the following:
 > > >
 > > >  my $uri = $r->uri;
 > > >  if ($uri =~ s#/@@(\d+)@@/#/#) {
 > > >$session = $1;
 > > >$r->uri($uri);
 > > >$r->header(Session => $session);
 > > >  }
 > > >
 > > >This way, a session ID could be generated of the form
 > > >
 > > >  /some/path/@@123456@@/foo/bar.html
 > > >
 > > 
 > > But isn't the problem then that if the user cuts & pastes the URL for
 > > someone else to use (e.g. mails it to someone), they're also then passing
 > > on their authentication? 
 > > 
 > > Doesn't this also mean you can only have links from sessioned pages ->
 > > non-sessioned pages or sessioned pages -> sessioned pages and not
 > > non-sessioned pages -> sessioned pages. I'd classify a non-sessioned page
 > > as a static HTML page.
 > > 
 > > Have I missed something here?
 > 
 > Perhaps an MD2 or MD5 hash that has an IP and the username or some
 > other bumf as semi-authentication might do the trick?

Don't use the IP address. Some proxy systems have a non-static IP
address for requests coming from the same physical client (some of
AOLs proxies work that way, if I remember correctly...)

Michael
-- 
Michael Peppler -||-  Data Migrations Inc.
[EMAIL PROTECTED]-||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]

Re: authentication via login form

[Dave Hodgkinson]

"Jamie O'Shaughnessy" <[EMAIL PROTECTED]> writes:

> 
> On 11 Oct 99 15:05:23 +0100, you wrote:
> 
> >I was actually looking at a PerlTransHandler that I'd drop into
> >my site-wide files that would do something like the following:
> >
> > my $uri = $r->uri;
> > if ($uri =~ s#/@@(\d+)@@/#/#) {
> >   $session = $1;
> >   $r->uri($uri);
> >   $r->header(Session => $session);
> > }
> >
> >This way, a session ID could be generated of the form
> >
> > /some/path/@@123456@@/foo/bar.html
> >
> 
> But isn't the problem then that if the user cuts & pastes the URL for
> someone else to use (e.g. mails it to someone), they're also then passing
> on their authentication? 
> 
> Doesn't this also mean you can only have links from sessioned pages ->
> non-sessioned pages or sessioned pages -> sessioned pages and not
> non-sessioned pages -> sessioned pages. I'd classify a non-sessioned page
> as a static HTML page.
> 
> Have I missed something here?

Perhaps an MD2 or MD5 hash that has an IP and the username or some
other bumf as semi-authentication might do the trick?

We've done something similar for embedding URLs into newsletter type
emails so when people click through they come to something
personalised for them. 

Still, that's only for us pushing to them, anything involving money
requires a full session login on the secure server.


-- 
David Hodgkinson, Technical Director, Sift PLChttp://www.sift.co.uk
Editor, "The Highway Star"   http://www.deep-purple.com
Dave endorses Yanagisawa saxes, Apache, Perl, Linux, MySQL, emacs, gnus

Re: authentication via login form

[Jamie O'Shaughnessy]

On 11 Oct 99 15:05:23 +0100, you wrote:

>I was actually looking at a PerlTransHandler that I'd drop into
>my site-wide files that would do something like the following:
>
>   my $uri = $r->uri;
>   if ($uri =~ s#/@@(\d+)@@/#/#) {
> $session = $1;
> $r->uri($uri);
> $r->header(Session => $session);
>   }
>
>This way, a session ID could be generated of the form
>
>   /some/path/@@123456@@/foo/bar.html
>

But isn't the problem then that if the user cuts & pastes the URL for
someone else to use (e.g. mails it to someone), they're also then passing
on their authentication? 

Doesn't this also mean you can only have links from sessioned pages ->
non-sessioned pages or sessioned pages -> sessioned pages and not
non-sessioned pages -> sessioned pages. I'd classify a non-sessioned page
as a static HTML page.

Have I missed something here?

Jamie

___
Jamie O'Shaughnessye-mail: [EMAIL PROTECTED]
Oracle Designer Developmentphone : +44 118 92 45052
__  __  __ _  __ .   __
Statements and opinions are my own and not those of... (__)|-

Re: authentication via login form

[Randal L. Schwartz]

> "John" == John D Groenveld <[EMAIL PROTECTED]> writes:

John> Well if you're going to generate your HTML on the fly, URL mangling
John> isn't too bad. HTML::Mason and probably the other embedded perl modules
John> would allow you to more selectively and consistently place session id
John> into your HREFs and the strip session code from the Eagle book is very
John> easy to implement.
John> Your options are limitless, have fun!
John> John
John> [EMAIL PROTECTED] 

I was actually looking at a PerlTransHandler that I'd drop into
my site-wide files that would do something like the following:

my $uri = $r->uri;
if ($uri =~ s#/@@(\d+)@@/#/#) {
  $session = $1;
  $r->uri($uri);
  $r->header(Session => $session);
}

This way, a session ID could be generated of the form

/some/path/@@123456@@/foo/bar.html

And could be universally included in *any* URL handed to the user, but
only those things that generate HTML and wish to maintain the session
would notice and re-include $session = $r->header(Session) in their
strings.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: authentication via login form

[Randal L. Schwartz]

> "Jeffrey" == Jeffrey W Baker <[EMAIL PROTECTED]> writes:

Jeffrey> Randal, how do you suppose that HTTP basic auth works?  The
Jeffrey> user agent stores the username and password and transmits
Jeffrey> them to the server on every request.

The difference between a cookie and a basic-auth password is that for
a basic-auth, *I* am carrying the credential (the user/password), and
the browser is merely caching it, and I have some control over that.
A cookie is its own credential and therefore non-portable.  Until
someone invents a "cookie wallet" that I can plug into each browser
I'm using at the moment, cookies for long-term auth are truly
unusable.

Jeffrey> This is exactly identical to a cookie which is set to have a
Jeffrey> short expiration time.  That's why I say replacing basic auth
Jeffrey> with cookies is acceptable: both of them are a totally
Jeffrey> inadequate way to authenticate users.

Yes, and I agree with you.  For *short term* auth, cookies are OK.
But I've seen too many apps out there that use cookies for unique ID
for long term.  Wrong.  Broken.  Busted.  Basic-auth would be way
better, although still not ideal.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: authentication via login form

[J. Robert von Behren]

On Sun, 10 Oct 1999, Jeffrey W. Baker wrote:
...snip...
> In my opinion storing anything besides a session key on the client side is
> needless extra work.  Just give the client a token, in the cookie or in the URL,
> and make sure the client sends that token back on every request.  Store the
> expriration time, the user name, and other information about the session on the
> server.  Check and update this information on every request.  Make the client
> reauthenticate after a short period of inactivity (15 minutes, perhaps), and
> give the user a way to logout or otherwise destroy their session (in case they
> are on a public terminal).
...snip...


If anyone is interested, I've got a somewhat hacked version of
Apache::AuthCookie.pm that allows the browser to store information either
as a cookie OR using standard HTTP authentication.  This doesn't win you
anything in terms of security of course, but it at least allows the stuff
to work even with clients that refuse all cookies.  The code is a bit 
crufty at this point, but I'd be happy to clean it up and publish it if 
anyone would like to use it.

-Rob

Re: authentication via login form

[Ajit Deshpande]

On Sun, Oct 10, 1999 at 12:34:56AM -0700, Randal L. Schwartz wrote:
> > "Jeffrey" == Jeffrey W Baker <[EMAIL PROTECTED]> writes:
> 
> Jeffrey> Cookies are an acceptable way to make the browser remember
> Jeffrey> something about your site.
> 
> Speak for yourself.  I'd change that to "... one possible way ..." instead
> of "acceptable way", and add "... for a single session".
> 
> Cookies are evil when used for long-term identification.

So basically we have a problem with cookies that persist beyond 
one browser session. Do you have any other reservations against 
using cookies?

Ajit

Re: authentication via login form

[John D Groenveld]

Well if you're going to generate your HTML on the fly, URL mangling
isn't too bad. HTML::Mason and probably the other embedded perl modules
would allow you to more selectively and consistently place session id
into your HREFs and the strip session code from the Eagle book is very
easy to implement.
Your options are limitless, have fun!
John
[EMAIL PROTECTED] 

Re: authentication via login form

[Eugene Sotirescu]

Many thanks to all who replied.

1. I think I can summarize the responses so far as boiling down to how I
do session management (hidden fields, URL mangling, cookies) and that I
will have to develop my own authentication mechanism.
(The reason I hoped there might be a solution using Apache's standard
authentication mechanism is because users with login credentials will
also be able to access a message board which which uses Basic
authentication to validate them).
2. URL-based sessions are tempting (work with cookie-less browsers), but
seem a headache to implement site-wide, tho it might just be my
inexperience with them speaking here.
3. I am going to be using HTML::Mason for this site, so I will probably
use Apache::Session for session management with cookies.
  
By the way, the article that Jeffrey pointed me to
(http://www.modperl.com/book/chapters/ch6.html#Cookie_Based_Access_Control)
is very interesting - I ordered a copy of the book after reading it.

Thanks again.
-- 

Eugene

Re: authentication via login form

[Jeffrey W. Baker]

Spidaman The Defenestrator wrote:
> 
> The point that should be taken is that if one must use a cookie for auth,
> expire it early and often.  What would _really_ be nice is if there were
> a javascript or ecmascribble or whatever it's called object that can _set_
> or _unset_ the auth request headers so one _could_ do a form driven
> authentication that used HTTP standards (basic and digest authentication).

In that case wouldn't you be trusting the user-agent to respect the unset
command?

-jwb

Re: authentication via login form

[Jeffrey W. Baker]

Andrew McNaughton wrote:
> 
> Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> > [2] Mangled URL Paths
> >
> > Isn't it possible to browse the history on the harddrive... so is this
> > really more secure than non-persistent cookies?
> 
> Relying on browser based client side expiration is not a good idea, either for 
>cookies or for mangled URL's.

Yes!  I hope those of you who attended my short crash course on session
management at the O'Reilly conference took at least this one thing away:  if you
need security, you must not ever trust information you get from the client. 
Never, ever, ever.

> Either you store information about when the user identifier (cookie or url 
>component) was last used on the server, or you put expiration information in the 
>cookie content along with a cryptographically secure checksum (as described in the 
>modperl book).  You must check the expiry time for every authenticated hit.

In my opinion storing anything besides a session key on the client side is
needless extra work.  Just give the client a token, in the cookie or in the URL,
and make sure the client sends that token back on every request.  Store the
expriration time, the user name, and other information about the session on the
server.  Check and update this information on every request.  Make the client
reauthenticate after a short period of inactivity (15 minutes, perhaps), and
give the user a way to logout or otherwise destroy their session (in case they
are on a public terminal).

> So what is the security advantage of mangled URLs over cookies for authentication?

I can't think of any security reason, but mangled URLs are more likely to work,
you can bookmark them and get your session back at some other time, etc.  There
are huge threads on cookies vs. URLs in the archives.

Cheers,
Jeffrey

Re: authentication via login form

[Jeffrey W. Baker]

"Randal L. Schwartz" wrote:
> 
> > "Jeffrey" == Jeffrey W Baker <[EMAIL PROTECTED]> writes:
> 
> Jeffrey> Cookies are an acceptable way to make the browser remember
> Jeffrey> something about your site.
> 
> Speak for yourself.  I'd change that to "... one possible way ..." instead
> of "acceptable way", and add "... for a single session".
> 
> Cookies are evil when used for long-term identification.
> 
> There is no one-to-one correspondance between a user and a browser,
> and yet cookies presume so.  In a given week, I might use four or five
> browsers, and a few of those will be in public places, like libraries
> or client's sites.

Randal, how do you suppose that HTTP basic auth works?  The user agent stores
the username and password and transmits them to the server on every request. 
This is exactly identical to a cookie which is set to have a short expiration
time.  That's why I say replacing basic auth with cookies is acceptable: both of
them are a totally inadequate way to authenticate users.

-jwb

Re: authentication via login form

[Andrew McNaughton]

Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> [2] Mangled URL Paths
> 
> Isn't it possible to browse the history on the harddrive... so is this
> really more secure than non-persistent cookies?

Relying on browser based client side expiration is not a good idea, either for cookies 
or for mangled URL's.  

Either you store information about when the user identifier (cookie or url component) 
was last used on the server, or you put expiration information in the cookie content 
along with a cryptographically secure checksum (as described in the modperl book).  
You must check the expiry time for every authenticated hit.

So what is the security advantage of mangled URLs over cookies for authentication?

Andrew McNaughton


-- 

Andrew McNaughton
+64 4 389 6891
[EMAIL PROTECTED]
http://www.scoop.co.nz/

Re: authentication via login form

[Gunther Birznieks]

On Sun, 10 Oct 1999, Spidaman The Defenestrator wrote:

> 
[...snip...]
> 
> But I digress.  Go ahead, use cookies and mangle them into auth headers
> but make sure they aren't persistent cookies.  And don't use this level of
> security for banking or commerce; those get mangled URL paths.  In a self
> contained intranet world, using client certificates and mod_ssl sounds
> like a good proposition.

[1] Client Certs

Under certain circumstances, SSL and client certs for authentication for
an Intranet is not necessarily that great.

[A] Users do roam (a pain to support cert loading)
[B] In a global organization, proxy infrastructure plays a part... SSL is
impossible to proxy, and when it is, you can't proxy client certs.
[C] SSL adds unnecessary overhead to the web server especially a heavily
used Intranet one potentially.

Client Certs are not necessarily more secure that username/passwords
and/or securID over a normal SSL connection. It depends on the environment
that the client cert is kept under control.

[2] Mangled URL Paths

Isn't it possible to browse the history on the harddrive... so is this
really more secure than non-persistent cookies?

Re: authentication via login form

[Spidaman The Defenestrator]

The point that should be taken is that if one must use a cookie for auth,
expire it early and often.  What would _really_ be nice is if there were
a javascript or ecmascribble or whatever it's called object that can _set_
or _unset_ the auth request headers so one _could_ do a form driven
authentication that used HTTP standards (basic and digest authentication).
Well, it'd be nice if browsers did a lot of things, like sent a
useful header:
Accept-code: ecmascribble/1.4, JVM/1.2, client-side-perl/6.0
...the percentage of sites that actually use content negotiation is
probably < 5% yet the browsers send all this chatter about what they
accept for content and nothing about programmatic capabilities.  Fooey.

But I digress.  Go ahead, use cookies and mangle them into auth headers
but make sure they aren't persistent cookies.  And don't use this level of
security for banking or commerce; those get mangled URL paths.  In a self
contained intranet world, using client certificates and mod_ssl sounds
like a good proposition.
-Ian

Meanwhile, back at the ranch...
> Jeffrey> Cookies are an acceptable way to make the browser remember
> Jeffrey> something about your site.
> Be careful when you use cookies.  Make sure it's your LAST choice.
> Mangled URLs and hidden fields are other straightforward alternatives.

--
Salon Internet  http://www.salon.com/
  HTTP mechanic, Perl diver, Mebwaster, Some of the above
Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326 

Re: authentication via login form

[Randal L. Schwartz]

> "Jeffrey" == Jeffrey W Baker <[EMAIL PROTECTED]> writes:

Jeffrey> Cookies are an acceptable way to make the browser remember
Jeffrey> something about your site.

Speak for yourself.  I'd change that to "... one possible way ..." instead
of "acceptable way", and add "... for a single session".

Cookies are evil when used for long-term identification.

There is no one-to-one correspondance between a user and a browser,
and yet cookies presume so.  In a given week, I might use four or five
browsers, and a few of those will be in public places, like libraries
or client's sites.

Be careful when you use cookies.  Make sure it's your LAST choice.
Mangled URLs and hidden fields are other straightforward alternatives.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: authentication via login form

[Jeffrey W. Baker]

Eugene Sotirescu wrote:
> 
> I'd like to authenticate users via a login form (username, password text
> fields) instead of using the standard dialog box a browser pops up in
> response to a 401 response code.
> 
> Can this be done while still using Apache's authentication mechanism?
> 
> I understand that authentication happens in 2 passes:
> first the server sends back a 401 and WWW-Authenticate header in
> response to a request for a resource in a protected directory. Then the
> browser pops up a dialog box, collects the entered information
> (user/password) and sends it back Base64 encoded to the server in an
> Authorization header. If the authentication succeeds, the browser
> returns the page and remembers the authentication info for subsequent
> requests for resources in the same directory or directories under it.
> 
> While I could collect the username/passwd from the form fields, encode
> them and pass them to the server, I can't figure out how to make the
> browser remember the credentials for all other pages under the protected
> directory.
> 
> Any ideas much appreciated.


Cookies are an acceptable way to make the browser remember something about your
site.

http://www.modperl.com/book/chapters/ch6.html#Cookie_Based_Access_Control

-jwb