Ok firstly I would like to ask about SESSIONS. Right now, I have set 2 sessions after registration, id_member and password_hash. I am wondering if i have to check them everytime user (who already logged in) visits my page, if data is correct?

Another question. Should I put sessionid() into browser bar, is it because some mobile phones and other devices don't support other session transfer? Should I regenerate it and when?

Ok and last one. If I salt my pass and passSalt store in database for each of users, then I need first access the db with username, take salt, check pass and return value? Or I'm salting in wrong way?

This post has been edited by Dancia: 27 Jun, 2008 - 01:41 PM

sessions are deleted after a browser is closed (in most instances.. certain browsers, like firefox, have managers that can restore sessions)... If you want to use them to make sure someone is logged in, you should check the username and password against your database and make sure they're logged in...

if you're salting your data, when you take their password, and add your salt to it, all it does is make it longer and harder to crack... if you're using it in a login system, you just add the salt to the password either before or after you MD5 it... before is more secure though, as it can make weak passwords much stronger...

Your main security with sessons comes from fixation/hijacking.

Fixation is where someone gives some an address to go to which contains the session id in the url or in a form field depending on how your site operates, then they have your session id, because they assigned it to you.

Hijacking is getting the session id of a user, say though xss.

With both methods they edit their cookies or send a var or whatever to take control of your session after you logged in, so becoming you.

I have a session security script on here if you want to check it out.

Salts should not be stored in the database, or not on the same database/user. The salt makes it difficult to crack, because it makes the hash not a dictionairy word, it is all about if someone extracts the hashes from the db.

I have a series in the tutorial section about creating a professional login system, it talks about secure hashing and encrypting

Yeah I know that session id is stored into cookie for client. But im talking about something else. For example if I set $_SESSION['logged_in'] = 'yes'; can someone manipulate it and change yes to something else? Because I have set $_SESSION for username and password and checking it after every activity.

Erm and about salting. So I guess I shouldn't put it into db. But then how? Maybe try to to create unique encode and decode functions so I don't have to check database or any files?

(currently my sessions are stored in db)

no, only scripts on your site can change the sessions... so unless someone hacks into your server and changes the scripts that way, you'll be fine...

You should hardcode the salt into the PHP script... so try it like the following:


at the end of this script, the password is "JBrace1990r4785h8907c4j67v69586vh9oh45"... if you MD5 this, it will be much harder for someone to crack because of the salt and the length of it...

for the sessions, what do you mean "stored in the db"?

^ You can store session data in a database, for protection against shared hosting environments.

Like JBrace said, only you can manipulate session data, unless you are putting variables into the session that are modified by the user, or unless someone gains access to your server/database in this example.

Also like he said, you hardcode the salt into your script. The salt is to protect the hashes in the database, and although some might argue if someone hacks into your server they would have access to the salt, that is irrelevant.

Here is why.

1) If someone hacks into your server they can change your code to store/mail passwords in plaintext (before encrypting/hashing).

2) SQL injections run commands on the sql daemon (unless you have some stored procedures like mssql that allows shell access) so a successful sql injection, may not have access to the filesystem, so discovering the salt will be near impossible.

Best practice for storing pass' in sessions or database:
1) Take the password and add a salt to it
2) Use a strong hash like sha512 to hash it, then store it
3) When comparing passwords , salt them the same way, and hash them the same way, then compare them.

Check out my tutorial, it has methods for hashing with sha512.

if you really want to overkill it though, you can hash it in like 12 different ways over and over again, then no one will get it =p

of course that is being very paranoid, but nonetheless, it works ;P

Ok, so I made useless job by checking $_SESSION['username'] and $_SESSION['password'] on every activity?

yes, generally you do not want to store the password, even encrypted in a session/cookie or anything. The only need for it is authorization.

Instead, after successfully logged in, store the username for ease, and store a special key like $_SESSION['is_authed'] = true; and just check to make sure it is true.

Erm but I do have to get user data from mysql on activity or should I create something like 'is_updated' and only then reupdate user, for better performance??