I have several independent PHP applications running on few servers. None of the servers have SSL, but I'm able to use PHP wraper for SSL. I would like to ensure all data sent between servers is safe and signed. Do I need to generate an certificate or is it enough to create public/private key everytime I send something? Is this aproach safe?
Do I need to generate an certificate or is it enough to create
public/private key everytime I send something?
Don't generate a public/private key every time. How would you be able to check who has control over the private key? The point of certificates is to be able to bind an identity to a public key: checking you trust the certificate and that you're willing to communicate with the identity it refers to is a necessary component to secure the communication.
From what I understand, the communication between the servers doesn't involve user interaction itself. If you control all the servers, you could give them certificates, either self-signed X.509 certificates (if you can install them all for all parties: only applicable for small numbers in practice) or your own CA (if you have OpenSSL, look into CA.pl, which has a man-page).
You could then sign an encrypt the content you exchange using S/MIME (there are functions available in PHP for this).
(You might also be able to achieve the same goal using PGP, using PGP keys/certificates instead.)
If both machines have mcrypt then you could probably encrypt the text you want to send over the wire in PHP at one end and decrypt it at the other, but of course the big issue you have here is going to be key distribution. You'd either have to pre-configure each machine with the correct key and hope nobody notices you're using the same key every time (which is bad), or you'll have to come up with some kind of way of distributing your key to the receiving machine when you send data without the key being snooped. (which is complicated).
You also mentioned signing, which is also a tricky issue.
Whilst it would in theory be possible to implement all this in PHP using an appropriate extension such as mcrypt, I honestly doubt it would be worth the effort of doing it right, which would be considerable, You'd also just be reinventing the wheel.
SSL implements all the stuff you need already and is the accepted industry standard, if at all possible I'd strongly recommend you install it.
In a little project of mine I use Blowfish encryption for some data transfer, using the mcrypt extension that's available on most servers:
$encrypted = mcrypt_encrypt(MCRYPT_BLOWFISH, 'here goes a key', $data, MCRYPT_MODE_ECB, null);
Decrypting goes the same way, just use mcrypt_decrypt. This is a shared key, not a public/private key system.
Related
I am currently managing two servers that have a shared secret key.
I would like to be able to send data between the servers in a manner that even if someone is listening in the middle, the data will be only read if someone has the secret key.
My requirements are:
encryption
authentication
But also:
freshness: so that old encrypted data that has been intercepted in
the past will not be accepted if transmitted now by someone else.
I was wondering if defuse/php-encryption is applicable to this scenario given that it provides encryption and authentication.
I also took a look at libsodium but I want to stay away from PECL if possible.
Thank you.
I would suggest that you use an existing cipher suite that can "blanket secure" the entire connection between the two parties. Then, in any case, use digital certificates (they can be self-signed ...) to secure the connection. (Do not use "shared secrets," a.k.a. "passwords.")
TLS (the successor to SSL) is used by HTTPS secure web-sites. (Be sure to use the current version of this protocol!)
VPN (as "OpenVPN" or "IPSec") provides "a secure router" between two subnets. The advantage of this strategy is that the two parties don't have to do anything to obtain a secure, reliable connection: it’s just there.
SSH is also able to do "tunneling," but it's too-easy (IMHO) for data to wind up actually being passed insecurely, and it really doesn't provide identity-verification.
These cipher suites will provide you with three very important guarantees:
The data is not intelligible to any other party.
There is no "man in the middle." The parties can identify exactly with whom they are communicating.
Messages received are known to be "exactly what the sender sent."
Nothing in-secure is passing "out of band" between the two parties.
... and yet, they operate completely "in the background," just as you routinely see TLS doing when you connect to a secure web-site. "It is secure, and 'it just works.'" It is very important that your scheme be unobtrusive to authorized users.
I have an android app that needs to connect frequently to the server to retrive or add in the database sensible data. I needed to verify that the calls to the server where being made from the app so I used this approach: how to verify the identity of the client from the server? which consists in a hardcoded string key in the app that's verified in the server.
But then I realized that there were tools like dex2jar, that would reveal all my code (Even with some obfuscation from proguard) in particular this hardcoded key.
Is there any more elegant and safe way to verify that the server calls are being made from my app?
PS: I'm sorry for the English, clearly I'm not a native speaker.
If it's only your client and your server, you can (and should) use mutually-authenticated SSL without purchasing anything. You control the server and the client, so each should only trust one certificate, the one belonging to the other and you don't need CAs for this purpose.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
You'll normally store that certificate/private-key in a keystore of sometype (a KeyStore if you're using Android) and that keystore will be encrypted. That encryption is based on a password, so you'll either need to (1) store that password in your client somewhere, or (2) ask the user for the password when they start your client app. What you need to do depends on your usecase. If (2) is acceptable, then you've protected your credential against reverse engineering since it will be encrypted and the password will not be stored anywhere (but the user will need to type it in everytime). If you do (1), then someone will be able to reverse engineer your client, get the password, get the keystore, decrypt the private key and certificate, and create another client that will be able to connect to the server.
There is nothing you can do to prevent this; you can make reverse engineering your code harder (by obfuscation, etc) but you cannot make it impossible. You need to determine what the risk you are trying to mitigate with these approaches is and how much work is worth doing to mitigate it.
I am new to the whole encryption world, and I wish to build a Mac application which interacts with a PHP application in order to access and manipulate data remotely.
My problem is that I can't just transfer plain data over the internet, as most of the data being transfered can be very private, as well as username and password are passed for authentication of the user.
I would like to know what kind of encryption/decryption methods I need to use in order the data will be transfered safely over the internet.
Shillo.
The easiest thing to use is SSL with HTTPS. This is well supported by just about any system and HTTP library. No additional encryption is typically necessary.
To do this, you simply need to purchase an SSL certificate and install it on your web server. You can generate one on your own for free, but a certificate authenticated by a 3rd party is often preferred.
i have client-server application (objective-c and php).
how can i encrypt data on client and then decrypt on server?
the simpler the better
The simplest way to encrypt data traveling over the network is going to be to simply always use TLS to connect to your server running your PHP app. You could verify a particular certificate from within your app if you're afraid of sophisticated man in the middle attacks, though that will make your app fail to work without an update when your certificate changes.
If you truly need encryption/decryption at the application level, not just transport, then you should probably use RSA public-key encryption. Your client will have the public key, your server will have the private key. Apple has documentation on RSA encryption.
Okay, rule number 1: DO NOT write your own cryptographic routines.
Given that, there are some standard cryptographic libraries available. OpenSSL is recommended in this SO article.
Use SSL/TLS protocol, OpenSLL have the implementation of both, check this tutorial, its in c but may be a good start to you.
This is for an iPhone app which needs to send encrypted data to a web page running php. Symmetric or asymmetric encryption is fine. Example code would be greatly appreciated.
Using SSL would be your best bet.
Look up AquaticPrime on the web if you want sample code, includes PHP and Objective-C. This is a package based on SSL for license key generation.
PHP has the Mcrypt library available to be installed which has a number of algorithms. Find a similar library with support which is callable from Objective-C, and give them a try. To avoid having a key on with the program, asymmetric or public key would be more secure (otherwise, it's just giving the password away).
http://www.php.net/manual/en/function.mcrypt-decrypt.php
You can encrypt it on your iPhone app and then decrypt it in PHP. You can pick an algorithm which is supported by both platforms (possibly AES). For the key, you could do something like concatenating the user's password and a long string (salt), the string being hard coded into the iPhone app and the PHP app.
That way, an attacker couldn't decrypt the messages without knowing the user's password, and both the PHP and iPhone app would know this password.