What are Best Practice for some of these concepts?

[M.O.S. Studios]

Hey everyone,

 

I am working on a project for fun. This is a LAMP application that is going to run on my intranet server, and hold NO VALUABLE data. I am doing it just to get better at programming, and learn some best practices and techniques.

at this point, I am working on some things, and I don't know what the best practices are. Can someone help me go down the pest route? 

 

1. A log-in system and I want to include a "remember me" button. What is the best practice for this? Obviously leaving user data in a cookie is asking for trouble, so I was thinking of leaving a unique id of some sort?

2. Information in a login SESSION. What information do you put in a log in session? I have seen lots of different techniques on this. I don't really know which is the best. For the moment, I keep an array like this: array('Status'=>True, 'Username'=>'Users name"  ,'email'=>'users Email'). If a hacker can inject session information, this seems like it would be really easy to break, because they only need a user's name and email to gain access. Is there something more I should do?

3. Config file that holds Mysql Information. I made a file that contains all the values that might change over time. That way I only need to change it in one spot. In this file I have things like the Mysql Database information. Should these files be encrypted? Or can I use a .htaccess file to make sure it isn't accessible to a hacker (as I mentioned before, this isn't a project that's going live, its more of an exercise to help me learn)

 

Thanks everyone

[requinix]

1 hour ago, M.O.S. Studios said:

A log-in system and I want to include a "remember me" button. What is the best practice for this? Obviously leaving user data in a cookie is asking for trouble, so I was thinking of leaving a unique id of some sort?

You have a table for users, right? Add another table that has the user ID and a unique token. That token gets generated when someone uses the "remember me" option and gets stored in a cookie; it should have an expiration, both in the cookie and the database table, of however long you want it to last.
When the user visits the site and they're logged out, you can use that cookie to look up the user (as long as the token hasn't expired yet, of course). You should also do some other checks to make sure somebody didn't intercept that cookie and start using it themselves, such as by checking the user agent and/or IP address - though both of those can vary legitimately for a user.

1 hour ago, M.O.S. Studios said:

Information in a login SESSION. What information do you put in a log in session?

Mostly just the user ID. You can include other information, like the email, but if you do then you have to worry about what happens when the email address changes by a session on another device - say, they change their email on their desktop and later continue browsing on their phone. So it may be counter-intuitive but storing less data is good.

Hackers cannot inject session information unless they have direct access to your server, in which case you're royally screwed so it doesn't matter.

1 hour ago, M.O.S. Studios said:

Config file that holds Mysql Information.

If someone is capable of reading files on your server then encryption or a .htaccess won't do anything.

No private files should exist under your website's "public" directory (eg, public_html) at all. Configuration files, source code, and other things that aren't supposed to be directly sent to the user's browser need to be outside of that directory. For example, a good project structure would be

/path/to/your/site/
- config/
- public/
  - index.php
  - CSS files
  - JS files
  - images
- src/
  - your source code
- uploads/
  - uploaded files, if you do this
- vendor/
  - Composer files

Your site's DocumentRoot would be public/.

[M.O.S. Studios]

8 hours ago, requinix said:

You have a table for users, right? Add another table that has the user ID and a unique token. That token gets generated when someone uses the "remember me" option and gets stored in a cookie; it should have an expiration, both in the cookie and the database table, of however long you want it to last.
When the user visits the site and they're logged out, you can use that cookie to look up the user (as long as the token hasn't expired yet, of course). You should also do some other checks to make sure somebody didn't intercept that cookie and start using it themselves, such as by checking the user agent and/or IP address - though both of those can vary legitimately for a user.

 

Would this be safe? I believe its possible for one website to read cookies from another. Couln't they copy that cookie to access the site?

[maxxd]

You can set the domain (and path, even) for cookies.