Forums

The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums Other How to secure your own Control Panel

  • This topic is empty.
Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #44817
    AndrewPham
    Participant

    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?

    #135299
    Argeaux
    Participant

    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 :)

    #135301
    AndrewPham
    Participant

    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.

    #135323
    Argeaux
    Participant

    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.

    #135349
    AndrewPham
    Participant

    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?

    #135351
    CrocoDillon
    Participant

    > 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.

    #135353
    AndrewPham
    Participant

    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?

    #135354
    CrocoDillon
    Participant

    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.

    #135358
    AndrewPham
    Participant

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

    #135363
    Argeaux
    Participant

    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 adminF%0cl?BX7@HfBuH-i;f-Y5UQ~<}|c(1M$|TO[I!=U

    #135377
    __
    Participant

    > 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.

    #135389
    AndrewPham
    Participant

    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?

    #135502
    __
    Participant

    > 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?

    #135528
    AndrewPham
    Participant

    > 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 14 posts - 1 through 14 (of 14 total)
  • The forum ‘Other’ is closed to new topics and replies.