I'm developing an android app using Firemonkey. This app makes requests to a WebApi using Rest and returning json result. The API is already developed and each request needs to send user and password as querystring to return data. My question is: what is the best way to save sensitive data in firemonkey (android). Of course using encryption to store such data is the first thing that comes to mind, but is there any native and secure feature for this on firemonkey?
-
This makes little sense for me, plain text in querystring is much more likely to be compromised than Android's internal storage. – Free Consulting Mar 06 '17 at 01:48
2 Answers
Don't save it. If it really needs to be secure, request it from the server as needed. There is no such thing as secure encryption if the key and the data are saved on the same machine.

- 90,003
- 9
- 87
- 127
-
2I think the question is asking how to store the *user's* password, which cannot be requested from the server. And although "don't save it" is still a valid answer in that case, it doesn't seem like a very *useful* answer. Plenty of apps offer to remember login information to save users from having to authenticate every time they start, and I think this question is simply asking how to do that. – Rob Kennedy Mar 05 '17 at 23:12
-
1@RobKennedy You use a generated access token. That's been a solved problem for over a decade- you NEVER store a password on the client, encrypted or not. – Gabe Sechan Mar 05 '17 at 23:13
-
1
-
@Gabe Sechan A token generated for example by oauth2 expires after a certain period, correct? Do you know of any method of persisting a token indefinitely? Still, sorry for my ignorance, if a user gets access to the stored token, he would not be able to access the system either? – Marcoscdoni Mar 06 '17 at 01:43
-
Just don't expire them on the backend. But the right answer is to refresh them when close to expiration by sending a new one the app replaces the old one with. – Gabe Sechan Mar 06 '17 at 01:45
-
Also am expired token, implemented correctly, should just log them out. – Gabe Sechan Mar 06 '17 at 01:46
-
As for a user getting access to the south token- who cares? He already had a password. What you don't want is attackers gaining access to it. But what a token has over a saved password is that the user isn't locked out easily by changing the password, and that if he uses the same password elsewhere an attacker had only compromised one account not multiple – Gabe Sechan Mar 06 '17 at 01:49
Do not encrypt passwords, when the attacker gets the DB he will also get the encryption key.
Just using a hash function is not sufficient and just adding a salt does little to improve the security.
Instead iIterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use functions such as PBKDF2
, password_hash
, Bcrypt
and similar functions. The point is to make the attacker spend a lot of time finding passwords by brute force.
Do not send the user's password in the query string, with an HTTP connection it is in the clear, with an HTTPS connection it will be encrypted but probably end up in the server log files

- 111,848
- 21
- 189
- 228
-
@Zafe What is your opinion about saving an access token on the device? – Marcoscdoni Mar 06 '17 at 01:55
-
Yeah, but as per question OP have no control over webservice, which wants credentials in such insecure way. – Free Consulting Mar 06 '17 at 01:55
-
1@FreeConsulting Then the OP has a delima, either put the users at risk or push-back and refuse to contribute. IMO we need to stop producing insecure products. Do you suggest to contribute to creating insecure sites that put users at risk? – zaph Mar 06 '17 at 03:42
-
1@Zafe Generally it is fine to save a authorization token on the device in the secure storage, the iOS Keychain and the Android Keystore. Understand that the user has access and if the device is compromised attackers. If using HTTPS (which should be used) the certificate should be pinned to avoid MITM attacks. – zaph Mar 06 '17 at 03:47