On Wed, 16 Mar 2005, Peter Jay Salzman wrote:
[snip]
> AuthType Basic
[snip]
> 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.)
-Mark
[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
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
