homepage Welcome to WebmasterWorld Guest from 54.196.196.62
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
Encrypting passwords with mySQL/PHP
is encryption necessary?
roldar




msg:1285931
 2:32 am on Jul 31, 2004 (gmt 0)

I've got a site where users have to register. I don't handle credit card information, but I definitely would not like there to be any security issues.

Should I encrypt their passwords, or is that necessary?

Is it hard to do with mysql/php? How can you check a password entered in the login form with an encrypted password - is there some kind of de-encrypt php function?

Any help would be appreciated, and I thank you in advance if somebody could shed some light on this for me.

 

Birdman




msg:1285932
 2:48 am on Jul 31, 2004 (gmt 0)

I'm interested in this topic as well!

From what I can remember, it goes like this:

1) password stored in database
2) password encrypted in cookie with md5 hash

And, I think, md5 hash requires a key. It is not decryptable(is that a word?). Keep this key in a safe place! Then you call db, md5 the password with your key, and compare it to the cookie.

Not sure if that's right, so stay tuned...

Birdman

So, you keep your

jatar_k




msg:1285933
 3:51 am on Jul 31, 2004 (gmt 0)

md5 [ca2.php.net] is one way encryption which is not subject to decryption.

If you are really excited you can read the The MD5 Message-Digest Algorithm [faqs.org] ;)

It really depends on what your business is and you must decide for yourself what lengths you need to go to for your users protection. The key is to take all reasonable measures to protect the data. This is where the fun of personal privacy laws come into play. Also remember that you are only legally allowed to require information from your user which you NEED to do business with them.

So...

Your user must enter said information and you are going to store it. How are you going to protect their information? You need the information to be accessible by the person who entered it and only the person who entered it. This would require some information that only the user knows. How can you acquire this information and how can you store it.

HTTPS

Again, this depends on what type of information you will be storing. The first thing involved is to get a secure certificate for your site and only transfer sensitive, or personal, user data over an encrypted connection. I have always gotten secure certs from Thawte and always been satisfied. One thing to note is the form itself does not need to be under https but any form action does. As long as the form action is https then the secure connection is established before any data is sent. I've spent a lot of time sniffing this scenario to be sure that it is 100% true.

User Account Access

There will need to be a way for users to access their account. Most often this will consist of a username and a password. Usernames should be unique. This will allow the username password combination to be unique and be the first line of protection against account hijacking. Depending on the type of data you are storing, two fields that make up your unique combination may not be enough but for our explanation here we will use only the two fields.

Password Protection

I realize I am only now getting to the heart of your question but, in truth, all of these things play a prt in it.

Passwords should never be stored on your system in plain text or in a decryptable form. MD5 is a one way encryption and is an acceptable method of storing passwords. There is absolutely no need for your users passwords to be accessible by you or anyone who works for your organization. A password can always be reset by the user or by you or your employees. You must encrypt the password when it is received and then store the encrypted password in your database. This makes sure that the password is useless in the form in which it is accessed straight from the database.

Your form that takes the password should post to script which does something similar to the following. Ensuring the username is unique and that the password is protected.

$sql = "select * from usertable where username='" . $_POST['username'] . "'"; 
$result = mysql_query($sql);
if (mysql_num_rows($result) >= 1) {
$error = "please enter another username";
include "userform.php";
exit();
} else {
$username = $_POST['username'];
$userpass = md5($_POST['userpass']);
$sql = "insert into usertable values('$username','$userpass')";
mysql_query($sql);
include "postregister.html";
}

You now have a stored password which is useless to you and only usable to the user through your login form.

User Login

Sessions or cookies are good methods to keep your user logged in and to be able to recognize them in your scripts. You must put some thought into how you are going to do your authentication and how you are going to stop the ability to hijack active sessions or hijack cookies.

A simple login script may go something like the following. Once again the form you use for your login should have an action that is under https or be under https itself. I will use a session based example.

session_start(); 
$username = $_POST['username'];
$userpass = md5($_POST['userpass']);
$sql = "select * from usertable where username='$username' and password='$userpass'";
$result = mysql_query($sql);
if (mysql_num_rows($result)!= 1) {
$error = "Login failed";
include "loginform.php";
} else {
$_SESSION['username'] = "$username";
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
// any other data needed to navigate the site or
// to authenticate the user can be added here
include "membersection.php";
}

User Authentication

Now an important factor is to be able to reliably recognize the user once they have logged in and to make sure that user is using their own session. In our above example we included the ip of the user to add some extra security. An authentication script would need to be included at the top of the page on every single page inside the members section of your site.

A simple authentication script could be as follows.

session_start(); 
$newip = $_SERVER['REMOTE_ADDR'];
if (!isset($_SESSION['username'])
empty($_SESSION['username']) $newip!= $_SESSION['ip']) {
include "logout.php";
}

All of the above scripts are very simple and greater means may need to be taken to protect and authenticate your users but those three scripts are the basis of a user management system. You would also need to provide a method for your users to reset and acquire their passwords if need be. Passwords should always be reset in some random fashion and then the user should be forced to change it before they continue using your site.

