We are developing an ASP.NET Web Forms application and we need to allow users to login, only from their own PCs.
We have been thinking about this for a few days and we have come up with these solutions:
When defining a user, specify the IP address from which he can login, and later, check if the request IP matches the one specified for the user. (The user can change his IP very easily. We cam limit the user, so he is unable to change his IP, but again, this is not 100% secure).
Use ActiveX and get the clients MAC address and check if the username is allowed to login from that MAC address. (This is not a good choice since we want to avoid ActiveX).
We want to go with the first solution. I know there is no 100% secure solution, but I wonder if there are any better solutions than these two.
ActiveX will not work on client machine or no any hack is there to get client machine details better and safe solution is IP address and if you wanna extend security then you can create service(exe file) that will run by client to identify himself :)
Related
I have been asked to get details of every user that logs into our website. Is it possible to capture the IP address of every user that logs into our website from which I can gather details using IP lookup software.
It's already captured. Check out the web logs for whatever your webserver is.
In IIS, it's likely in C:\Windows\System32\LogFiles. Apache will normally be in /var/log.
You can tweak the specifics of what it captures, but by default IP address is always included.
Unless you are explicitly required to store the ip:s yourself, I recommend using Google Analytics, which will sort out unique/returning visitors, geographical locations and so on.
I'm developing a network application which should be capable of contact DNS servers.
I was wondering what would be the best way to do it. And browsers came to my mind.
For example, how Firefox or Chrome resolve the Domain names i put in the URL bar?
I mean, i type http://www.google.com, how does it know that has to make a TCP request to the IP 209.85.195.104?
Thanks!
In the simplest scenario, browsers would use a function such as gethostbyname() to resolve names to addresses. However, this function is not always implemented in such a way that's convenient for a browser (it usually blocks until it gets an answer).
Browsers today are starting to use "DNS prefetch", where the browser will send DNS requests directly to a DNS server as the page is loading, to resolve addresses before the user clicks on the next link. That way, the user doesn't have to wait for name resolution when they click, and the browsing experience appears faster.
Web browser send request to DNS server. Server send list of associate addresses (if domain name record do have, several IP addresses - example is cnn.com with several IPv4 and IPv6 addresses).I am not sure if this addresses store browser or Operating systems but if browser use first address and don t get answer he will use another address from list. I read somewhere that it waits max 30 seconds until he use another address from list.
We are in the process of building a new website which we want to lock down to specific computers to only allow access, then once the pc is authenticated we will do our in built user authentication.
Also, when a pc is known, we dont really want anything on the pc which can be easily transfered (by the client) onto another pc in order to gain access to the website.
Please can anyone give us an idea on the best way to achieve this 'lock down', we dont really want to go down the AD route and have loads of extra user data to maintain.
Thanks in advance.
Richard
IP and MAC addresses are trivial to spoof. Without Trusted Computing, there is nothing you can really trust to authenticate a PC. What you need to figure out is what can you do that gets you an acceptable level of trust. Here's what we have done with our "locked" tokens: They take some info from the PC and hash them and send that hash to the auth server. Any requests for an OTP then needs to be accompanied by that hash. It's not perfect, but it also handles mutual https authentication, so it thwarts network-based MITM attacks too. If the token is stolen, the attacker must also know what info to spoof and spoof it. Again, it's not perfect, but better than nothing given the current state of PC security. http://www.wikidsystems.com/downloads/token-clients and our sourceforge page: http://sourceforge.net/projects/wikid-twofactor/
specific computers on your network?
set some IP restrictions in IIS, this assumes your DHCP box is giving out static IPs.
The only way a user could "transfer" the authentication is to take their NIC with them, or clone its MAC address.
Install Helicon Ape free and put .htacces and .htpasswd files in the root of the site you are trying to protect.
I'm building a website that just allow each person in my office to access the page from their own PC placed at the office only. It looks like I need to identify a client from within the codes on the ASP.net web server. How can I do this? Please help!
This is going to be tough if it needs to be watertight.
Ideas:
Maybe easiest: If the computers all have fixed LAN IPs, maintain a table of IPs and users. Allow users to log in from "their" IP only.
Use a cookie to tie a computer to a user. Create a "connect this computer to my user account" page. That page set a cookie that lasts forever on the user's computer. The cookie contains an ID that is associated with a user name on your server's end. This requires the trust that the user is actually on their computer at the time of "connecting", but you wouldn't have to do any work on their computer directly.
If your colleagues are confined to using one Browser, see whether you can use that browser's user agent and inject some unique value. This can be done for Internet Explorer by modyfing a registry value IIRC. This would require you to access each computer individually.
Install a small service on each user's computer that sends back a pre-defined ID code when connected to. The ID identifies the computer the user is accessing the site from. This would require you to access each computer individually.
re your comment: Totally crazy idea: Write a script that logs into the network router, parses the "DHCP clients" table, thus finding out which MAC address has which IP address. Not a quick job and not a clean solution but, if the router has a web interface, it might be possible. Of course, you may have to adjust your script when the router gets an software update.
None of this will be reliable enough to protect against criminal activity, but should do to identify a computer under normal circumstances.
Assumption:
computers in the network are assigned a static IP addresses..
Possible Solution:
Associate each IP with each specific user.
Each time a user tries to login to the service, ask for their credentials i.e. username, password and check if those credentials match the IP address associated with the username and password stored in the db.. just a thought!
I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.
All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use Request.UserHostName and then Dns.GetHostEntry. The result is then compared to a setting in my web.config (that holds something like *.mydomain.local) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.
However, my problem is that I don't always get the expected value from Request.UserHostName. on the development site I get the IP-number (?) of the machine running the browser but on the customer site I don't get the IP-number of the user machine, I get some other IP-number. The browsers don't have any proxies set or anything like that.
Should I be using something else than Request.UserHostName?
I recommend using IP addresses as well. I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening. External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.
To deal with it I just check for that one IP. If I get the IP of the gateway, I provide the internal access. If I get anything else they get the external one which requires additional authentication in my case. In yours, it would just mean a different interface.
Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.
There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.
Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".
It looks like you're being returned a public facing IP Address. Get the user to go to http://www.myipaddress.com . If this is the same as the IP Address returned to your software, then this is definitely the case.
The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option.
It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.
I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.
Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).
If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.