Develop Reference

Should I encrypt a user's password before sending it to the server?

I want to authenticate a user by allowing him to create a username and password. Since I only find old posts about it, I'm creating this one.
Should I encrypt the password before sending to the server? If so, how should I do it? If not, should I use some specific configuration in my POST request to the server?
Is there any reliable third party api that I should use?
I know that Google has an androidx API for this things, but it's still in alpha.

If you use HTTPS protocol to comunicate with the server the data are already encrypted before beeing sent, anyway I suggest you to execute an additional encryption using Cipher.
PS see this question for more How to encrypt String in Java

You may make a basic obfuscation like Base64 or something like that, as Marco mentioned, HTTPS already secures the channel and information wouldn't be seen by a man in the middle.
Instead of encryption you may add a security validation that the HTTPS certificate is trusted, so that using Proxies such as Charles Proxy is also forbidden.

Encryption assumes an encryption key which needs to be securely distributed. Since the password (or a derivate of it) needs to be stored server side for subsequent authentication I would recommend to send the password in clear text at least when registering the username / password. Of course assuming that HTTPS, enforcing a secure protocol and hostname verification, is used. The benefit is that you don't add an implicit dependency to a specific algorithm to the server API. Instead the server application can hide this as an internal detail when storing the password (or a derivate) in the database. This makes API evolution less painful.
It is often recommended to use certificate pinning (i.e. "hard-coding" a server certificate client side) but this may be overengineering depending on your use case as it will require certificate lifecycle management.
All this said. You probably would benefit from using a third party service (e.g. AWS cognito) for authentication, at least in the short term. This way you can more easily implement 2-factor authentication when creating the account, login abuse prevention, password recovery, etc

What are the options I could use to encrypt a HTTP POST request to a web server in Android?

I have an android application that I send some information from the android device to my web server and the information has to be secure through the network till it reaches the server.
I was thinking about using HTTP SSL request, but maybe there are similar options that are free and secure as well.
So what are the options available to encrypt a HTTP POST request through the network?
Thanks in advance.

SSL is definitely the best option and can be free assuming you can install certificates on the devices in question, or prompt the user to do so. That said, it may be a red flag to users if they're prompted to install some strange certificate. You could encrypt the payload using a symmetric encryption scheme (like AES) but then the issue is either key exchange (how do you get the key onto the device) or, if you use a key coded into the app, anybody could access the key from the binary.
Alternatively you could use asymmetric encryption using a server public key that is hard coded into the app, but then you also need to provide for data integrity checks etc.
In summary, just use HTTPS. There's a 99.999999% chance whatever you write will be less secure than accepted, industry standards.

Security issue, HMAC in header vs https, or both?

I'm setting up a server which an android app and an iPhone app will connect to. And I'm wondering what type of security is more secure for sending/requesting data?
Currently I generate a HMAC-SHA256 of the content I'm sending to the server in the header to verify its integrity.
But I'm wondering if its more secure to use a https connection instead? If I use https, could I skip the HMAC?
I would like to know the differences in security, which is more secure?
And also, if I'm using either is it better to use both for an extra layer of security?

Quick answer to your questions: SSL if used properly should give you more security guarantees than HMAC. So, usually SSL can be used in a way that removes the need for HMAC.
HMAC provides integrity as well as authenticity. Assuming the client and the server use pre-shared symmetric keys to calculate the HMACs, one side can be sure that the device on the other end has the secret key. This provides authenticity of both server and client.
What is missing in this picture (with just HMAC) is confidentiality. What is the nature of data exchanged between the server and client? Is there any sensitive user data being transferred during the communication that you don't want a man-in-the-middle to see? If so, then you may want to use SSL.
SSL gives you confidentiality (among other things). Meaning that you can be sure that you have a secured end-to-end connection and no man-in-the-middle can see what data is being exchanged between the server and client. However, common SSL usage does not include client machine authentication. Fro example, your web browser checks for Paypal's authenticity when you go to their https webpage. But the Paypal server does not ask your browser to send any certificate from your side.
Since you are comparing SSL with HMAC, I am assuming you care about authenticity of both sides. So, use SSL with both server and client authentication. This basically means that both of them would ask for each other's certificates and check different aspects of the certificates (i.e. common name, certificate issuer etc.). You can create your own certificate issuer to sign these certificates.
If you are making an app for AppStore or Google Play that users can simply install and start using, you may want to think through how the client side certificates will be generated, signed or who will sign them. You can remove the need for client side certificate (and signing) by adopting a model similar to GitHub's, where the user manually informs the server of trusted public keys to authenticate devices. But you can probably see how this process might not be user friendly.

How can I Secure a JSON file with REST API or other methods?

I've searched everywhere, and found lots of information I cannot comprehend. I'm using a WAMP server and managed to execute a "SELECT name FROM Tablename" query and passed the data to json_encode(). I like the results so far, but now I need to protect the JSON file in the server, making it accessible only to users that run my Android app.
Through my research I found that REST might be a solution for me but I do not understand how I can implement it for my case. Is it possible to have Server-side REST Security, and Client-side as well? I understand that REST is a web service and I read a tutorial where the web service is basically a web page. My priorities are server-side json file, security and speed. The user will not be inserting any information via the Android app. I was thinking of deploying the Android application with the user and password to the specific json file (verification).
It would be helpful if you can point me to a video tutorial, or a tutorial for beginners, related to the subject.
Here are my specific questions?
Can I parse images with JSON?
Is it more efficient to mysqldump --> convert .csv file ---> SQLite? (Securely).
How big can a .CSV file get with say 1 million entries in the database?
How can I accomplish all this?
Please help, thanks.

Solution: Use HTTP Headers
Insecure solution:
use the User-Agent header.
User-Agent: MyAndroidApp/1.0
More secure solution:
First off, you'll need to use SSL so no one can just easily see your secret key.
Second, you can put a secret key in the HTTP header of the request you make from the android app:
X-Android-Secret-Key: fee400be-7d08-45c5-bf7c-ff79c35a838c
You check headers on the server and only serve the file back if the desired header is received. You keep the header somewhat secret but not impenetrable with SSL.

I'm only going to answer your original question on app authentication. Your other questions belong as separate questions.
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.

Securing a web service so it can only be called by a specific Android application

We have a web service that should only be called by a specific Android app. What solutions are there for this problem?
The requirement is to not use authentication at all.

If it's only your client and your server, you can (and should) use 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 guess this will work with proper authentification in place. First post I just stumpled upon was this one:
Securing communication from android to a web service
Hope it helps =)

If you're absolutely certain this web service will only need to be accessed by authorized applications/devices, go with client-side SSL certificates and restrict access at the server to only clients with authorized certs. This has the bonus feature of forcing SSL at all times so you don't like auth secrets over an open channel. Here's a quick guide for Apache, but you could use nginx too:
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500