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.)
Related
I would simply like to ask if I'm doing the things right or if it is better if I stop before going in this direction. I have an administrative area in my website and I though to manage login using a table on my database.
When the user correctly login, I then write on a sql table the username, the session id and the IP obtained from REMOTE_ADDR server variable.
When the user ask for a private page that require to be logged in, I lookup the username on my table filtering by IP and Session ID, this return the user of the current user asking for example for "prices.aspx" page on my admin area.
I have then made my so saved records be deleted after 30 minutes. Is this safe enough? Is this a good way to expose my website to hacks? How could I improve the security?
If your site can be hacked, it doesn't matter how your login system works. What keeps a hacker from getting at your data?
Encrypted Transmissions
Never show database names, file names, passwords in front end code.
2 Step verification login to your website and database
The basic principles of logging a member in, or logging someone in to an authorized page are no different.
Whether you delete a record 30 minutes after it's been saved or not is totally immaterial. If a hacker can access that data, saving it in an unsecured manner for 1 second is to long. If you want the user session to time out after 30 minutes, just deleting the database record won't achieve that. So, to your question, "Is it safe enough?". No, it's not.
If your regular member login is safe, then all you need to do is have a field in your user information database, that indicates whether the user is authorized to see certain pages or not.
When your website is first loaded, don't ever load the admin pages unless it's requested, and then have the user give their password a second time. If the user who logged in is not authorized to see an admin page, then don't even load the HTML that allows a user to request an admin page.
Is it safe to login user automatically after registration?
User fills registration form, some info message is sent to his mailbox, and what then:
User redirected to login page asking him for credentials;
OR
User auto-logins as his newly created user?
I feel something not safe enough in auto-login, but can't figure it out!
If they just filled out the login information and you're not concerned about confirming that the email address is legit, then there shouldn't be a problem just logging them in directly.
However, you open yourself up to people/bots creating bogus accounts (at least ones without legitimate email addresses). If you're concerned about that (not sure it this is a public facing app or intranet, etc) then you should at least verify the email address by sending a link with a guid or some identifier that you can track back. Then you can let them log-in once they are confirmed.
You could also just tie it to their StackExchange/Facebook/OpenID/etc account and not make users fill out yet another form and worry about maintaining all that information.
They should need to login. Also the confirmation email should not contain their password. If they managed to give you the wrong email address and you automatically log them in then someone else has access to their account now. This holds even if you have them type their email address twice. Sometimes people make the same mistake twice in a row.
It can be safe to auto login if the user already has an active session as the correct user during the confirmation step. If you think about it, it's not actually "automatically logging them in" but simply keeping them logged in as they was before.
User registers
Keep a session identifying the user
User navigates to the confirmation page (linked in email)
You activate the account
During all that time, there was no reason to end the session. The only reason you would want to end the session (or not create one in the first place) is if your permissions are not properly set to allow someone to login / create a session without giving them higher privileges than an unregistered user.
Now, be sure not to automatically identify the user as X simply because this person navigated to the confirmation page of user X. If a user navigates to this page but does not already have a session open, do not assume he knows the password.
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.
Well, you type username and password in form, hit "OK" button. Then data going to server side and check users database if that user is existed. Then it return user id. And what next?
That data is saved in cookies?
Does it mean, that with every clicked link, site login you to website again?
I mean,
you click some link on site
browser redirect you to that page
site checks your cookies
site grab username and password from cookies
site checks is that data is valid (via connecting to database)
show page to you
Is that correct?
User enters credential.
System validates credential.
Upon successful authentication, server saves user object into session.
System grabs user info from session.
System displays webpage.
Tadaa!! :)
UPDATE
To add a little more...
User visits the secured webpage.
System checks if session contains a user object.
If user object exists in session, allow user through to visit the page.
If user object doesn't exists, redirect user to login page.
You don't need to store user password in the session. In fact, it is highly discouraged. Checking to make sure the user object exists in the session is sufficient.
When the user clicks the logout page, then proceed to invalidate the session... that's it. :)
Almost correct. You rarely go to the database with every request. You usually set a cookie with a expiry date and save the user session and info in memory. So every time a request is made, if the user is not authenticated, you authenticate him, generate and send him a cookie with, say, 5h expiry. So, in the next 5 hours, whenever a request comes in with that cookie, you trust that the user is an authenticated, valid user and you don't have to check the database.
It's not how every site does it nor it is the only way to manage session and cookies but I think it is the most widely used.
You should probably use sessions, but that's pretty much the gist of it. That way the data doesn't accidentally persist.
I mean, for my simple site at home, that's how I do it. But it's still locally hosted, so the security is guaranteed to be crap.
Oh, and no need to check with the database whenever you click on another link -- too much time wasted.
Typically, an application takes advantage of the session that is established between the browser and the web server, and makes a note that that session is "authenticated". "session" is a built in feature of HTTP. If the browser is closed, or after a certain period of time passes, the session is automatically closed. If the user does an explicit logout, the application marks the session as not-authenticated.
.. 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.