Authentication using login passwords a bad idea

Authentication using login passwords a bad idea

Post by Ron Reis » Thu, 14 Mar 1996 04:00:00



I've seen some articles that state using the login password for web
authentication is a bad idea.  Something about the password going by in
the clear.  How is this different from telnet?  Not that telnet is
that secure, but our auditors have decided it's ok.  If you type your
password into a browser authentication dialogue box it get's blended in
with your name (whatever you type) and converted to mime-base64 and sent
as clear text.  This seems no worse than telnet.

The plan we were working on was to create a 4.4bsd DB file that Apache-SSL
could use.  This file would hold around 27000-35000, depending on time of
year, records holding the encrypted login password.  The .db file would
be owned by the "www" user, and only accessable by that user.  We would
use a slightly modified mod_auth_db module to access it for User and Group
information.  Is there some way this file could be leaked if we keep it
out of the "htdocs" directory?

We'll want to be able to authenticate SSL and Non-SSL accesses.  With so
many people it's appealing to tell them all they can use their login password
for web access.  We'd like to be able to make things like class grades
available through the web.  If this is a bad idea, can someone tell me
why it's a bad idea?

thanks!

Ron
--

University of Delaware Information Technologies/Network and Systems Services
Computing Center/192 South Chapel Street/Newark DE, 19716
pgp finger print: 0D 73 06 6F D3 6A 99 D3  F5 D5 6E FF 3B B9 7C 2C

 
 
 

Authentication using login passwords a bad idea

Post by Kevin Kad » Fri, 15 Mar 1996 04:00:00




>I've seen some articles that state using the login password for web
>authentication is a bad idea.  Something about the password going by in
>the clear.  How is this different from telnet?  Not that telnet is
>that secure, but our auditors have decided it's ok.  If you type your
>password into a browser authentication dialogue box it get's blended in
>with your name (whatever you type) and converted to mime-base64 and sent
>as clear text.  This seems no worse than telnet.

Actually, if anything the transmission of passwords is slightly more secure
than it is via telnet. I believe there are two issues that make auditors
nervous about web authentication:

* All browsers will cache the name/password combination for the duration of
the current session, sending it to the server automatically when a new
protected document is requested. This means that the cleartext password may
be readable in a core dump, and that it is sent many times during the course
of a single session.

* While there is no easy way for a user creating pages on a server to capture
the password the user entered to authenticate for the server, it is possible
to transparently redirect the browser from a trusted server to a compromised
server and have them authenticate to that server instead, which could log
the password information.

Quote:>The plan we were working on was to create a 4.4bsd DB file that Apache-SSL
>could use.  This file would hold around 27000-35000, depending on time of
>year, records holding the encrypted login password.  The .db file would
>be owned by the "www" user, and only accessable by that user.  We would
>use a slightly modified mod_auth_db module to access it for User and Group
>information.  Is there some way this file could be leaked if we keep it
>out of the "htdocs" directory?

NCSA includes dbm-based password authentication in the stock 1.5 distribution.
It is important that the user used to invoke the server and open the access
control file (often root so port 80 can be bound) is _NOT_ the same user that
the server uses when executing CGI scripts or accessing documents.

Quote:>We'll want to be able to authenticate SSL and Non-SSL accesses.  With so
>many people it's appealing to tell them all they can use their login password
>for web access.  We'd like to be able to make things like class grades
>available through the web.  If this is a bad idea, can someone tell me
>why it's a bad idea?

This is not a bad idea, if implemented carefully. There is one major caveat:

If confidential information is to be served by a web server, it should
be dedicated to that purpose, and only person's who should have access to
that confidential information should be able to create and modify documents
and CGI scripts on the server.

The problem is that any user who can create a server-parsed document or
CGI script under the web server can easily gain access to all the documents
and scripts available to it.

 
 
 

Authentication using login passwords a bad idea

Post by Ben Lauri » Sat, 16 Mar 1996 04:00:00



> I've seen some articles that state using the login password for web
> authentication is a bad idea.  Something about the password going by in
> the clear.  How is this different from telnet?  Not that telnet is
> that secure, but our auditors have decided it's ok.  If you type your
> password into a browser authentication dialogue box it get's blended in
> with your name (whatever you type) and converted to mime-base64 and sent
> as clear text.  This seems no worse than telnet.

You are correct. It is no worse than telnet. I don't know what your
auditors mean by "ok", but telnet does not fit my definition of OK in a
secure context.

Quote:

> The plan we were working on was to create a 4.4bsd DB file that Apache-SSL
> could use.  This file would hold around 27000-35000, depending on time of
> year, records holding the encrypted login password.  The .db file would
> be owned by the "www" user, and only accessable by that user.  We would
> use a slightly modified mod_auth_db module to access it for User and Group
> information.  Is there some way this file could be leaked if we keep it
> out of the "htdocs" directory?

Sure ... Bad Guy watches someone login to your Web pages. Bad Guy then
logs in using telnet and the stolen password/username. Bad Guy then
exploits one of many hacks to gain superuser access [whether there is one
available to him depends on your OS and how up-to-date with CERT etc. you
are - but clearly you have opened up a bigger can of worms than mere
access to "protected" pages], Bad Guy then does Bad Things.

Of course, if you permit external telnet connections, then the Web makes
it no worse.

> We'll want to be able to authenticate SSL and Non-SSL accesses.  With so
> many people it's appealing to tell them all they can use their login password
> for web access.  We'd like to be able to make things like class grades
> available through the web.  If this is a bad idea, can someone tell me
> why it's a bad idea?

> thanks!

> Ron
> --

> University of Delaware Information Technologies/Network and Systems Services
> Computing Center/192 South Chapel Street/Newark DE, 19716
> pgp finger print: 0D 73 06 6F D3 6A 99 D3  F5 D5 6E FF 3B B9 7C 2C

--
Ben Laurie, * Consultant and      | Phone: +44 (181) 994 6435
Technical Director, A.L. Digital Ltd,     | Fax:   +44 (181) 994 6472

 
 
 

1. Password aging - Is it a good/bad idea?

At my site some people have expressed an interest in forcing users to
change their passwords once a month. Based on my personal experience, I
don't think this will help the security of our system.

I have found that on systems where password aging is used, users are more
likely to pick easy passwords so that they don't forget them. They start
using passwords like "doggy1", "doggy2", etc...

Have any papers been written on the merits or problems with password
aging? I would like to find something that either changes my opinion that
password aging is a bad idea or that I can show to my boss and convince
him not to implement password aging on our system.

Any suggestions or opinions would be appreciated.

///////////////////////////////////////////////////////////////////////////////
Celia Clause

2. Using Removable Devices with Blocksizes > 1024 Bytes

3. Apache Authentication Accepting Bad Passwords

4. SUNOs and solaris?

5. Using an NT Primary Domain Controller for password authentication

6. Wanted: "Striped Down" Telent mechanism

7. any way of making login have less or more bad password attempts?

8. problem in cshell programming.

9. (PPTP VPN) Using samba/unix password for CHAP Authentication

10. Slow password authentication using Samba

11. using a unix password file for limited authentication to http and ftp possible?

12. Leafnode unable to connect using Secure Password Authentication

13. User authentication using UNIX password file with Apache