I'm using NodeJS to create a simple blogging platform as a bit of an experiment. However while creating the admin panel (to allow one to compose posts and edit existing ones, change themes, etc.) I realised that I would need to create a login system. I am aware of passport.js, however I question the need for a login system where the software will administrated by one user.
My question is, is it necessary to have a login system for a platform that only has one administrator and no other users? If not, what approach should I take for this platform then?
In my opinion, it depends on what you want.
If you want to make some security relative practices and learn the principles inside, you should do more deeper research about security, and then choose a particular solution.
If you just want a 'door', which prevent others from accessing your control panel, and your application is just a simple blog system, not some popular huge system, in this case, I think static password would be good enough to hold, just require a password from user interface(frontend), then send it to your backend(nodejs), check if it's really yourself so that your backend logic can decide whether grant this access(you can hardcode the password in the backend part), done.
Related
I have been building quite a few MVC based websites locally and am finally ready to deploy the first, but, I am getting rather nervous.
During testing, I noticed several things that worried me - I am using the default forms authentication with a few tweaks (although nothing to the underlining security).
I noticed that if I created a user in one application and logged in, then launched another application... it would keep me logged in* as the user from the previous application. The user doesn't even exist in the new application!
* - I used [Authorize] on controllers, and was surprised I could just get straight in without any sort of authentication
I assume it is because the cookie is being set for localhost instead of the application/port (although, not too much I can do about this in development).
Based on this, how secure is the default authentication?
1. Is there anyway to check from the code that the user doesn't have a "faked" cookie? / Check the user has logged in from my application?
2. I was just wondering if there are any sort of check lists or anything I can go through before deploying?
Sort of - 3.As of writing this, For question 1. I am guessing I could add a column with a random number that is saved to the cookie, and then that number is checked every time any authentication is done... however, I did not want to start mucking around with the membership provider... but I think this could work. Is this a good idea?
Try using IIS on your machine instead of VS Dev Server. Solves your problem 1.
Other than that I don't think you will need any extra effort to make default membership mechanisms of asp.net to make more secure if of course you don't need a real custom things to do in your projects. These things are around for a while now and I think they have been well tested in terms of security.
You just need to remember to put [Authorize] attribute to right places. If not on your controllers put them to right methods.
Basic Web Authentication shouldn't be trusted for applications which contain truly sensitive information. That being said it's sufficient for most applications. Be sure to check your application as often as possible before and after release for XSS vulnerabilities.
Here is Microsoft's recommended "Secure yourself" list. http://msdn.microsoft.com/en-us/library/ff649310.aspx
No matter how strong your authentication is, one small XSS mistake and a malicious user can do as they wish to your site, and your users data!
I recently read a good book: Worx Professional ASP.NET, it talks about these steps in more detail on securing yourself as well as exposing examples of problems. After reading this I was able to "deface and steal" my own sites information with relative ease, was a good eye opener on the importance of securing for XSS.
I have a webapp that requires security beyond that of a normal web application. When any user visits the domain name, they are presented with two text fields, a username field, and a password field. If they enter a valid user/pass, they get access to the web application. Standard stuff.
However, I'm looking for additional security beyond this standard setup. Ideally it would be a software solution, but I'm also open for hardware solution as well (hardware=key fobs), or even procedural changes (one time use passwords on a password pad for example).
The webapp is unique in that we know all our users ahead of time, and we create their username and password and give it to them. In this sense, we can be assured that the username and password are "strong".
However, our clients have requested additional security beyond this. Anyone have any ideas on how to add another layer of complexity to the security?
Our company used PhoneFactor and we absolutely love it.
We've also used Safeword Tokens in the past.
However, it's notthe only game in the book. I'd start by googling "Two factor authentication"
The OWASP guide to authentication is another good place to start. Actually, OWASP is the first place I'd look for ANY web security question.
Another option for additional security is to use a piece of physical 'evidence' such as a Smart Card: Protect Your Data Via Managed Code And The Windows Vista Smart Card APIs
There are lots of different areas that web apps can have their security improved on. Before getting started you need to determine what, exactly, your problem areas might be and what you want to focus on.
You might start this process by having a third party do Penetration Testing (PEN Testing) on your application. This should give a quick hit list of things you can take care of and, when you have a passing grade, is something to use in your sales literature.
Next you'll want to talk to your customers to understand what they mean by "more secure". Is it simply two factor authentication like David and Mitch mentioned or are they more concerned about things such as data in motion (ARP Poisoning, SSL, and the like), data at rest (everything from hard drive encryption to database encryption), authorization, impersonation (cross site and replay), personnel (ongoing background checks on who has access to the machines), etc..
The concept of security covers a lot of ground.
Even though there are many good CMS tools out there, I've decided to roll my own tools for my website to get some hands on experience. The only thing that is currently eluding me is how to add authentication to secure the administrative tools.
I'm the only one who will be using the administrative tools, so I don't need something as complex as a full-blown log-in and registration system. However, I also don't want to rely on security-through-obscurity and use random page names and such to hide the tools.
What are my options?
OpenID is probably your best bet.
To utilize it for one person as you suggest, just check the username that is authenticated. Yeah, that would amount to hardcoding, but if we're creating a system with only one valid login name, there's no need for anything more complicated.
But creating the alternative shouldn't be that bad. You could also just create a table of roles, and do a query against that table to see if the currently logged in user is an admin. If you want to be fancier later, you can later add different users and roles.
How the users and roles get into the table is up to you.
1) Simply use "WWW-Authenticate: Basic" see Wikipedia for an idea and the related RFC for details.
2) Enable SSL to ensure your cleartext password is encrypted.
SSL is quite standard on web servers. You can even self-sign your certificate.
This will depend in part on what platform will be used by you and your web host. A given platform will likely offer one set of choices that will be easier to access than others.
For instance, ASP.NET running inside of IIS offers Forms, Basic and Windows (NTLM) authentication, as well as certificate-based authentication with the ability to map client certificates to Windows users.
You could certainly implement another authorization schema in an ASP.NET application, and many do. But there happen to be this set of out of the box authentication schemes that you would not have to implement if this were your platform. I expect this is true of any other platform, including the Linux-based platforms.
Be sure to find out what's available out of the box, and what can easily be added, before writing your own.
IS it best to configure permissions within a website for Administration access, separate webPages, or a completely separate application to administer changes on the site?
I usually configure permissions within the same website and have separate web pages for administration.
In some cases, having the same page with more controls can be useful as well, for instance, if you want a page to Approve/Reject comments, or something like that, instead of creating a separate interface you just add a few buttons depending on the role of the logged in user.
I often find that with questions starting "Is it best to" that there's usually a someone and a sometime involved (a kind of pragmatics type thinking - whome and in what context)
Different contexts will offer up different pro's and con's for each of the scenarios you've presented here and depending on who requires what functionality may also sway your choice.
With regard to the "who" part there may be other questions you'll be asking yourself about the process you're going through. Is it my users that require admin access, is it my development team, is it the managing director with little I.T. experience etc etc.
Questions about the medium used may also play a role in the decision you make. Are the "admin" people going to be on a PC, sales reps on-the-road using a palmtop which might suit it's own software application etc.
From a usability perspective, is it better to integrate admin section on the main website or have a separate section to manage content?
Any thoughts are greatly appreciated.
EDIT: the application is a CMS for very non-techno friendly staff.
It depends on the project and part you want to administer, imho.
For example comments on newsposts should be administered in the website itself by showing a "delete" linkbutton for each comment. Otherwise the mods would have to look up the comment in the admin section => not very user friendly.
But in general I think a seperate admin section will usually be more clear to your client. You'd want them to see the site as a normal user would see it.
At the very least I would recommend moving all your administration files to a separate folder. That way if you're using a platform like .NET you can very easily control folder access though role and user-based web.config permissions.
Having your administration files all segregated allows you to do other things easily too, like delete them if you decide to move them to another server later. Also you can exclude them in your robots.txt file (although by putting it in the robots.txt file you will be telling other people this section exists, and robots don't have to mind this file).
Edit:
I feel like my answer missed the mark a little considering your question. Of course in-line editing is easier than going to a separate page from a usability perspective, but whenever I hear of mixing admin users with regular users giant alarm bells go off in my head.
I think that it depends on the function of the site and how intrusive it will be to your staff. Does it make sense for them to make changes while browsing the site and will they eventually become discouraged with your system because it forces them to inject unnecessary steps into their process? How long will the edits take? Does it make sense to show a completely different interface to administrators? I think an answer to this question requires a lot more understanding of what specific function you're trying to accomplish and will vary on a case by case basis.
I have never liked adding administration pages into the main site. It seems like it is too much of a risk from someone accidently getting access to the administration portion of the site. Even if you review the security over and over, there is always that possibility that something unexpected will happen, and it is a huge mess to clean up (what was modified, who accessed what etc. etc.). In my opinion keeping it as a seperate site is the easiest way to go.
While there is a level of convenience in being able to login to the main part of a site as a privileged user, and then clicking on parts of a page to edit/alter it, there is also a measure of security in having it in a separate area.
I have found that having a separate section of the website that is devoted specifically to administrative tasks makes the tasks easier to organize and use. Just look at Wordpress (especially the new 2.7 release), Drupal (a very popular cms), and Joomla (another very popular cms). If you would like to test these feature out to see why I think the separate section is better, you can go to www.opensourcecms.com and test out both Drupal and Joomla.
From a usability, the more integrated the better but it tends to add severely to the complexity. Its always best if you can perform the action within the context in which it occurs - lock out a bad user, trim a log thats too big etc. however since these tend to have significant side effects the security aspect trumps this a lot of the time out of fear.
I think you need to look at doing a risk assessment with regards to integrating the administration capabilities right into the application.
What would be the implication for the system if someone were able to escalate privelages and gain access to the admin functions. if every user was locked out maliciously - damage to the site, the reputation, SLA etc?
What destructive functions can an admin perform from this section ? delete lots of data? crash the app? alter costs that have material impact on users/customers?
Are the admin functions integrated in the app or isolated into specific admin functions?
Does the application have a public face or is it an intranet that is assumed secure?
I personally have never felt at ease integrating the admin section with the site out of fear that a security breach caused by my ineptness or something beyond my control like bad defaults, unpatched exploit. However, when the client is writing the cheque I tend to do what they feel is best.
I come from the school of Usability that says "minimise guess work". So, what kind of information did you get from your user group sessions?
Remember, you're not (and we're not) typical users of your system. Anything we say is going to be a guess. What's worse is that any opinion shown here is likely to be ill informed for your situation (but probably awesome at what they do). The only way you'll have an informed opinion on what to do is by going out and asking your users in intelligent ways.
Because this is a security issue some of your user mix should be people who specialise in security. Just because it's easier to use doesn't mean it's the most appropriate.