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.
Related
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 :)
I've heard from more than one IT Manager that they don't allow users to user RDP to connect to their internal network from the outside, because it's not safe. They claim that if they'd allow their users to do so, then anyone from the outside will have access to their network as well.
I'm not getting it. In order to use RDP, you need a user name and password, and you can't get in without it. The same is for using Gmail, online banking, and any other web service.
So what do they use instead? LogMeIn. Or a VPN connection, and then use internal RDP. VPN also requires a user name and password.
If they're afraid of a brute-force attack, then someone can brute-force attack the VPN server or LogMeIn just the same. And if these other technologies have lockouts (after x number of failed attempts) then why can't the same be set up for RDP?
Similarly, people always say that VPN is very secure because it uses a "tunnel". I don't fully understand what that means, but regardless, why can't the username and password be cracked the same way any website or web service which uses a user name and password can be.
With proper configuration, RDP is capable of 128-bit RC4 encryption, virtually any port or set of port allocations, and has proven to be relatively bug-free, with only extremely minor flaws ever discovered.
On the other hand, the secure tunnel created in a VPN is far more secure than Remote Desktop. All your data is encrypted for safe transfer from one remote location to another.
Moreover, VPN only allows shared content to be accessed remotely to tighten the security. If your device falls in the wrong hands, they won’t be able to access and manipulate unshared data and resources.
The bottom line is that both RDP and VPN have their own advantages, however, with high security, better performance and manageability, VPN seems to be a clear winner in the competition of Remote Desktop VS VPN service.
I have a web service with several web methods, each web method requires client machine to send their MAC Address and the server will validate this client base on this information (if not valid then return error) before proceeding to further operations. The communication between client and server is HTTPS. I only have about 20 clients or so. The question is is my way of doing this right/secure or not? If not then is there any simple way to do this?
Thanks,
It depends on your security requirements, there is no one definition of "secure enough". As others have said, the MAC can be spoofed, and is in effect just a shared secret/password. However, that is sufficient for many scenarios, when the confidentality of the connection is ensured by HTTPS. You need to define what threats you want to protect the system from, and how much you're willing to invest in security.
No, it's not secure because anyone who knows a valid MAC address in your database could call the web service. Of course knowing a valid MAC address in your database is unlikely possible, it's as if he knew a password.
The client can spoof the MAC address of the machines which is authorized. So, this is not secure.
Protecting your webservice through client certificates would provide better security.
Tutorial : http://www.codeproject.com/KB/WCF/9StepsWCF.aspx
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.