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
Related
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 am designing a mobile application which is supposed to interact with a remote server through the HTTPS protocol. This means that the system will manage to encrypt messages and keep the communication confidential by using a SSL certificate.
Well, I would like also to provide an authentication method in order to protect the system from external attacks and make it accesible only by users with valid credentials.
I'm now wondering if Digest HTTP Authentication (http://php.net/manual/en/features.http-auth.php) could be a good idea or not.
I guess so, especially because I think there should be no particular risk since that way I should manage to combine encryption and authentication.
However, I've read somewhere that if I use SSL, HTTP basic authentication is secure enough. Is that true? What do you guys think about that?
Do you guys by chance have any suggestion?
Thanks a lot!
I have a Client-Server-Application, which allows users to run any code on the server over network. I want to protect the user from connecting to some other server, that behaves like the real thing, but steals passwords, how can I do that?
Neither the Server nor the Client can be expected to have internet access, the certificate authority is out of the question. Is there any other way to verify that it's my code I'm talking to, even if someone gets the source code?
The simplest solution is using SSL with a self signed certificate. Then hardcode the server's certificate into client. Most SSL libraries offer some way to roll your own certificate validation logic, or change the collection of valid CAs.
This assumes you can keep the server's certificate secret.
In principle SRP could be an alternative. But you should not implement it yourself, since it's very easy to make subtle mistakes that appear to work, but make the system insecure. Some SSL libraries, such as GnuTLS have support SRP.
Is your attacker likely to gain root access to your real server? If not, then you can establish a self-signed certificate (as suggested by CodesInChaos) and rely on operating system permissions to prevent unauthorised users from reading the private key file. You can then be confident that your clients are only connecting to your real server (via SSL).
If an attacker can gain root access to your real server, you have many problems to deal with. Firstly, the attacker can read process memory at will, so any sensitive materials exposed in server memory (such as the passwords you mention) will be accessible. Also, the attacker can steal your private key and establish their own server (although why would they, when they can simply snoop on your real server memory).
Am i correct that when using State Server traffic between my web site and the state server isn't encrypted? If it isn't, how can i secure it (SSL)?
The ASP.NET Session State server uses clear-text http-requests in a rest-like manner for communication. The actual protocol specification is publicly available at [MS-ASP]: ASP.NET State Server Protocol Specification.
I've never heard of anyone encrypting the state traffic, cant find any references for it, and nothing that states that it's even possible.
It's impossible for any of us to say whether the traffic between your web site and state server is encrypted or not.
At a high level, state server uses clear text for transferring the data. But this doesn't necessarily mean it's not encrypted.
However, depending on how your network is setup it might be encrypted at a lower layer by the operating system. Namely, if the machines are part of a domain the network administrator might have turned on the proper settings to force kerberos encryption between the machines.
Further, if you encrypt the data prior to putting it in "session" then it would obviously be encrypted.
If you are worried about internal threats then your network should be configured to encrypt all traffic between machines. (if you want to know how, go to serverfault.com).
The state server should be behind the firewall and not public, there should be no reason to encrypt the traffic. You would only want to make sure that the traffic is only able to go to and from the web tier to the state server via network layering.
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.