I'm uploading an encrypted file from Android phone to a server and decrypting the same file in the server side.
Client: Used HTTP post to send file to a server
Server: PHP
Encryption: Triple DES
I hard coded the keys and iv in both the client and server side. Is there any idea how to use the keys and iv so that the transmission is highly secured?
Thanks!
No. If you hardcode a symmetric key into a client application that runs on untrusted devices, it's practically no encryption at all. An attacker can just extract the key from his application, and decrypt all other transmissions.
Just use https with a single trusted root public key corresponding to your server.
If android encrypts the file immediately prior to transmitting it and the server decrypts it on receipt, then you should just use SSL/TLS/HTTPS.
Hardcoding either the key or the IV is horribly bad practice. If you hardcode the key in an application, anyone who can get the binary has the key and can read the message. If you hardcode the IV, even people who do not have the key can potentially do something( IV's can be public, but they MUST be random)
Related
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
I am working on a mobile app using Corona SDK. One of its core functionalities requires sending data between the app and my server. My question is, at what point do my attempts at making the data transfer secure become redundant?
The server side consists of a few PHP files and a single MySQL database. I have an SSL certificate and I validate the data at both ends. The app itself only makes network requests via HTTPS/SSL using HTTP POST and the data being transferred is a JSON string.
To this point, I believe that I have done everything as they should be done. However, as an extra precaution, I also encrypt and decrypt the JSON string at both ends using AES256-CBC.
Is this extra encryption at all necessary or is it redundant?
HTTPS protects the transport between the client (browser) and the server. It specifically does not protect data at rest at the server side (i.e. inside the database) not does it protect the transfer of the data between the PHP application to the database.
It is unclear if any protection outside the transport between client and server is needed. But it seems that your AES encryption will only protect the same path as HTTPS already does. In this case it will likely not add any protection. It might maybe add protection against legal (or malicious) SSL interception but if the encryption key is send over the same communication channel as the encrypted data then it will not actually add protection.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
For private use only, I'm creating and hosting on my web server a PHP application that retrieves all my passwords for various accounts from a MySQL database and serves them to the client that is an iPhone application which should also be able to insert new passwords in the database.
Instead of sending this data over the internet as plain text I would like to encrypt them before sending them but I'm very new to encryption so I'm feeling a little bit disoriented among all the possible encryption algorithms out there.
While the mcrypt function on PHP seems to be very flexible and compatible with many encryption algorithms I couldn't find anything like that on iOS.
What I wanted was some algorithm easy to implement both on PHP and Objective-C that, given some plain text and an encryption key (stored both on the server and on the client), would encrypt AND decrypt the plain text.
For further detail the server/client communication I had in mind was something like this:
Client sends a request containing some client-specific-app-ID and the service
whose password the server should return
The server checks if that client ID is allowed to get that information
If the client is allowed then the server querys the database and
retrieves the password
The server encrypts the password and sends it to the client
The client decrypts the password and shows it to the user
This thing is for personal use only so I don't need unbreakable security because probably nobody will care breaking it.
I'm doing this just for research and to get started with encryption. I know this is not secure at all.
Do you guys know any two-way encryption algorithm that is easy to use both on php and objective-c that I can use to encrypt passwords on the server and decrypt them in iOS?
Don't bother with your own encryption. You just need to use an SSL link, e.g.
https://yourserver.example.com/getpasswords.php
^---
SSL gives you the encryption for free, and as a bonus allows the iOS client to be reasonably sure that it's connecting to YOUR server, and not some malicious fake server.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.