Web application vs client/server native application security wise, which is better?

I am developing a admin interface to do CRUD on sensitive data on a remote server over the internet that need the best security protection. I have 2 choices in hand, but I could not figure out which is the better way to do it.

1. Create a web application using LAMP+SSL and control access using methods such as IP filter, password etc.

2. Create a native server/client application and communicate using TCP socket with SSL-like encryption and control access using password.

I am fully aware that there is nothing safe after putting on the web, and I h开发者_运维百科ave considered the option of tunneling into the server and run as a local application.

However, that would be quite difficult to use from the user perspective IMHO, so other than that any better options that is user friendly?

Not very familiar with security stuff, so any advice will be helpful. Thanks.

---

Neither approach you list is inherently more secure than the other. If you go with a TCP socket then the danger is that someone notices that the server is listening for TCP connections, connects to it, and works out your data exchange protocol. If you go with the web-application approach then the danger is that someone discovers the website URL, makes it past your filtering, and is able to establish (or hijack) an authenticated session.

Either one requires the attacker to execute the same basic steps (discover that the service exists, connect/access the service, convince the service that they have rights to perform protected operations). Either one also requires that you either know what you are doing or thoroughly do your homework in order to create a system that is truly secure.

So in that sense, I'd suggest going with whichever approach you are more familiar with. Of course, it's worth considering that there is probably a wider range of prebuilt security libraries and tools to choose from if you go the web application route. For instance, there are probably a number of Java Filter implementations that can let you specify IP-based blacklist and whitelist parameters, and many servers will include a prebuilt framework for handling user authentication, and so on.

---

As far as tcp socket vs. https there's likely little difference in security. Since the socket is less 'standard' it may have marginally more protection because a simple off-the-shelf browser + standard http[s] might not work. However it's really more obscurity than security.

You have to think about 2 things: Privacy: ensuring others can't see the data in transport. something like SSL should cover this. Authentication: The server trusting that the client is who it says it is. That's the harder problem. If you require a 'password' of some sort it helps but of course you have to manage the password etc. That's a big topic in itself.

---

The strongest encryption in the world is irrelevant if your users have "12345" as their password. If you're that concerned about security, don't use passwords.