-
hypuk,
Your first move should be to get the vendors of this system to explain what security measures are in place to prevent the interception of data over what appears to be an insecure local network.
If your guests can just "find and connect to" your network, so can anybody else.
My personal views would be:
1. I would not send my credit card details over a WiFi network in a railway station or public library, so why should I do so at your hotel?:eek:
2. When A hotel charges me for services, I expect those to appear on the bill I check before I leave. Just like the telephone calls and pay per view TV.
3. Whilst your security concerns might not be with your guests, they certainly should be with people who are wardriving within range of your network as you know that those people's intentions are not honourable.
It sounds to me as if someone in your organisation with no IT knowledge has "just gone out and bought the system" That is not the way to do things, as security should have been a part of the original Business Requirements Specification.
If the vendors cannot satisfy you, I would recommend getting a professional IT security auditing firm to look at it.
I would really need to know much more about how the system works and what features and options it offers to offer any suggestions as to an alternative implementation strategy. In all honesty, those are questions that should have been asked before you went out and installed anything.
-
i would tend to agree with nihil. a safer way to handle the accress would be to issue a cardboard card with an account number on it that is associated with the patron's room number. When they connect to your network, they get directed to a web page that requires them to enter the account number, at which time the mac address of the device is added to the allowed mac filtering list.
this prevents people from having to enter credit card data over an insecure connection, and gives you a means of adding the charges to the room bill, which is what i'd expect when travelling.
just my 2p.
-
Another point is that diving straight in and trying to hack the system proves nothing, apart from the fact that you don't know what you are doing?;)
The correct sequence is:
1. Does the application support the security that I require? if the answer is "no", then there is no need for any further investigation. You need to look at a different implementation strategy or a different product.
2. If the answer is "yes" then the next question is: "has it been set up correctly?" Things like routers, operating systems and applications are generally insecure straight out of the box, they need to be configured properly first.
3. Once you are satisfied with the answer to #2 then you start testing.
It would be most embarassing to report something as being insecure, and then have the supplier demonstrate that the problem was that you didn't understand how it worked and hadn't set it up properly?