l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 Mar 16 00:57

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] htaccess and encrypted passwords
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] htaccess and encrypted passwords

On Wed, 16 Mar 2005, Peter Jay Salzman wrote:
>    AuthType      Basic
> I've read that it's possible to make this more secure than sending a
> password uuencoded over the net.  I've seen references to md5 protecting the
> password, but the documents I read said that no browser supports this.
> Is this true?

It's true.  Or at least I tried it and I couldn't get it to work so I gave
up on it.

> Any other way to make this reasonably more secure?

HTTPS/SSL is the way to go, of course.  Problem is you gotta pay to get an
authority to sign your server's keys otherwise the visitor gets
"unverifiable key" messages.  It's not a problem if your visitors know
what they're doing.

Here's another method: Some people use Javascript/PHP solution.  They
create a website with a login screen, and upon clicking "submit" a
javascript code encrypts the password and sends that data along with the
username to the server, where a PHP/ASP/CGI code checks the encrypted
password.  You can probably find a cookie-cutter Javascript code for this
on the web somewhere.  Future sessions need to be kept track of in this
case, though, otherwise you gotta keep logging in everytime you want a
protected resource (and you gotta code the server to keep asking for the
username & password.)

Even if you implement all that, you can't stop there since all that does
is protect your cleartext password, not the server -- otherwise someone
who can see the transaction can login to the account using the encrypted
password (it doesn't matter if they can't see the actual password as long
as they know what string to send to the server.)  To protect the server
and the user's account, the server should send a challenge to the client,
and the client should respond with an appropriate key, to link the
recipient to the server[1].  Here's one way:

   1. The server generates a login webpage.  The login page
      is uniquely stamped with two Javascript variables called
      "key" and "value", a key-value pair that the server also
      keeps track of.

   2. The user types in username and password on the webpage
      and clicks "submit."

   3. The Javascript code reads the password, concatenates with
      the "value" from #1, and MD5s it.  The JS code sends the
      username, the MD5 password+value, and the key to the server.

   4. The server reads the key, finds the corresponding value in
      its database.  The server also reads the username, and finds
      the corresponding password in its database.  It concatenates
      the two and MD5s it, and compares the result with the MD5
      sent from the client.

   5. If the two MD5s match, login the user and keep track of the
      client's session.  Otherwise reject the login request.

This is still not secure since the server is vulnerable from anyone trying
to access the website using the client's session ID.  To prevent that, you
need HTTPS/SSL or some sort of constantly secure connection, not just a
connection that verifies and protects the login process.  (If you really
really want to, you could probably use Javascript/PHP combination to keep
the entire session encrypted, but it's not a very fun thing to do.)


[1] It's interesting to note that Leslie Lamport of the LaTeX fame came up
with the concept of "Challenge-Response" in security context.  The example
I give here is different from Leslie Lamport's original idea, though.

Mark K. Kim
AIM: markus kimius
Homepage: http://www.cbreak.org/
Xanga: http://www.xanga.com/vindaci
Friendster: http://www.friendster.com/user.php?uid=13046
PGP key fingerprint: 7324 BACA 53AD E504 A76E  5167 6822 94F0 F298 5DCE
PGP key available on the homepage
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.