Database Login Credentials

[Landslyde]

When I first started this project, PHP was new to me and I didn't have a clue how to use it. Here, seven months later, I still don't know what I'm doing.

 

I have 47 pages that are MySQL intensive. Each client has their own login credentials to the database. I've been using the $_SESSION global to carry these credentials across the pages. I realize this is a huge security issue, but I don't know any other way to keep their username / password handy as they log in and out of the database. I've searched and not found anything resembling my need here. Most of the discussions relate to setting $_SESSION['foo'] = 'bar' and carying that from page to page.

 

I cld really use some insight on this. Thanks.

[scootstah]

Why would each client have their own credentials to the database?

 

Typically your application should have a single set of database credentials.

[benanamen]

 I am hoping you mean credentials to the application as in a users table in the app DB, which if the case, $_SESSION is how you would do it although putting the password in a session is not what you would do.

 

You could do like

$_SESSION['login'] = 1;

And then on your pages check to to see if $_SESSION['login'] isset .

 

 

If you actually mean credentials for a Mysql connection  (Yikes! ) then you have some work to do.

(As in $con = mysqli_connect("localhost","my_user","my_password","my_db")

Edited October 4, 2015 by benanamen

[hansford]

Typically a user logs in with their username and password and then a session variable is set which identifies the user. No need to place passwords in a session variable. There is only going to be one user with that username.

[Jacques1]

Even if there was a sane way of keeping the database credentials in some kind of session, it's still an awful idea to let end users choose passwords for internal database roles. Many people routinely use passwords like “123456”, and you certainly don't want that as a database password.

 

End users are not database administrators (unless you're implementing some kind of PHPmyadmin), so it's your job to create an abstraction layer between the application users and the database roles. It does make sense to use separate roles for different user groups (e. g. standard users vs. administrators), but it's nonsensical to create a new role for each user.

[Landslyde]

Like I said, guys: I'm new to this. I get what you've all said. Even in the beginning I thought of doing it this way. But for some reason I got stuck on all the clients needing their own logins, and that made for a lot of extra work. It isn't all bad though, because I learned a whole lot in the process. And today, I learned a better way. I appreciate all of your comments. Thanks.

 

Time for a new pot of coffee so I can start untangling this mess I've made!

[ginerjm]

You've been trying to pick up PHP for seven months and apparently haven't read a single thing on logging in and secure methods and good practices?  What HAVE you been doing for those seven months?

 

NEVER carry a password around.  You handle a password only for as long as it takes to get it from the user's entry into a login form and create a query to check the db. If the check passes you set a token that tells you who they are (user id?) and that they are logged in (as mentioned - $_SESSION['login'] = 1) or if necessary a token that gives you a value that translates to a security level if your appl requires that to be known.  Then you forget the password.  You'll not need it again.  And god forbid - you will not design your appl to 'help' the user by "remembering" his password.  Always make them signin, or at least set a cookie with a reasaonable duration if you must let them remain logged in for a certain window of time.

 

As for a db login.  Store the credentials (user id and password) in a mini php module that is stored outside of your web-accessible tree (I assume you know what that is) and reference that in your standard MySQL connection code (which I also assume that you have)  The uid/password is stored in only ONE place this way and not accessible by any of your users - only your php scripts.

 

After seven months you might want to pick up the learning pace and do some research to educate yourself on these elementary things. 

Edited October 5, 2015 by ginerjm

[Landslyde]

Each of the clients has a memberID, and their clients are associated to them by this memberID. In whittling down the code and removing the username and password session vars, is it a risk to tie their memberIDs to a session var? It's either that or have them log in at every query. So is using a memberID session var a damaging approach?

[Jacques1]

Storing the user ID in the session is the standard approach. It's pretty much the whole point of sessions (besides storing temporary data).

[Landslyde]

Storing the user ID in the session is the standard approach. It's pretty much the whole point of sessions (besides storing temporary data).

Thank you, Jacques1.