Grow your CSS skills. Land your dream job.

How to secure your own Control Panel

  • # May 16, 2013 at 10:16 am

    So I have to build this administration page(control panel) for a website. I look at it from a simple perspective. Just a simple page, which can only be accesed if a certain session is set. And the session will only be set if you have succesfuly logged in. On that page, you will be able to view/modify/remove every item from a database table. Also, you will be able to add new items. This will be done through some forms and some SQL statements like "UPDATE SET" or "INSERT INTO".
    Also, the login page contains a simple form, and on submit, it will check the value from POST with some data from the database. If it matches, I will output a button to the edit page, along with the POST parameter, which will tell the edit page to set the session, before checking if it is set.

    But still, I have that feeling that I’m missing something. I feel like this thing isn’t secured enough.
    I don’t know, it just looks so simple, but when I think generally about a control panel, I consider it a complex thing, a highly secured thing.

    For those who are experienced, am I missing something critical? How can I improve the security?

    # May 16, 2013 at 11:59 am

    The way the login is made is important for safety:

    You should encrypt the admins passwords with something like bcrypt instead of md5 or even no encryption. And also use a salt on your passwords. It can also be useful to throttle the number of logins someone can do. So after 3 or 4 wrong attempts block the user for a few hours. This way it’s harder to do a dictionary attack to guess the passwords.

    The queries you use should be escaped properly to make sure people dont mess up your database. Or used prepared statements in pdo or mysqli.

    You should also use csrf-protection for your form. (google it for more info!) Last but not least, make sure your admins use good passwords and not 12345 or admin admin.

    Also a problem which you will probably are gonna face now is that a user will edit a page and accidentally removes some of the text and hit submit. He or she will realize that it was important information and its forever gone because you update or delete it directly on the database. This can be solved by using versions of your data in the database which you can roll back or make users save something temporarily and they have to do an action to make it “live”.

    Hope this helps a bit :)

    # May 16, 2013 at 12:17 pm

    Why should I encrypt it, when I have it on a server-side variable, or in a database? No one has acces to those things.

    # May 16, 2013 at 2:49 pm

    They will have access to the database or serverside variable if your site isn’t secured right, and then your adminusers password are known. The admin users might use this password for their mail or bankaccount as well so they have access to that too.

    So it’s an extra security layer to protect your users, not your website or data itself.

    I made a small mistake btw, the correct term should be hashed, not encrypted.

    # May 16, 2013 at 5:13 pm

    Alright. My point was to make it impossible for them to acces my database or server-side. I don’t want to do that just in case they hack in. I don’t want them to hack in.
    > if your site isn’t secured right

    So how do you think someone could gain access to the server?

    # May 16, 2013 at 5:21 pm

    > I don’t want to do that just in case they hack in. I don’t want them to hack in.

    Better safe than sorry, I agree with Argeaux, always hash passwords (I use sha256). Assume everything can be hacked.

    # May 16, 2013 at 5:31 pm

    So I’m just going to hash the password string, and put it back in the db? How am I going to “dehash” it, in order to check if it matches with the pass he entered? I think, though, that the hashed version isn’t just a string. If you output the code, you will get the original string behind it, am I right?

    # May 16, 2013 at 5:34 pm

    No, once you hash it, you’ll never get it back (especially when it’s salted, otherwise you could brute-force it with rainbow tables if the password is weak). That’s the whole point :)

    When some one wants to login, he enters his password, then your back-end will have to hash it exactly the way it was hashed in the first place (same algorithm, same salt) and then you can compare the hash with the hash from the database.

    # May 16, 2013 at 5:48 pm

    Oh, right! How comes I didn’t think of it? I must have went through it fast.
    Anyway, what does salt mean?

    # May 16, 2013 at 6:28 pm

    A salt is something you add to the password before you hash it to make it harder to crack.

    For example the password is
    admin

    A hacker can make a database with all kinds of known words and passwords and their hashes and search his database for the hash and he will know it was “admin”

    However if you add a salt to the password admin to make it a set of characters a hacker will not have in his database he wont find the hash.

    salt = F%0cl?BX7@HfBuH-i;f-Y5UQ~< }|c(1M$|TO[I!=U

    combine this salt with the password:
    adminF%0cl?BX7@HfBuH-i;f-Y5UQ~< }|c(1M$|TO[I!=U

    And hash this, the hacker will never guess what your salt is and it doesn’t look like a regular password anymore so dictionary attacks will probably not work.

    You obviously have to save this salt somewhere in your code because with out it you cant make users login after you save their password with a salt.

    # May 16, 2013 at 10:52 pm

    > My point was to make it impossible for them to acces my database or server-side. I don’t want to do that just in case they hack in. I don’t want them to hack in.

    One more thought on this subject: do you have a private server? with a company you trust completely (not just their intentions, but also their competence in security matters)?

    If you are on a shared hosting plan, as 90% of the internet is, then your site is simply **not secure** and it is not possible to make it so.

    > Why should I encrypt it, when I have it on a server-side variable, or in a database? No one has acces to those things.

    The other reason is, if you *can* simply look up a password, you eventually *will*. That means that someone, sometime, will be able to steal the password.

    # May 16, 2013 at 11:28 pm

    You should never, ever store passwords unencrypted. Ever!

    Used to have high end clients wanting to be able to view/extract their users’ passwords from the database, thankfully could deflect them with Australian online privacy laws, which are pretty stringent.

    # May 17, 2013 at 2:41 am

    Alright. I’ll take your advice and hash+salt it. But what about the session part?

    If someone tries to access directly the “profile.php” page, they will get a 404 error(faked by me). But if they have that session set, they will gain access to the control panel. And they can’t have it set unless they log in.

    Is this a good practice?

    # May 18, 2013 at 12:20 am

    > If someone tries to access directly the “profile.php” page, they will get a 404 error(faked by me).

    Not really “faked,” but I understand what you mean.

    But why? Do you object to simply telling the user that they need to log in first?

    # May 18, 2013 at 11:44 am

    > But why? Do you object to simply telling the user that they need to log in first?

    I just feel prety unsafe to let the user know that that’s my administration page. He may me a random dude trying to guess it. And it’s pretty obvious: “profile.php”

    Anyway, so is this an appropiate/secure method of logging in? The one with sessions.
    I was thinking that someone might visit a website which will actually set a session with the same exact name.

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".