Securing opensource web application

Question

I have an open source website. I need to add an admin section to the website which is accessible to only one person. To make it secure, I was thinking about providing a login page which checks if the password matches to a predefined password and sets a session indicating the login was successful. This password will be stored as an environment variable in the server.

Do you think this approach is secure? This website does not have a database. So I don't want to add dependency to a database just for keeping user accounts and passwords.

Website is written using nodejs and ExpressJS.

Answer 1

Your webserver can disallow access to files and folders. You could make this configuration in a .htaccess file which contains your password hash. Storing plaintext passwords should be avoided at all costs.

Make sure that authentication is performed over HTTPS and HTTPS is used for the life of the session. If you don't follow this guideline then you will be in violation of OWASP a9.

Answer 2

Do you think this approach is secure?

On it's own - NO! Without adding additional layers of security on top of what you described, your server would be exposed to brute force attacks trying to match the required password. It doesn't matter how long and random your password is, given enough time your protection scheme will be cracked. And the way you describe it, it doesn't look like it would take long either. You could secure your web application a bit more though, even by using a simple one lock one key security you describe. On top of what Rook already suggested, I would add that you could implement also these security measures with relative ease:

• make sure you move your admin sections of your web application to a non-standard location and never publish (link to) its location in publicly accessible parts of your web application. There is no true security through obscurity though, with plenty of threads on IT.sec describing why not.
• lock access to your admin sections in your web server config to only a limited IP range (with mask as high as possible), or even better only a few specific IP addresses that you intend on accessing admin sections from. Keep this configuration always up to date and as limiting as possible at all times for best security.
• any active scripts that might be accessible through your admin section should also be moved to a non-standard location. For example, say you're using TinyMCE extensions in your CMS. These can be exploited in various ways and you're best off moving any such server side scripts to non-standard locations. Make code changes where necessary to support new locations.
• Only explicitly allow access to these sections to user-agents that are even supported by your admin panel (and similar). You can configure that in your web server. You can lock out a lot of generic web vulnerability scanners out there, as most script kiddies can't even be arsed to change user-agent strings to something less obvious.
• Log any access to these sections and dynamically deny access to IP addresses that seem to scan for standard admin panel locations. If automation is not possible, then check these separate logs frequently and lock out such IP addresses in your web server config manually.
• Only share information on how to access these admin sections with those that absolutely need to know them and create different sets of rules described above for each and every single person that needs to access it. If that means more than one single password, checked against IP address they're accessing from, then so be it.
• Make sure these passwords used can't be retrieved by code inspection alone (meaning, never store them directly in your code, obfuscated or not). It should be also self-obvious not to store them in locations that can be accessed through your web server.

All these rules should be easy enough to implement and will add additional layer of security on top of a simple password that you plan on using to access these secured locations. I would also suggest you use a username and password combination to add to the complexity (and if possible some sort of CAPTCHA) that will make your admin sections a bit less prone to brute force attacks. Others will answer your question with more suggestions, I'm sure, but these are the ones I can think of off the top of my head that wouldn't take too much time to implement. Hope it helps. Cheers!

Answer 3

This is perfectly fine as long as you have a decently long password. The only way anyone could get your password is if they compromise the server process, but if they compromise the server process, they don't need your password because they can probably just modify its behavior/remove the password check etc.

You may want to hash the password, but you don't need to bother if you don't reuse the password anywhere.

Note most of the suggestions in the other answers are mainly FUD/OCD :) For example IP filtering is a waste of time, and logging isn't that important really if you have a secure password and don't have all kinds of holes in your site.

The one thing I'd say to do if you haven't already done it is make sure you don't have any injection (XSS/SQLi/etc) problems or CSRF/clickjacking. You may want to use HTTPS if you think it's possible that someone (government, people on your wireless network, etc) will intercept/interfere with your traffic.

Answer 4

You can use an open source 2FA solution (like ours) and mod-ldap on apache. I did a proof-of-concept for an open-source automated scanner. See here: http://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-add-two-factor-authentication-to-the-seccubus-automated-vulnerability-scanner.