I am developing an app which uses Facebook login, and which contains a messaging platform. Messages are stored in a Firebase database, and I would like to have some sort of encryption such that the database stores the encrypted messages, and only the sender and receiver can decrypt them.
I know the sender/receiver need some unique key to encrypt/decrypt the messages, but I am unsure as to how I should generate this key, and as to where it should be stored? Basically, there are plenty of tutorials on message encrypting, so I am wondering about the general information structure of an app which involves this kind of encryption, rather than about what exact code to implement!
I thought about basing the encryption key on a user's Facebook access token, but these change every 60 days so I assume it wouldn't work?
Thank you for any help or suggestions!
Related
So I have a restful API that is responsible for handling the licenses for my app, it records
User ID
User email
Username
license expiry date
Currently what happens is the user authenticate via a third party auth service (firebase) then the app takes the user ID from firebase auth response and get the license info without any authorization on the license API.
Essentially if you have a user ID you can get all the info mentioned above
My question: Is this a security flaw? or is this acceptable considering that it is very hard for a malicious user to obtain another user's ID and even if he obtains the ID the info is not really that useful
This is a data protection question, not a programming question and you watch it from the wrong perspective in the comments. Information security and data protection and totally different jobs with different mindset.
User ID - personal data
User email - personal data
Username - personal data
license expiry date - probably company secret
What do we protect here?
Some not that sensitive personal data like username and email, which can be guessed by checking the companies webpage or linkedin. The license expiry date is not that important I guess, maybe the company wants to keep it in secret, who knows, better to ask them. The user ID if it is used only here is not a big deal.
What happens when somebody gets the user ID?
They can watch the upper data 24/7 until you add proper authentication or change the User ID. It does not matter how they get it, let's assume they can. They can watch HTTP packets, or an employee sends it by accident to somebody, or they steal this part from the database or they get it from HTTP server logs when you throw out a faulty HDD, who cares?!
What would be the effect to your company?
If your customers don't care about it, then ok. If they would terminate the contract immediately and report the data protection incident to an authority, you will be sued, etc. then it is an issue...
What else can happen?
Do you have support? Can somebody use the User ID and the upper infos to trick your support into terminating the contract and sending back money to the bank account they give? If so then it is an issue either.
Risk assessment is about checking the probabilities, motivations, consequences, etc. of something like the upper and mitigate them if necessary with risk reducing protective measures. Such a thing can be for example encrypting and signing the User ID and the session expiration date before sending it to your API, if it is possible to send encrpyted signed JWT by FireBase.
If the only way to access the record is a randomly generated UUID, then it is reasonable to consider the UUID to be a "secret key" and knowing it the equivalent of an authentication token. The UIUD space is extremely sparse; they are not guessable any more than AES keys are guessable. So the data is as protected as the UUID. You of course should still use HTTPS to protect the URL in transit. I use these kinds of schemes regularly (where knowing the UUID or knowing the SHA of the data is the authentication).
Are there any packages, frameworks, or services to do client-side encryption of user data in Flutter, using firebase as a server?
I hope to build an app that handles some of a user's personal financial information and so I want no one else, including me, to be able to access it. Firebase allows a Dev to see the unencrypted database so I need to do the encryption on the client-side.
I think this will probably have to involve a client-side symmetric key used for encrypting and decrypting the user data.
My worry is how to store this key.
(1) Randomly generated key stored locally - doesn't allow the user to switch between devices and is lost if the device is lost
(2) Store it in a Google Drive - requires the user to have a Google account. (Advocated by this article from HackerMoon
(3) Generate it deterministically from a salted hash of the user's password (stored locally) - lost if the user forgets or changes their password.
(4) Allow the user to choose between a subset of the above
My question is similar to this one How to encrypt user data in Firebase but it covers situations were data is transferred between users and hence uses public key cryptography.
Questions:
What is the best way to encrypt user-data for a firebase db?
And if it is to use a symmetric key, what is the best way to generate and store this key so the user doesn't risk losing access to their data?
This one appeared to be the best solution for my case: flutter_secure_storage. It stores the data in an app specific container within the official key stores of iOS and Android
I am developing an app which uses several API services, the API requires that I provide username and password for API transactions, unfortunately no API token :-( in-order to automate I need to store username passwords somewhere, preferably database, I cannot use hashing because I need to send the username/password to authenticate and process API request, hence I am wondering how to go about it.
If I use Zend\Crypt to encrypt and store the password in database and decrypt whenever required, would this be enough for security? is there something else I must consider?
Looking for pointers.
PS: I am using ZendFramework2 with Doctrine/MySQL for the app.
Usually you would use a token mechanism (like OAuth). If that's not possible, one would use TLS/SSL client authentication.
However, if you rely on plain passwords (on the application-level, I still guess the username/password tupel is transmitted over a secure connection!) and you want to store them encrypted, you have to think of a meaningful mechanism to get an encryption key for your scenario. Just generating an encryption key and storing it on the same machine in plain does not provide more security.
Without more information on your scenario it is hard to make a suitable suggestion.
The apps that I build frequently have 'social media service' requirements; e.g.
Twitter
bit.ly
Facebook
For most of these services, I need to have an API key of some sort. I'm trying to work out the best way of including these API keys in the application binary. The desired level of security depends on the possible attacks that can be conducted by malicious attackers.
Twitter
I have an xAuth-enabled key and secret. Both need to be used by the iPhone app.
Fallout from attack
Malicious users could post twitter status updates masquerading as coming from my app. There is no twitter account to hijack and start posting status updates on.
bit.ly
I have a username, password and API key.
To login to the website and access analytics, the username and password are required.
To create links via the API, only the username and API key are required by my iPhone apps. The password will not be in the app in any form.
Fallout from attack
Malicious users could create links on my bit.ly account. They would need to do a separate attack to brute-force or otherwise gain the password to login to the account.
For both of those services, the potential for harm doesn't seem too great. But for other services, it could be much worse.
I can just define the API credentials as strings in the header or in-line in the code, but then it's vulnerable to someone using strings on the application to see what's in it.
I could then start doing silly concatenation / xor-ing in the code to recreate the API key in memory, and the attacker would have to do a bit more work to recover any keys in the binary. My concern with that is that I'm not a cryptographer and would create an embarrassingly weak form of obfuscation there.
What better suggestions do people have?
The attacker can just sniff your traffic and extract the secret from there. So any obfuscation is easily circumvented.
Even SSL won't help much, since you can intercept the networking API which receives the unencrypted data.
The secure way to solve this is create your own server, keep the secret stuff server side, and use your own server from your app, and the server then relays to the other webservice. This way the attacker never has access to the secret.
A good suggestion is not to worry about it. There are plenty of apps that store their API keys in plain text. The point is you need a lot of different bits of information to construct an access token.
As long as you're not storing username+password combos in plain text on the file system or transmitting them over the network without SSL/HTTPS etc then you're fine.
I am planning to store a password in my Native app (Android and iPhone). Should I store them after encrypting it ? or can I store it without any encryption? Are they really secure?
Any jailbroken iPhone will give any user access to the application's Documents folder. So, yes, it's insecure.
Additionally, if you put the password inside the code, you're still weak, as someone can decompile the program and find the key. What I'd recommend is a proxy.
For example, we have an application that connects to Facebook's API on the phone. However, we don't want to store our Facebook API private key on the phone, because then any user who reverse engineers our code could hack our Facebook application!
So, instead, we store the Facebook private key on a (secure) proxy server. When the device needs to interact with Facebook, it contacts the proxy, asks the proxy to log-in, and then the proxy gives a session key to the device to use directly with Facebook.
Certainly, it's still hackable - but you won't lose your private key in the process, and instead, the only thing your user could do is do the same things you do in your proxy server API.
Could you give us a little more information about what you're trying to do?
I would store it encrypted.
If someone would read your password he/she could simply use it. If it is stored encrypted, that person would need to decrypt it before usage.
Stored passwords are not safe at all. Determined user can root it's device and access any database and preferences. If you encypt password, your application can be decompiled to get decode function or step-executed until decrypted password is stored somewhere in process memory.
It doesn't mean you shouldn't encrypt passwords - use any symmetric encryption and initialise key in some non-trivial way (i.e. arythmetic expression). This will prevent script-kiddies and casual programmers from reading passwords. Just remember if some really want them, he will get them anyway.