|
plain text passwords over HTTP
Hi. I am playing around with the whole content-management-via-php-and-mysql thing.
I have been trying to wrap my brain around the concept of having users log in securely (using PHP sessions).
The common wisdom on logging in securely seems to be that the user enters their name and password via an HTML form that POSTs this data in plaintext to a php script on the server. Then this script encrypts the password with md5() and compares that to a password that is stored in the database under that username using the same md5() encryption. If these hashed strings are equal, then it's the correct password.
That seems simple enough, but I am thinking that the password being transmitted over the wire in plaintext kinda defeats the whole purpose of having them encrypted on the server in the first place -- if a hypothetical person with malicious intent could see this POST data, they would have the user name and password in plain text!
Am I missing something here?
Would one have to use SSL (https://www....) to be totally secure in this context?
(I am only familiar with php at this point, but I assume the same principles apply to asp, perl, etc.)
Thanks everyone.
Jordan Lev
Thursday, January 22, 2004
Here's one way around that scenario:
1. Users requests logon form which is generated by the script on the server. At this time, server creates random number and puts it as a hidden variable in the form and remembers this number is associated with this IP.
2. User enters password on web form and javascript code encrypts the random number using the password as the key for the encryption. HTML page then just transmits encrypted random number.
3. Server receives encrypted number and computes its own encryption based on the original number using the real password. If they match, login is successful.
The downside here is the server needs to know the real password. So it can't be stored encrypted.
mhp
Thursday, January 22, 2004
mhp:
Could the passwords on the server also be stored in an encrypted manner?
When a compare is needed - the passwords stored can be decrypted to do a match.
Will this be feasible?
Ram Dass
Thursday, January 22, 2004
> if a hypothetical person with malicious intent could see this POST data, they would have the user name and password in plain text!
Actually, even if the data wasn't in plain-text, it would still be dodgy. For example, imagine a scenario where you apply the md5 hash client-side, say in JS, and send over the hashed password. It's fine you think, nothing is plain-text.
A malicious person intercepts this hashed data, produces their own client i.e. page that sends this hash. If this hash is the only source of verification, then the malicious user can login without necessarily knowing the password as the security data i.e. the hash is the same.
SSL, however, would handle this issue.
SC
Thursday, January 22, 2004
>SSL, however, would handle this issue.
... as would mhp's solution.
SC
Thursday, January 22, 2004
.. which is a variant of Digest authentication. Which unfortunately doesn't work very well.
mb
Thursday, January 22, 2004
(that is, the current web brwoser client and server implementation is hard to use. doing it yourself in jscript should work fine)
mb
Thursday, January 22, 2004
mhp - what happens when the user is on a client farm (a la AOL or earthlink) and are unlucky enough to have a different IP send their POST than sent their GET?
How about associating the random number with a GUID that's also sent to the client (and back again) to look up the random number when the post arrives?
GersonK
Thursday, January 22, 2004
The whole system is intrinsically insecure and nothing can be changed to fix it. There is no such thing as privacy or secrecy on the internet. Or even on a desktop computer isolated from all networks. If you act as if everything you do is being monitored by nefarious elements, you'll be fine.
Dennis Atkins
Thursday, January 22, 2004
"How about associating the random number with a GUID that's also sent to the client (and back again) to look up the random number when the post arrives?"
But then it's the same problem. The attacker has the encrypted password, the GUID & the Random Number. Everything to impersonate the original person again. Associating with the IP is what made the original solution "secure."
Dignified
Thursday, January 22, 2004
Not really.. associating with the IP is no more secure than the GUID. The hacker could spoof the IP.
But just do this... Once the GUID is used, the random number associated with you is deleted from the db. So then when the poser hacker comes back later posing as you, with your encrypted number and the GUID, its no longer in your database.
mhp
Thursday, January 22, 2004
"The hacker could spoof the IP."
Which is exactly why I had the "secure" in quotes. ;)
I see no problem with your deleting-random-number-after-GUID-use, but I am not a security buff by any stretch of the imagination.
Dignified
Thursday, January 22, 2004
I am trying to keep things as simple as possible; so it seems that SSL is the way to go.
I'd like to avoid using javascript, and passing random numbers back and forth seems like it's just adding complication which could cause unforseen holes in the future. But I must say I am impressed with your crafty-ness, mhp -- using the password as the encryption key!
Thanks everyone.
Jordan Lev
Thursday, January 22, 2004
Me neither. I'm sure there's a flaw.. I just remember that's how BlitzMail used to do it when I was in college (I think) and it's been in use for a LONG time.
mhp
Thursday, January 22, 2004
the question is always what you're trying to secure against. if you hash the password every time with a different key, it's difficult for the man in the middle to decrypt it, and if they key is valid only once, they can't replay it either.
mb
Thursday, January 22, 2004
Out of curiosity, are there a lot (or any) documented cases of this being done?
I'm not trying to say "don't worry about it" - I'm just honestly curious.
Philo
Philo
Thursday, January 22, 2004
Yahoo! uses some guy's free javascript crypt implementation:
http://pajhome.org.uk/crypt/md5/
view source on
http://mail.yahoo.com/
another screen name
Thursday, January 22, 2004
While I think the IP attached process would be fundamentally broken (because a lot of people are behind mega proxies, and have a different IP on each request), I think the possibility of IP spoofing is vastly overblown -- You can easily spoof the source on UDP packets because it's a one way transfer, but unless you're on the upstream ISP of the destination, it's pretty much impossible to spoof an IP over the connection-oriented TCP -- packets have to return to you to continue the conversation, and obviously the infrastructure will route them to the actual IP address.
Dennis Forbes
Thursday, January 22, 2004
And, let's be honest: if you have the power at someone's ISP to inspect, inject, redirect, and halt packets, then it seems like a man in the middle attack is much easier anyway.
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, January 22, 2004
Do they really have to associate the random number with a given ip, guid or even computer? Associate it with a given time frame i.e. rand number was issued and valid for a fixed amount of time, and invalidate it when used.
SC
Thursday, January 22, 2004
I second the "can't use an IP address". I've been burned by the mega-proxies myself... the IP of an AOL user, for instance, will vary _while_ a page is being fetched (e.g., images on the page).
dir at badblue dot com
Thursday, January 22, 2004
If the passwords are for something fairly inconsequential, like identities on a message board, just do the plain text and don't worry about it. Still, do store hashes on the server, because it is easy to do, and attackers would only have a window of a couple seconds to intercept the password over the Internet. Whereas having it stored on a server leaves it exposed for days, weeks, or months.
If the passwords are for something that really matters, use SSL.
T. Norman
Thursday, January 22, 2004
As a general rule: do NOT attempt to roll your own encryption or authentication scheme. The people who design and implement crypto and authentication are experts who have deep knowledge of attack techniques and ways to mitigate them. You WILL make mistakes and you will implement an insecure system. (Mike Howard jokes that people who try to implement their own security systems end up writing encraption algorithms...)
There are cheap, standardized, heavily tested, robust systems available "off the shelf". Figure out what your security needs are, figure out which off-the-shelf solution meets your needs, and use the right tool for the job. That will be much cheaper and safer in the long run.
Eric Lippert
Friday, January 23, 2004
Eric, I am most definitely *not* a security expert, and I wholeheartedly agree with you that it is best to use what's already out there and proven.
Could you please share with the group your experience with any off-the-shelf systems that you've used or come across? I know I know, "right tool for the right job", but what are some tools you've used and for which jobs?
[This same question goes out to everyone, of course].
For my job here, it's a VERY simple website for an artisan to show off wares, which are updated very infrequently. Money will be handled via paypal, so we don't need super-tight security. Based on the comments on this board, I am thinking that the plaintext password, hashed in the database, will be 'secure enough'.
Thanks again everyone who replied.
Jordan Lev
Friday, January 23, 2004
I suggest using SSL if possible, if only just for the fact that [some of] your users will feel more comfortable seeing the little "secure" icon in the corner of their browser.
Richard P
Friday, January 23, 2004
What I find helpful is to list the _threats_ and the _vulnerabilities_ -- that usually clarifies what the problem actually is.
Let me give you a real-world analogy. I've got this old house with a TV in it. What are the security threats? Bad guys who want to steal my TV are the threats. What are the vulnerabilities? The windows, the doors, the locks, the housemates being careless with their keys...
OK, now that I know what the threats and the vulnerabilities are, what tools decrease vulnerabilities and thereby mitigate threats? Better locks. Stronger windows and doors. Attack dogs. Alarm systems. Cameras. Insurance. A well-funded police force.
Note that the mitigators prevent (locks), detect (alarms) and clean up after (insurance) attacks.
OK, now that I know what the possible tools are, I can evaluate the cost of the tool vs the cost of the thing I'm protecting. It makes no sense to spend $1500 on an alarm system that protects a $500 TV.
In your case, what are the threats? Do the attackers want to impersonate users, steal data, corrupt data, trick users into thinking they're using your site when in fact they're using someone else's site, what? How is your site vulnerable to those threats?
Once you know what the threats and vulnerabilities are, you can start evaluating solutions. SSL mitigates eavesdropping, spoofing and replay attacks. Password systems mitigate "bogus user" attacks. Auditing systems help you discover attempted or successful attacks and track down the culprits. Backup systems help you get back online quickly after a successful attack.
Once you know what the tools are, you can evaluate their costs compared to the value of the stuff you're protecting.
Eric Lippert
Friday, January 23, 2004
Why does everyone says Digest authentication doesn't work in these discussions?
It seems to work: http://www.cafeconleche.org/news2004.html (Saturday, January 10, 2004)
gunga
Saturday, January 24, 2004
3 reasons for using custom stuff in the browser (e.g. username/password field on an HTML page over HTTPS):
1) not all browsers support digest auth correctly.
2) not all server environments let you access any HTTP authentication information easily (basic, NTLM, digest, etc.).
3) not all users like the HTTP authentication user experience (typically some sort of password dialog box thrown up by the browser).
mb
Saturday, January 24, 2004
 Recent Topics
Fog Creek Home
| 
