Limiting number of computers from which users can access ASP.NET website?

I'm building an ASP.NET application. One of the reqiurments is to limit number of different computers from which users can access the content of the site (for example 5 computers). It doesn't have to be perfect, if a normal user, with no IT knowledge will not be able to ommit the checking - the solution will be K.

I'm thinking about a way to get a fingeprint of the user machine (for example: a combination of MAC and compuetr name). Of course, users will be informed about checking their MAC. Howevew, it is hard to do, because HTTP protocol is stateless. One solution is to use ActiveX. But it's limited only to Windows systems, and it's to easy to pass the security checking (by just disabling ActiveX, which as far as I know is disabled by default).

As I googled, it's a quite common question, but there are no solutions other then using ActiveX. Had any one had this kind of problem, and found some good solution?

Users can be in different networks. It will be an extranet application, so checking IP will not work (routers, and dynamic IP's).

EDIT: What I want to achive by doing this is to avoid buying membership, and then share the account data to all your friends.

From stackoverflow

• Unless we are talking about limiting users who are all on the same LAN, why could you not just track the IP addresses of users and if they come from an ip address that is not on their "list" then you can turn them away and not authenticate?

  Eric Petroelje : This would be a problem if the user's IP address changed - pretty common, especially if they are on dialup.
• • Use a firewall with MAC Filtering/IP Filtering
  • An IP Whitelist in the Application
  • A threshold of "Logged In" users in the Membership Provider

  Whats the scenario, is it a public facing web site or something that you're gonna host internally on a Private LAN

• If limiting within a certain timeframe is good enough - that is, the user can only use five different computers in a day, a week or a month, you could always check for ip adresses. Every time a user tries to access your site, you could have the following algorithm to see if you should allow access:

  1) Check what IP adresses have previously been used with this user account. Is there less than 5 unique IP's? Yes => 3. No => 2.

  2) Five or more IP's are already stored. Are at least one of them at least one day/week/month old? Yes => 3. No => 4.

  3) It's OK - less than five IP's are stored, or at least one is too old. Delete any that are too old, store the new one and authenticate. => 5.

  4) It's not OK - five or more IP's are already in your database, and none of them has expired yet. Do not authenticate. => 5

  5) End

  Adam : Yes, it would be a good solution, but users can have dynamic IP's, that can change quite often.

  Tomas Lycken : And that's exactly why this would only work if you limit yourself to a time span. How often do you assume a dynamic IP client recieves a new IP address? If your timespan is shorter, the old IP will be marked as "old" after the change.

  Adam : Hmm, it's a quite reasonable solution.

  bmb : Five computers in the same house using the same router will look like one computer.

  Tomas Lycken : They will, but Adam hasn't specified _why_ he wants to limit access to five computers per account. In case two computers in the same household should still be considered two different machines, then my solution isn't a solution because as you say, coming through the same router the web app won't be able to tell the difference. But I don't see a reason to consider these machines different - if the user has access to all of them, it is probably pretty random which one he/she chooses to use.

• Is it only 5 specific computers? Or no more than 5 simultaneous computers? It's not a perfect solution, but you can increment/decrement a counter on session start/end respectively.

  EDIT: Ok in that case I would probably go for a cookie based approach (again not perfect). When a PC connects deposit a cookie on the client computer, and record that one's been issued on the server. When #6 attempts to connect, block the cookie and deny the connection.

  Adam : Not simultaneous computers, but lets say than not more than five different computers in a month.

• I think you should consider using of WCF web service and custom WinForms/WPF client with authorization.

  Adam : It has to be an ASP.NET application.

  Mike C. : -1 for not attempting to answer the actual question.

• Use (tracking) cookies? Even though this would be on a per-browser basis and not per-machine basis and of course require the user to have persistent cookies enabled, it might be good enough? Check if the cookie exists and shouldn't have expired, if it does it's all fine and dandy - if not, add it and keep track of this in your back-end...

  Shielding access by IP, network or any other network-related criteria, while having its own problems of course like most users not having a fixed IP or if so, is sharing it with many other users through the horrors of NAT, should most likely be done by the publishing firewall(s) and not the application itself.

  Getting a fingerprint or any identifying stuff off of someone's computer by a simple web site should be mostly impossible (one hopes) and instead require the installation of a local application or plugin by the user.

  Edit: The newly added information about the reason makes it rather clear that any such solution will be annoying and cost extra to develop and maintain. The answer about circumventing the need for this restriction at all seems best.

  bmb : +1 for probably being the best idea, but seems like even unsophisticated users know how to clear browser information.

  Oskar Duveborn : Yeah but if they clear them, they prevent themselves from accessing the site - not the other way around... you'd need to inform the users of this of course :)

• Is this for a licensing scenario? If so, it's one of the silliest licenses I've heard of since the Internet came out.

  It's the kind of license that used to make sense in the context of desktop applications, but makes no sense in a web-based application. Your application will likely be the only one these users use that behaves this way. That won't look good for you.

  Adam : I was requested to implement this kind of functionality. The question is not about sense of this kind of solution, but is it possible to do, and how.

  John Saunders : Without understanding what the requirement is trying to acheive, you are unlikely to acheive it.

• Based on your comment

  The sense of this requirement is to avoid users from registering in the application, paying for the membership and than giving the credentials of account to other people.

  Either you go expensive and highly secure like RSA hardware authenticators

  -or-

  You change your business model and make it unattractive to share credentials. e.g. due to cost - I don't share my apple or amazon creds because I don't feel like paying for their purchases. Another is having a user community. Nobody shares their flickr account because those photos are artistically theirs, and they don't want anyone mucking with their stuff for the sake of a few dollars. Sharing is dissuaded because it's a community, not just a repository.

  But none of these things prevent users from sharing, but I'm sure it happens a lot less.

  You otherwise restrict yourself to mechanisms that (attempt) to passively monitor abuse. Too many concurrent downloads, too many concurrent accesses, etc. If your user violate the t's and c's of your agreement then you suspend their account. But you would have to have very obvious offenders, because it's very easy to get this wrong. It's a model to be avoided if you can because you're always going to play catchup and there's always going to be someone who rips you off.

  Nobody will sign up to a website if they need to buy an RSA device to access it. It's not a viable consumer solution.

  ---

  (Original answer) I think what you want to look at is using Client Certificate Authentication. Essentially your user installs a personal client certificate on their machine so that when they connect to your server, your server can verify that computer.

  I'm not going to tell you it's easy, because it doesn't look like it. You may need to set up your own certificate server and quickly googling it, none of it is pretty.

  Maybe, OS depending, there's a feature in there that you can create a certificate that is machine-specific, or one that can't be exported.

  This sort of thing is usually for secure connections between between servers, and not typically for what you want on the client side. This is going to be a helpdesk nightmare.

  wiki Transport Layer Security or windowssecurity.com Using Client Certificate Authentication with IIS 6.0 Web Sites or msdn Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

  You could also go the route of using RSA hardware authenticators

  Adam : I think that this is the best idea. To make the application so customized for the users that they would not want to share their accounts. Some frauds will happen, but a common user will have no interest in saharing his account data.