I understand that PCI compliance affects not just storage of card details but does it also affect transmission. E.g. if I simply want to collect a card number and transmit it over https does this require PCI compliance steps to be taken?
PCI does require protection for card data at rest and in transit, so yes, this will require you to take steps to comply.
This is covered in great detail on Security Stack Exchange using the PCI-DSS tag.
Yes, if you transfer card data somewhere (no matter - between user browser and your server, between your scripts, between script, database and back, between your server and PayPal / Authorize.net / whatever) - you must make all this channels secure.
Say, with SSL layer. Do everything using HTTP*S*, not just simple HTTP and make sure your server's SSL certificate is correct, and up to date.
Related
I am thinking about a complicated chat application where two clients can connect to each other directly like in a p2p network. My idea complexity is both about network and the security (authentication).
NETWORK PART
As far as I have read on internet, p2p connection can be achieved by TCP HOLE PUNCHING. In most examples of Hole Punching, I have seen a middle server that helps clients pass their address to each other. Imagine that server goes down. I still want my clients to be able to find each other. A very crazy idea is for them (for example my application users as human not the code) to use any other communication channels to tell each other a code (which is generated from a data). I want this data to contain client {local ip, local port, public ip and public port} (which in all examples of TCP hole punching that I have seen, they were used).
Can this data be found by client itself? and is it enough? (Consider help of extra HTTP REQUESTS from client to find about his PUBLIC IP ADDRESS)
Also, are there any better ideas than using TCP Hole Punching? My clients are mostly behind NATS
AUTHENTICATION AND SECURITY PART
I am trying my best to rely less and less on a middle server for helps. My client applications can perform Diffie Hellman key exchange and encryption after their connection established. But as I want real users to use this application, I need some ways that clients can authenticate each other. I am not looking for this app to be used by wide range of users. So maybe they can actually see each other sometimes (in the real world) and transfer some sort of files with their bluetooth (or other file sharing systems in application layer) that can be their token or authentication token. This token may later be used to authenticate each other later when they want to establish connection in network. Well this is my only idea:
The problem here would be if Jack and Rose meet and they transfer their personal tokens, later Jack has Rose authentication token and can use it to pretend to be Rose when he is talking to Jim.
Unless this token is generated with same value for both of them and somehow means its token for only {Jack and Rose} communication, and token for {Jim and Rose} is different. (I mean its unique token for any conversation or pair of users)
Would there still be any risks? Can any sort of networking attacks or other tricks, break this?
You can refer to WhatsApp end-to-end encryption white paper
https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
I have multiple clients sending data to a central server. Is there a way I can ensure that the server get the data but in no way it can associate sender with the data.
If the clients are identified using IP address, then spoofing is a way to make sure that they are not traceable. To spoof, you need to identify the packets the client is sending to the server. In Network layer, you shall find the IP bits, which you need to replace(or remove, if it works).
(Use wireshark tool, it might be helpful)
Although, it shall still be considered a malpractice in the society. I sincerely advice you to contact the server administration, to discuss and put in place other security measures instead of spoofing.
I was wondering how to read certificates put in a SIM Card, (http://stackoverflow.com/questions/12705603/read-write-certificates-on-a-sim-card-ios), but the fact was it depended every time on the phone considered, what was a bit unconvenient.
Then I bumped into this report, saying that you could implement secure HTTP Servers on SIM cards.
My question : does someone know how to configure/use this technology? For instance, check certificates via http ? (Any Documentation would be welcomed ! )
Thanks,
Let's say I want to make an application where stored data is encrypted so only my application is able to read it.
But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.
The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.
Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.
Cheers.
More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.
But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.
Interesting problem.
Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".
However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.
If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.
The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.
As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.
Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.
With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.
You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.
As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.
Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.
Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.
Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:
-----------------------------------
/ IPSec tunnel \
+---------+ \
A | IPSec | B Untrusted \
trusted network -------| capable |------- Networks ----------- Your application
| router | Internet, etc.
+---------+
The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.
If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.
You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.
I'm looking for options for securing UDP traffic (mainly real-time video) on a wireless network (802.11). Any suggestions apart from Datagram Transport Layer Security (DTLS)?
Thanks.
You must be more clear about the attacks you are trying to defend against. For instance if your only concern is spoofing then you can use a Diffie–Hellman key exchange to transfer a secret between 2 parties. Then this secret can be used to generate an Message Authentication Code for each packet.
If you need any more protection I strongly recommend using DTLS. It should be noted that all TLS/SSL connections can be resumed so you can cut down on the number of handshakes. Also, certificates are free.
Are you trying to wrap an existing application or writing your own? What client server setup do you have? Do you want to prevent snooping or tampering?
I am assuming here that you
are developing an application
are trying to prevent snooping
have access to client and server.
The simple approach is to use any off the self strong encryption. To prevent tampering use any signing algorithm with a private/public key scheme. You can use the same key pair for encryption and authentication.
The drawback of this approach is that it is on layer 7 and you have to do most of the work on your own. On the other hand, DTLS is a viable option...
Have you considered IPSEC? This article provides some good guidance on when and when not to use it.
You can look into ssh with port forwarding. That comes at the cost of maintaining a TCP connection over which the UDP traffic can be secured.