That may be a little more than you asked but I felt these were all important issues. I hope I still answered your question in there somewhere. ;)

Read the Peer Code Review [webmasterworld.com] (msg 1 - 4) of this post as well

[edited by: jatar_k at 8:32 pm (utc) on June 16, 2005]

roldar




msg:1285934
 4:17 am on Jul 31, 2004 (gmt 0)

Thank you very much for that post, jatar_k. It was more helpful than you can imagine. It brought some important issues to my attention that I hadn't considered.

One question I have now is regarding the session authentication. Somebody once told me that AOL and some other ISP's change the IP address several times while a person is online. Is this a serious issue? I would hate for a user to enter a lot of information and try to save it, only to be redirected to the login screen because their IP was changed.

jatar_k




msg:1285935
 4:24 am on Jul 31, 2004 (gmt 0)

I haven't had any trouble with it at all.

dialup users get a new ip everytime they connect.
Many AOL users will share the same ip but won't be able to access the session.

Session timeouts are also very important. Again, it depends on what the user is logging into but users that are inactive need to be logged out at some point. You could store a timestamp in the session and force it to time out every 10 mins if you like or it could be 30 mins.

If you keep session timeouts on a shorter time period the likelyhood of a user sharing the same ip being able to hijack a session is less likely.

roldar




msg:1285936
 4:40 am on Jul 31, 2004 (gmt 0)

I have the misfortune of starting out on a shoestring budget. Is OpenSSL or some other open-source SSL a viable alternative to Thawte certificates? I've never really understood why a third party needs to issue certificates. Couldn't somebody just build some cryptography software for servers? Or is it a legal issue?

I'm afraid I'm new to programming and especially security issues, so I'm not sure exactly what HTTPS secures. Does it secure things on the user's end, or does it secure them on my server? Who or where along the line does it prevent interception or the deciphering of intercepted data?

For a lot of major websites that I log in to, such as Yahoo, I notice that they don't have a secure login form as the default. They often have a link to a secured login form... why wouldn't they just secure it by default?

If I don't get a secure certificate, could some hacker intercept every username/password input on my forms? Or would a hacker have to have compromised each individual user's computer/internet connection in order to get that information? I would hate for any user's account to be broken into, but if it's difficult to do and requires a security failure on their end, then I might be able to justify holding off on SSL in the beginning because I could just fix one or two breaches if that's all I had to worry about. But if a hacker could potentially break into everybody's account because of a failure on my end, I would probably be forced to get a SSL certificate before I launched the site.

Users won't store any highly sensitive data on the site. The worst information that any hacker could glean from inside an account is the email address of the user. But I want to make sure I do everything within my ability to make sure even that doesn't happen.

jatar_k




msg:1285937
 4:50 am on Jul 31, 2004 (gmt 0)

well, as I mentioned, it always depends on the information you are storing. If the only data you have is an email address, https probably isn't even necessary. You also have to consider what type of information it gives the user access to. Is it just a forum? Who cares. So an account gets hijacked, an Admin can fix it.

I work with money, I take these things very seriously. Most sites don't need to go to the lengths that I spend every day analyzing. Third party certs are fine for most.

The thing you have to remember about hackers, there needs to be something worth doing or stealing.

From what I gather about your site you probably don't have to worry too much about certs and insane levels of security. The baseline scripts I outlined above might even be a little over the top. I just see these questions a lot and think that people need to really sit down and think security issues through before they start programming and then keep it in mind every day the site is live.

The issues I deal with daily are absolutely ridiculous, I rework security scripts all the time. There will always be someone smarter than us and no system is ever secure.

The key to the level of security is all reasonable precautions if its only an email address, https and high level security isn't reasonable.

make sense?

RonPK




msg:1285938
 9:44 am on Jul 31, 2004 (gmt 0)

> I've never really understood why a third party needs to issue certificates.

The third party verifies the identity of the site owner. Thawte actually called me to check whether the information I sent them was correct. That way a visitor can be sure about where the information goes.

roldar




msg:1285939
 10:32 pm on Jul 31, 2004 (gmt 0)

I've finished implementing most of the above suggestions, and I feel a lot better about the security of my data.

The only difficulty I'm having now is figuring how how to implement a "forgot password" function. I only require a username, password, and email address from users.

Having only these three fields, does anybody know of any secure way to help a user get a new password emailed to them? Without, of course, giving malicious users the ability to go around resetting every user's password that they know the email address for. I could always add a "secret question/answer", but I know how much I dislike entering things into those fields.

jatar_k




msg:1285940
 11:20 pm on Jul 31, 2004 (gmt 0)

Then put a nice little note over the secret question saying that you are trying to protect their accounts and it is required for things like "forget password".

Or you can just fire off the email and reset the password. Remember it is going to the email account they control. If someone gets their email account hijacked, that isn't your fault.

dreamcatcher




msg:1285941
 9:31 pm on Aug 23, 2004 (gmt 0)

jatar_k, thats some useful information you have posted. :)

Thanks

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved