SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 32
  1. #1
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    how do you secure your admin areas?

    When in a shared hosting environment, how do you secure your web-based administrative areas of the website? Meaning the admin areas to manage content, products, users, that kind of thing.

    Obviously there will be a necessary login (I currently use basic authentication for the admin area and then a second php-based login since admins would have varying privileges), and your robots.txt file should disallow robots from going to /admin (not that they'd be able to access it) - is there anything else?

  2. #2
    Non-Member thewebhostingdir's Avatar
    Join Date
    Oct 2005
    Posts
    703
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Crawlers can not access the password protected pages.

    We save the passwords in MD5 encrypted forms with some minimum password strength. We also disallow admin folder in robots.txt

  3. #3
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    As robots.txt is freely available, should you really be advertising the existence of your administrative location?

    I agree this screams of 'security through obfuscation', but still...
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  4. #4
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    For the same reason a simple step is not to put it in a directory called "admin".

  5. #5
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    I enforce a 2 stage login.

    Stage 1.
    I demand a 3-token login, which grants a cookie.

    Stage 2.
    From then on in, login is quite easy via a simple PIN number ( one strike and you're out if the PIN is wrong ).

    Holders of the cookie go straight to Stage 2 to login.

    I use db-based session control.

    passwords are SHA1() ed.

    The logins are kept and stored in a different database with different credentials.

    Once logged in this selects the settings this user needs to do the basics, in my case is just which applications each user can access - though it could be ACL, the path to their application and the name of the database they can access.

    A logged in user can then access their database with some privileges as a named sql-user so they cannot ever influence the data in another database, just in case I were to overlook anything at the application level.

    Each screen within each application checks the validity of the current session vs the database every time.

    So everything to do with logins, users, passwords, failed attempts, login-sessions etc are kept far away from application data in a seperate database.

    I don't yet make the login https://, and I don't yet enforce account locking, which I will do when I have more than one client!

    I don't know which would be more important to use https:// or a dedicated server - but I'd guess it was the latter.

    I'd never tell robots.txt anything except public urls.

  6. #6
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use Zend_Auth in combination with Zend_Acl - and I decide whether the user has privileges to access the admin module in a controller plugin before anything else takes place.

    Passwords are stored in a database as sha1() hashes + plus I uses 40 characters long (or longer) randomly generated salt so brute force attacks are not possible.

    When the user has no privileges to access the page, he/she is just redirected to the error/denied page with explanation of his priviledges and which parts of the website he/she can access.

  7. #7
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do you mean "secure" as in beyond the usual username and password requirement? If so, I can think of a few ways:
    • Login credentials encryption/hashing
    • Max. login attempts or account lockout
    • SSL Certificate
    • Security image like banks use
    • Additional security question, like "what year were you born"

    The last 2 points especially are probably over the top for most simple login systems, unless you are actually storing financial data. Most times all you need is a simple username/password with hashing. Your security will only ever be as strong as your dumbest user.

    Quote Originally Posted by TomB View Post
    For the same reason a simple step is not to put it in a directory called "admin".
    You're thinking about it from a programmer's perspective. What if your users are used to going to "/admin" or "/login", and they constantly forget the correct location because it's "more secure" by naming it something different? It ends up meaning more phone calls and emails you have to deal with. In the case of Wordpress - they tried that, but now "/wp-admin" is so common it makes no difference.

  8. #8
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course strong database, cPanel (or other control panel you use) and ftp passwords are important part of security (I use this to generate strong passwords http://strongpasswordgenerator.com/).

  9. #9
    SitePoint Wizard Dean C's Avatar
    Join Date
    Mar 2003
    Location
    England, UK
    Posts
    2,906
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I hope none of you store passwords solely using md5 or sha1. I would hope you salt them too

  10. #10
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dean C View Post
    I hope none of you store passwords solely using md5 or sha1. I would hope you salt them too
    Of course, using salt is a standard these days already.

    One more thing I would like to add. To help thwart session fixation/hijacking, always set a specific time for the session cookie to expire (for example I use 7 days).

  11. #11
    SitePoint Addict skunkbad's Avatar
    Join Date
    Apr 2008
    Location
    Temecula, CA
    Posts
    278
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Don't forget the SSL certificate! If you REALLY want to be secure, logins, and anything that you don't want people to see should be within your encrypted connection. Sure, there has been recent news that SSL might not be as secure as we once thought, but the hacker would have to have access to your network, which makes the man-in-the-middle attack pretty rare.

  12. #12
    SitePoint Addict artemis's Avatar
    Join Date
    Sep 2003
    Location
    London
    Posts
    295
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I found this post just this morning

    http://www.smashingmagazine.com/2009...-in-wordpress/

  13. #13
    Non-Member Musicbox's Avatar
    Join Date
    Nov 2004
    Location
    india
    Posts
    1,331
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    securing admin area by restricting access to guest by adding login feature as password protected pages cannot be accessed by robots.

  14. #14
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by skunkbad
    ... but the hacker would have to have access to your network, which makes the man-in-the-middle attack pretty rare.
    Reality check on the original post:

    Quote Originally Posted by old_iron
    When in a shared hosting environment,
    If there was a hierarchy of needs when it comes to securing your application I'd say move #1 is get dedicated server.

  15. #15
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,198
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by old_iron View Post
    When in a shared hosting environment, how do you secure your web-based administrative areas of the website?
    Check with what user apache runs with.

    If it run as nobody or a set user that is not your accounts user, then run and never look back. (i.e. change host at once).

    If the apache does not run with an unique user for each hosting account that means that you easily can get access to any other account and their files.

    Other than that, you have received a bunch of good tips already.

  16. #16
    SitePoint Wizard bronze trophy bluedreamer's Avatar
    Join Date
    Jul 2005
    Location
    Middle England
    Posts
    3,397
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    A few ideas:

    1. I often rename the "admin" directory to something obscure
    2. Add an extra layer of password protection over and above the softwares on login system - two logins are required but taht's not a bad thing and no customers have complained
    3. Enforce minimum password length, and if possible a mixture of lower/upper case alphas and numbers

  17. #17
    SitePoint Member
    Join Date
    Aug 2009
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Damn this site is so informative, I'm glad I joined !!

  18. #18
    SitePoint Wizard
    Join Date
    Mar 2008
    Location
    United Kingdom
    Posts
    1,285
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some great posts here.

    Really need to think of adopting a more secure approach for my own logins.

  19. #19
    SitePoint Evangelist rhysboy84's Avatar
    Join Date
    May 2007
    Location
    Colwyn Bay, North Wales, UK
    Posts
    438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, very informative.

    I'm writing my own CMS (i'm using it as a way to learn PHP & MySQL) and am concerned about security. What would you recommend? I'm using md5 (with salt) and an obscure login directory.
    I'm Rhys Wynne & I blog at Winwar Media
    WP Email Capture: Free Email/Ebook Marketing Wordpress Plugin
    UK Based SEO? Tweet Your Location to #ukseohere!
    | My Brand New Brand | Twitter |

  20. #20
    SitePoint Enthusiast robertss's Avatar
    Join Date
    Mar 2008
    Posts
    32
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You definitely need an SSL certificate to encrypt the password as it is being sent to the server. Otherwise, anyone in the middle can view your username and password.

  21. #21
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by robertss View Post
    You definitely need an SSL certificate to encrypt the password as it is being sent to the server. Otherwise, anyone in the middle can view your username and password.
    JavaScript can encrypt, too.

  22. #22
    SitePoint Enthusiast premiumscripts's Avatar
    Join Date
    Aug 2009
    Location
    PremiumScripts.com
    Posts
    55
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Add a fake "admin" directory and keep the hackers busy trying to hack a non-existant admin directory

    Put the fake admin directory in robots.txt as a forbidden rule and they'll be sure to try and hack it.

    Meanwhile, log their details and do whatever you want with that.

  23. #23
    SitePoint Guru
    Join Date
    Dec 2005
    Posts
    982
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    I enforce a 2 stage login.

    Stage 1.
    I demand a 3-token login, which grants a cookie.

    Stage 2.
    From then on in, login is quite easy via a simple PIN number ( one strike and you're out if the PIN is wrong ).
    What's a 3-token login? How does your PIN work? Before they can enter their username/password they have to enter in a 4-digit number? Does every user share the same PIN or does every user have a username, password and PIN? How do you enforce the 1-strike policy?
    MySQL v5.1.58
    PHP v5.3.6

  24. #24
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    This old thread on a similar topic explains more about what I meant (post #11).

  25. #25
    SitePoint Guru
    Join Date
    Dec 2005
    Posts
    982
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    This old thread on a similar topic explains more about what I meant (post #11).
    Interesting idea, but I just don't quite understand the purpose of the PIN. Here's the flow as I understand it:

    Customer goes to login screen and enters username plus the 4-digit PIN unique to their account (I assume they were assigned this when they created the account? If they were able to choose their own, 99% would be 1111 I bet.)
    If correct, they are allowed to enter their password
    Else, they are told their username/PIN combo is wrong

    Once properly logged in, the username is stored in a cookie. For this session, nothing more is asked, but if they leave and come back, they must ONLY re-enter their PIN? After failing to enter their PIN three times, their cookie (with username) is deleted and they are treated like a new user.

    I can see this being a little more secure (you now have 2 passwords more-or-less), but it doesn't seem much better (brute forcing the PIN seems doable if you know the username). Memorizing the 4 digit PIN also poses a big nuisance to the customer; customers forget their password all the time, now they have to also remember a unique 4-digit number.

    Am I right? Or do I misunderstand it?
    MySQL v5.1.58
    PHP v5.3.6


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •