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.
Related
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.
I am relatively new to programming and I'm working on a little application. The app is running on an android device and needs user based information from my PHP web server.
My plan is to use JSON for the communication between the phone and the server so the Phone should send the user data and password via get or post to the web server and receive JSON data back.
The question is now, how can I make this connection save? It is a hobby project so I don't want to invest to much in SSL certificates.
Is there some RSA Libary or some good hash function that I can use for this communication?
How safe is the PHP-based hash function: password_hash() and is there something that it can communicate with in Java?
The data is probably not so critical and the application is just for training for me. However, because it is user related data it should not be to easily to break.
You might be interested in a zero-knowledge scheme.
There's a javascript/php example at https://github.com/RuslanZavacky/srp-6a-demo
I'm putting together an android client (and possibly in the future iOS, web portal, etc) and php mysql server. Server side I am currently using the PHPass library to hash and salt the incoming passwords.
Should I make the client send plain text passwords over HTTPS/SSL or should the client do some form of hashing first. For example should every client simply sha1 (or some other algorithm) every outgoing password?
Most websites will send the password plain-text over an encrypted connection SSL/HTTPS. Hashing the password client-side can be done, but the advantage is small and often client-side languages (JavaScrypt) are slow so you can calculate less rounds in the same time, what weakens the hash. In every case the server must calculate a hash as well to be safe.
The advantage is small, because if an attacker can do a ManInTheMiddle attack, he can also modify/remove the script (JS) which does the hashing. Only an encrypted connection with SSL/HTTPS can protect against a MITM attack, so you need SSL anyway.
In your case with an app, it looks slightly different. Because the user first has to install your software, there is no need to send a script to the client, so a MITM cannot modify this script. Moreover, the app can calculate the hash relatively fast (if it can run native code) and therefore can do enough rounds on client-side.
This is what i would do:
For easiness send the password plain-text over an encrypted SSL/HTTPS connection and calculate the slow BCrypt hash server side, as you do now.
Only if the load on the server grows too heavy, then you can move the calculation of the slow BCrypt hash to the client app. Still use HTTPS to send the hash, and then calculate an additional fast hash (e.g. SHA-256) on the server. This is more complex, because you have to exchange and store the salt separately.
Another disadvantage of hashing passwords on the client is that you cannot change the hashing algorithm or iteration count without also having to update your clients.
For JavaScript clients that is not a problem, but you cannot easily guarantee that your users will be on the most recent version of your native client.
So I would stick with sending plain passwords over HTTPS.
In the early days of HTTP, there was Digest authorization as an alternative to Basic authorization. Instead of the HTTP header
Authorization: Basic <credentials>
you would use
Authorization: Digest <credentials>
It was an algorithm that increased security by avoiding the password being sent as cleartext. This was in the days when TLS/SSL came at a performance cost so this was an alternative. However the algorithm meant the password had to be stored as cleartext on the server. So you had a choice of sending the password cleartext but having a hash on the server, or sending the password as a hash but having cleartext on the server.
Unsurprisingly, as martinstoeckli said in his answer, now that TLS/SSL is widespread and easy to implement, HTTPS is used instead. You can store the password as a hash on the server but not expose the plaintext password if it is intercepted by a MITM attacker.
I want to send very sensitive data to a webserver by calling a specific php file with data over GET or POST (not sure yet). The data contains 3 values, so I thought of building an own algorithm, but this could be reverseengineered easily and I guess there are far better solutions than those I have.
The difficulty is basically this: When a user buys a inapp purchase for a Windows App he gets access to this server. MS does not offer any OAUTH check like Google does so developers have to implement their own check. Also we don't have any user accounts.
Do you have any ideas on how to restrict users that haven't bought the purchase from accessing this server php file (which is secure)?
There are lots of 'handshaking' methods you could use. One method that has worked for me:
Open the channel to your server
Server sends a string of random characters to the client
Client hashes the string with a known salt and sends this string back to the server
Server compares the returned string with it's own encrypted version of the original string
If they match then the client session is allowed
This prevents someone from doing a replay attack on your server.
If you want to stick with a typical 'web transaction' then use HTTPS (port 443) to handle your encryption. Another alternative would be to use an encrypted socket to a different port.
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.