Which method is better (safer) for authorizing users?

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
Galt
Forum Newbie
Posts: 18
Joined: Thu May 22, 2003 8:08 am

Which method is better (safer) for authorizing users?

Post by Galt »

I'm using a php to authorize users on a website I'm building. Right now I use header("WWW-Authenticate: Basic") method to get the username and password. As you know, this pops up a window that asks for the user login info.

But I was thinking that if I had a form on a webpage, I could make the login look much 'prettier'. I'd have to use the $_POST method to retreive the username and password in that case.

My question is whether one of these methods is more secure than the other. I'm new to php, and since I didn't know better, I thought the former method was more secure, and built the page that way. But now that I have a little more of the website done, I would really like to have the login as part of my first page, as a form. Anything insecure about doing it that way?

Thanks for the help.
Last edited by Galt on Wed May 28, 2003 9:56 am, edited 1 time in total.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Both WWW-Authentication: Basic and non-SSL webform are very insecure.
Both methods send the username and password in cleartext across the network.

That being said, a web-form approach is probably better because its generally simpler to deal with adding users to a database than to a system file and lets you preform application-based security without duplication of effort.

There are a few JavaScript tricks for hardening a non-SSL login form. I wouldn't trust them myself, but they are better than nothing. I beleive they are mentioned in the client-side forum somewhere.
Galt
Forum Newbie
Posts: 18
Joined: Thu May 22, 2003 8:08 am

Post by Galt »

So all those websites that take passwords through forms (even this site) send the password back to the server in cleartext? 8O
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Yup, unless its https and you see the little lock/key/whatever icon then your username/password was sent in the clear.

Sites I run use SSL to protect the users, even if most of them are only a self-signed certificate -- I don't pay VeriSign or someone else to verify that I'm who I am for most applications. I'm not doing e-commerce; most of my users know me personally and trust me on security issues at least, those who don't know of me and seem to trust me as well.
Galt
Forum Newbie
Posts: 18
Joined: Thu May 22, 2003 8:08 am

Post by Galt »

Thanks for your help, I really appretiate it. I guess my next task is to enable SSL and then I can make my form login page.
User avatar
mrvanjohnson
Forum Contributor
Posts: 137
Joined: Wed May 28, 2003 11:38 am
Location: San Diego, CA

Post by mrvanjohnson »

Usually I encrypt passwords and sometimes usernames in MD5 format before passing it anywhere. Not sure how much good this does because it's still in clear text, but at least it's not readable anymore.

It takes a little extra time to set up because the users need to be created in the database with MD5 encryption. Seems to work pretty well to protect from the casual sniffer. Also, if someone manages to get your database, it's not much good to them because the only information in there is MD5 encrypted usernames and passwords. Again, I wouldn't trust my bank to use this method but for your hobby and low end security needs it works.
Galt
Forum Newbie
Posts: 18
Joined: Thu May 22, 2003 8:08 am

Post by Galt »

mrvanjohnson wrote:Usually I encrypt passwords and sometimes usernames in MD5 format before passing it anywhere. Not sure how much good this does because it's still in clear text, but at least it's not readable anymore.

It takes a little extra time to set up because the users need to be created in the database with MD5 encryption. Seems to work pretty well to protect from the casual sniffer. Also, if someone manages to get your database, it's not much good to them because the only information in there is MD5 encrypted usernames and passwords. Again, I wouldn't trust my bank to use this method but for your hobby and low end security needs it works.
If I understand you correctly, then your server does the encrypting of the usernames/passwords, since php is server side. But the password still has to travel from the client's browser to the server. Isn't it still in cleartext then? Once it gets to the server, then making a hash of it and working with that provides security from people hacking your db and retreiving all the passes. But for the journey from the client's browser to the server is still insecure (besides SSL, which seems to be the only protection.) Client side code could be used to make a hash of the user/pass and then send that (which is what an ideal situation would be), but that requires javascript being enables. And that just leads to more problems. So in a situation where you want the process to work guaranteed, the best choice would be SSL + post/get variables or the www:authenticate method. Correct?
Post Reply