Questions: Sessions, information storing and security

[Worqy]

Hi!

 

Insted of making alot of topics with just one question in them I decided to make a topic with all my short questions in it.

 

I'm trying to make a intranet type of website that is made for smaller communities to control users and keep their staff up to date.

 

Question 1

How should I store my MySQL username/password ? Right now I'm storing them in .php files and include them where needed. Is there a safer/better way to store them?

 

Question 2

A

Are session unique for every website? If website A has a session called "login" that is set to true can the user login to website B that also uses a session called "login" ?

If true, how should I keep my session unique ?

 

B

Are sessions a good/safe way to store login information? Information like "is the user logged in", "access level" etc.. ?

 

Question 3

How should I store critical user information like passwords ? Right now I'm using sha2 hash the passwords. Is that enough?

Should all the user information (username, email...) be somehow encrypted?

 

Any comments about website structure and/or security is welcome!

Edited January 25, 2013 by Worqy

[devilsvein]

Hey, I might not have the best answers but I'll give it a shot.

 

1) I think your fine there...if you have something like $username = .... and so on make sure you don't call them out when you don't need to.

 

2a) As far as I know sessions are unique on every websites and webpages on specific sites can only access the session if it has session_start(); at the top. For added security you could look into session hijacking and maybe encrypt sessions aswell. NEVER store passwords in sessions

 

2b) Its OK for temporary information. If you want to then store them for more future uses consider variables and also use html entities on the data to prevent any attacks.

 

3) For passwords you could use phpass. Thats one way which many people use as its highly encrypted. You could also use sha512 and add unique salts to passwords.

[requinix]

Wrote short and long answers to a couple questions, figured I'd expand on the others too.

 

How should I store my MySQL username/password ? Right now I'm storing them in .php files and include them where needed. Is there a safer/better way to store them?

Short answer: It's fine.

Long answer: It depends what parts of the server can be accessed by whom. Put them in the least-accessible place you can (within reason).

 

Are session unique for every website? If website A has a session called "login" that is set to true can the user login to website B that also uses a session called "login" ?

If true, how should I keep my session unique ?

Short answer: False.

Long answer: If the two websites are on the same server and same domain (and different subdomains), have access to the same files, and have the session cookie set to be shared across both sites, then it's possible/likely that it'll be shared. If that's the case then set up different session save paths for both sites.

 

Are sessions a good/safe way to store login information? Information like "is the user logged in", "access level" etc.. ?

Short answer: Yes.

Long answer: Assuming a user cannot edit files (or wherever the session data is stored) on the server then yes.

 

How should I store critical user information like passwords ? Right now I'm using sha2 hash the passwords. Is that enough?

Should all the user information (username, email...) be somehow encrypted?

Short answer: Kinda and nah.

Long answer: Someone will be along shortly to mention PHPass. Salt the passwords then hash them with sha256 or greater or another strong and slow algorithm (eg, bcrypt). If you're paranoid then HMAC is an additional option (basically it uses two salts), though it's easy enough to just do it so try and get in the habit now. The user information probably doesn't need to be encrypted but it depends on the sensitivity of the information.

Edited January 25, 2013 by requinix

[Sanjib Sinha]

To keep your password safe, you may consider using a good php application framework like Laravel where password is hashed and salted with Hash class. The Hash class uses the bcrypt hashing algorithm.

$password = Hash::make('secret');

The make method of the Hash class will return a 60 character hashed string.

Or you can make your own Hash class like them.

[Christian F.]

Long answer: Someone will be along shortly to mention PHPass.

Hehe, was that referring to me? In any case, I'm more than happy to oblige.

 

Worqy: As noted by requinix I recommend that you read this article about secure login systems, it will tell you how to properly construct a secure login system. (Besides its use of the global keyword.)

Another great resource for password hashing specifically, is this video by Anthony Ferrara:

 

Sanjib Sinha: No need to use an entire framework just to secure the passwords. Anthony's compatibility layer for the new password_hash () functions in PHP 5 is more than enough, if you're running PHP >= 5.3 and < 5.5.

[Worqy]

Thank you all for your answers!

I've had two tests at school this week so I haven't had time to try out anything yet.

I will post back on the weekend if I have some more questions.

[Worqy]

Should the salt be saved on the same place as the username & password?

 

Is current time + random letters + password a good salt?

Or how should I generate it?

Edited February 3, 2013 by Worqy

[kicken]

Should the salt be saved on the same place as the username & password?

 

It needs to be saved somewhere.  The same place as the username and password are stored is as good as anywhere else.  The salt is not sensitive information, it's just there to make sure the password can't be found on a rainbow table and to make it so anyone trying to crack it would have to re-generate a table for every user (which is time consuming).

 

Is current time + random letters + password a good salt?

Or how should I generate it?

 

That would be fine, you could just do a string of random letters to if you wanted.  I generate a string of 22 random letters for my salt values using a simple little function:

 

function GenerateNewSalt($len, $alphabet='abcdefghijklmnopqrstuvwxyz0123456789'){
$ret = '';
$alen = strlen($alphabet)-1;
if ($alen > 0){
	for ($x=0; $x<$len; $x++){
		$ret .= $alphabet[mt_rand(0, $alen)];
	}
}
return $ret;
}

[Christian F.]

Also, since there might be some confusion on the what the salt should consist of. I know I'm a bit confused as to what exactly you meant with your previous post.

 

The password should not be a part of the salt. Nor a part of the password. The salt is saved in clear text, after all, and thus you'd also expose the password (or a part of it) if you used it in the salt.

 

If you're talking about the hash operation: No need use the (current) time when hashing the password. In fact, I would recommend against it. Not only would you also need to save the time in the database, since it becomes a part of the salt, but it could also expose your script to security vulnerabilities. Using the exact time something has been generated allows attackers to perfectly replicate a PSRN-generator result. Which translates the random to predictable, and thus possibly unsafe.

Not that it has too much to say in relations with a salt, but when it comes to security I find it better to always be on the safe side.

Edited February 3, 2013 by Christian F.

[Worqy]

Thank you all for your answers!

 

Just to clear it up, when I asked if I should use the password in the salt I was thinking of using a salt (time + letters) + password to create a different salt that I would use to hash the password.

So the password isn't saves in the database, insted I would use the password the user inputs to create the new salt to compare the hashed passwords.

Edited February 5, 2013 by Worqy

[Christian F.]

Ah, I see. That would be a seed to create a salt, btw.

 

Anyway, I wouldn't have done it. Just to be on the safe side. Depending upon the implementation, you may expose the password, or parts of it, to the attacker. So it's best to leave the salt generation completely unrelated to the password.