I could be wrong about this, but it is my understanding that it is a very common practice to handle permissions like so:
The user goes to the login page and provides a username and password.
The username and password are verified. If valid, the user's information (including permissions) is set to a session variable.
As the logged in user navigates the site, certain features are available to the user based on their permissions, which are referenced in the session.
This makes sense since it would be impractical to frequently query the database for the user's permissions. However, from a security standpoint, I'm not sure what the best approach is. A simple example would be if you were to remove a certain permission from a user while they're logged in. An extreme example would be if you were to mark a user account as inactive while they're logged in. I don't know how you could get that user's web browser to know about the change other than to code database permission checks (as opposed to session permission checks) into every part of the website. Again, that seems like overkill, but is that really the only way if you want a secure website?
Thanks!
I believe you've got it stated correctly:
I don't know how you could get that user's web browser to know about the change other than to code database permission checks (as opposed to session permission checks) into every part of the website.
Depending upon how your site is designed, it might make sense to invalidate the user's session when you perform drastic enough modifications to the user's privileges. Deleting sessions mean the user will be faced with a new request to log in, but if you've just disabled their account or severely downgraded their privileges, that might be acceptable.
But you wouldn't want to invalidate the session for every little thing and certainly not for almost any permission enhancement operations.
If you expire all sessions N seconds after the last authentication you can place an upper limit on the amount of time that your application code would grant permissions that have actually been revoked. This might be suitable when the stakes are not very high anyway.
Related
Should I have one login form for ordinary user and admin
Or
should I have separate login form for admin and ordinary user?
It is OK to have the same form.
The purpose of the login page is authentication-- determine who the user is, not what they can do (see What is the difference between authentication and authorization?). So for example you might want them to submit a password or other token to reduce the risk that they are not the person they say they are. That can be the same process for everyone.
Certain features in your site may be available only to administrators or end users, but checking for permissions (authorization) can only be done after you're sure who the user is (they have authenticated). And logic to check for permissions should be present on every single page. So it has little bearing on what the authentication process is like.
You should just use one form for both admins and ordinary users if the log in information required is the same. Having two forms only makes the application more complicated to write. Having one or two login forms would be equally safe. Just remember to implement the correct security measures on the server side so a user does not get admin privileges.
The first step in authentication would be to check if the username exists, then check if the entered password matches the user's password in the database (passwords should be hashed). Then you can do authorization to check if the user is an admin.
While this seems to be asked in the form of an opinion, it makes more sense to answer this based on what most websites (or applications) do.
It really depends on the context. As a general rule, the same login form would be used for regular users and admin users. Generally, a parameter specifying whether the user is an admin would be stored in a database table for the users. The authentication method(s) that are executed upon clicking the login button will verify the user exists, check the password against the hash, then check the database table to see if the user is an administrator.
In some certain circumstances, I have seen a separate login page for administrators, but it is rare. One example might be a webstore that has an administration/management dashboard which is separate from the main site. Generally, though, these will work via the same form.
I apologise if the title is a little confusing, but I was a little stuck with the wording.
I'm currently working on a section of an application to allow users to grant developers access to their data through the application. This comes in a little 'Allow Some great app to access your account with the following permissions'. The application developer adds the required permissions, then when the user goes to authorize the application, these permissions are are displayed. If the user is happy to grant these permissions, the user shall press 'Grant'. This means that the user has agreed to every permission that has been displayed, and therefore this generates an API access token for the relevant application.
The issue now is that it has came to the attention that people may want to remove these permissions at a further date. At the moment, if the user would like to remove permissions, all permissions will be removed or disabled. The reasoning behind this is that if a single permission is removed from the application, the token that they authorized with is technically invalid as it does not have the permissions that were given to it when first creating the token.
Whilst this seems logical, there are also circumstances where the user would want to deny access for the third party application for a single feature (eg. The external application had a bug that was creating bad behaviour in a certain area, but was working fine in another area).
Would anybody be able to throw their two-cents in to this, as I'm having a hard time understanding if its best to allow modifications to a single permission in the event of problems, or to simply have to disable the application.
I know the title is a little off, but it's hard to explain the problem in a short sentence.
I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".
Authorized licenseholders which does all setup themselves.
Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)
Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them.
This is also how we do support: we login as them and then follow them along, guiding them.
Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.
So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.
Any suggestions?
(The platform is classic ASP... I said it was legacy...)
Both options you present sound unattractive to me.
A master password is probably even more dangerous than what you are doing right now
Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.
I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).
How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)
What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:
logged_user - the actual user who typed in his/her username and password
impersonated user - the user (1) is acting on behalf of
Everything you do is done with the impersonated_user's permissions and preferences.
If you are not impersonating anyone impersonated_user=logged_user.
This way you have to always log any operation with both "actual" username and "impersonated" username; for example:
2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'
sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.
I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.
.. Or is it enough to just check for a session variable that indicates a successful login has in fact been performed?
What are different ways to go about this? The ideal and not so ideal?
Thanks!
Third alternative: HMAC-ed cookie. No need to hit database/session-store at all.
Details.
Even if a user has an active session that is restores via cookie for example, you need to verify his account data.
If you don't check the current database entries for a user, he could possibly login although his profile has been banned or something like that.
The reverse situation can happen if your user opens a session in one browser (at home for example), upgrades his account to some "premium" (or whatever) account with another session (maybe from his office). When he returns home, he would get his old session that has no "premium" privileges.
So, always check the data for your user profiles. I would recommend to check them on EVERY request to your website. Your session data should only say WHO the user is and not WHAT he is allowed to do.
how do I prevent my users for more than one simultaneous login per account. I am using Vb.Net SQL.
Just coming from a 'web programmers' point of view, there is one really simple way:
You have to use some sort of central session system, where a Cookie on the user's browser has a hash, or some unique key that is also stored in the database. One each page request, or at set intervals, you check if that hash exists in the database.
Then, whenever you have a user log in, you delete any hashes that are tied to that user in the database, and then you create a new one for the user logging in.
What happens is if a user logs in, and you delete existing hashes from the database, then the other user will be logged out when you go to check for their hash in the database.
Not VB-specific, but: when the user logs in, keep track of the fact they are logged in. You can keep this in a cookie (watching out for the fact that a cookie can be tampered with.) You can keep track of it in a session variable. Or you could keep a boolean field in the database, "is_logged_in".
Then, when the user attempts to log in, you can check to see if they've already done so. If they're already logged in, the script might just return them to the home page (provided they used valid credentials. Otherwise a rogue user could type a username but leave the password blank, and depending on the behavior of your program, could see if a user was logged on at that specific time.)
Also, it is common that when someone is logged in, the webpage itself replaces the "Login" link with some text that says "Welcome, rascher!" and maybe links to their profile or preferences page.
Edit: Also remember to set is_logged_in (no matter how you track it) to "false" if they log out. It might also help to time this out - say, when the user closes the browser, or after "n hours" of inactivity (though that can be really annoying.) It will depend on how long people are generally logged into the system. Also note that someone might log in on their home computer, stay logged in, and then try to log in to the same place from work or their iphone. You might could look at ways of dealing with this (if the IP address is different than the current login, then log the other person out? Or something.)