I hope someone out there has some update to date information on sessions and their IDs.
I'm running on IIS 7 and we're seeing Sessions assigned to more than 1 IP address.
I ruled out the possibility of it being caused by users resetting their IP addresses, for instance by unplugging their modems.
In at least one instance a user logged in and found data from a different user in had been saved to his account (the user IDs that determine in which account the data is stored are kept in session variables). In another instance an employee logged in to check a problem as was given the session of a different user.
It's not just the session variables, but I saw in our log the session ID itself is being associated with two different IP addresses. At one point this was happening with over 10% of our users.
I'm wondering if the problem is not in our system, because I'm seeing that in each case the IPs sharing a session ID are on the same ISP or share at least one NameServer.
I very much welcome any ideas, we're getting desperate!
It's a caching issue with IIS7. Read more here: http://lionsden.co.il/codeden/?p=446
Related
I know it is against Google Analytics terms of service to store personal information about a user i.e. email address, log in name. But I have a requirement that need to track time spent on site/page for a user by email address.
Has anyone done this before?
The terms are a bit more specific than that (if they weren't, google-analytics would not be usable on sites with user logins at all), but the question is why you need to track them by email address. As long as your user is logged in, all you have to do is set a session ID when they log in, and then track that session ID when it's being used for content requests. For PHP backends this is described in http://www.php.net/manual/en/intro.session.php but other server-side languages have similar functionality.
I am trying to find a solution to control the number of logins on asp.net application.
I need to install the application in the client server, and set the number of licences. e.g. only 10 users are allowed to access the app.
Every time someone tries to login I need to check how many user are logged in, compare with the total allowed then authorize that user to proceed.
I tried with Certificate, but I couldn't see where to match the number of logged in users with the max number of allowed user.
Also I would like to use the IP address as identifier, then if I open 3 browser windows, it count only one user logged.
Basically this web application will be sold by licences. We need to control the logins per computer, and not per user, and block logins if the limit of logins are reached.
Please forgive me, if i am not clear with the description.
Thanks for any help.
I would use the SessionID in the Session object as the key, I'd store that along with the UserID for the logged in user in a database or some kind of backing store. I'd use Session_End in the global.asax to remove the records above for any session expiring and also remove them in any logout function. You should find it fairly simple to count the number of active sessions you have and confirm that it's not the same user logging in again, if that's allowed.
What I would do is use the global.asax file and increment a counter in session_start and decrement on session_end.
Since the session is stored in a cookie, several sessions on the same computer only create one session.
Here is a good refrence for the global.asax file:
http://aspalliance.com/1114_Understanding_the_Globalasax_file.3
I would use the Membership.GetNumberOfUsersOnline method, if you are using the Membership API, to determine the number of active users.
I believe this number only counts the number of users you have authenticated so it is safe to use in your scenario.
I'm starting to size up a project where I feel security needs strike a little closer to home. What tools and techniques could I look at to attempt to raise an alarm when a valid login is used, but the owner of the login has given it away or had it stolen. I would prefer ASP.NET, then MVC 3, oriented stuff.
This is not a silver bullet, but perhaps you should consider employing some kind of two-factor authentication. For example: when a user creates an account with you, you require that she provide you with a phone number where she can receive text messages as part of the registration process. Then, when she attempts to log in, you text her a temporary authentication code to be used in combination with her username and password.
This ads an extra layer of security to the system, because an attacker would have to both know her username and password and have physical access to her cell phone in order to compromise her account.
I hope that's helpful.
Seems like you would get a lot of false positives... but you might try checking what IP address the login is coming from. Most people will log in from the same IP address most of the time, so when that changes, it's at least a warning sign. If you want to be very strict about security, you could maintain a whitelist (for each account) and require that they get their IP address added to the whitelist before logging in.
My bank (Chase) does this by checking a secure cookie during my username/password login. If the cookie is missing or corrupted, they require a second form of authentication, which is either a code sent via text to my phone number on file or via email to my email address on file. Once the second form of authentication is complete, they set the secure cookie and then I can login from that browser with only username and password.
Implement your own Membership provider and add field locked to model,
check for user being locked on login and do some actions
It might be useful to think of the factors of the Authentication process, so that you can be sure that you are sufficiently covering things. You can easily get ridiculous with the layers of assurances, but I happen to find that most banks now have a variation on a simple model. All of this is, of course, over SSL
User submits account name. Additionally, you can require a secondary piece of information, last 4 of account number or year part of date of birth.
Optional, but a good idea: present the user with a counter sign, that is something that verifies the identity of the server. The user selects this at registration and should be looking for this every time they attempt to log in. This aids in preventing phishing.
System checks to see if the current system using IP lookup or cookie is associated with the account. If not, presents challenge question along with password input. Otherwise, presents just the password input.
Complicated, but can actually be done in 2 pages and more secure than is usually required.
I've presented this workflow to a few bank clients and they usually remove one or two of the checks for a balance of user friendliness.
With phones with text capabilities being so common, the idea of SMS verification code as mentioned by others is also a good idea, though I haven't implemented this in a system yet, personally.
I am wondering what are the technical hurdles involved with offering a voting system (or say ratings) without requiring the user to sign in. I know there are issues with robots, voting a bunch - but what if you keep the users IP address? Do proxies become an issue?
I'd like to build a public voting system that is still reliable.. is that possible right now?
EDIT
The stakes are moderately high for correctness, that is human-verification, and one-vote-per-user. A full-fledged login will ask too much of the user given his role (voter)
Also, if this is "impossible" to accomplish, how can you detect vote fraud after the fact? Could wikipedia's model work here?
Thanks,
Matt Mueller
As you said, you'll need to handle robot behavior.
If you log an IP address, you'll have problems with corporate users which usually stay behind a proxy, so everyone seems to have same IP.
Maybe you should to display some CAPTCHA image to validate human votes. Can't be that hard for users, since it's suppose to vote only once.
EDIT: How to enforce one vote per user?
You can:
Ask for a valid email and send a link to vote
To log your user in and let it vote
Let user vote and save a cookie
Let user vote and ban user IP
All this options have a weakness, so you'll never be sure.
To handle this problem "definitely", you'll probably need to bind their virtual identity with their real identity. This can be done by asking for personal information and keeping it. But that brings a whole new problem set.
First of all, be sure the voting uses POST to prevent robots and pre-caching clients to cause a vote.
Restricting IP addresses will cause problems with dynamic IP ranges, proxies and people sharing a connection, so I wouldn't go this way.
Most of those systems remember that a user a voted using a cookie, but this can of course easily be tricked by deleting the cookie or just using a different browser.
I'm looking for the simplest solution to this situation:
I have a pre existing web store with a shopping cart using .NET (vbscript)
I customize what products my customer's see based on the subdomain they use to come to my site (customer.mysite.com)
What my customer's are requesting is, instead of typing in their billing/shipping addresses each time, that they have a selection to choose from from previous addresses they have used.
How can I accomplish this, keeping in mind that they don't log in, they simply use the subdomain to come in to my site and place orders without a user/pass.
The simpler (easier to implement) solution, the better.
Why not just show all the addresses for that subdomain, but, due to some privacy concerns, I would wait until they type in a street address, then show them the addresses for that.
Otherwise, everyone on that subdomain will see the address of everyone else on that subdomain.
If they don't care, then just show all the addresses for that subdomain.
Or, give them an option to login and order, and then when they do that, then you can show them all their addresses they shipped do when they are logged in.
The last one is the preferred one, IMO.
If they don't login then I assume you don't have them create an account either. Thus the server won't be able to identify them. In this case I think you are left with using client cookies. Just make sure you don't store sensitive data in them (like credit card).
I would place a cookie on the users computer with the address information in it attached to the subdomain. The down side to this is that you should not put sensitive information inside cookies but depending on the nature of your business this may not be a problem for you.