I am trying to figure out how to handle the credentials for reconnection process for a chatserver from a mobile device, i know the credentials probably has to be stored in the device.
I am wondering if the password is encrypted before they are stored? But as whatsapp and these chat do not require a password on open,so i am assuming they don't or they use a unique value per device to store them?
Both iOS and Android offer file encryption features for developer to encrypt / protect sensitive data. It is typically used to store local password.
You should make sure on Android that your are using the proper file storage mode: http://developer.android.com/training/articles/security-tips.html
and you should look for Keychain on iOS: https://developer.apple.com/library/ios/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html
Related
We use AES encryption with static key and static vector.
Encryption and decryption of data made on Windows, MacOS and Android.
We know it is not secure to store the key in the app and we do not care about security, we just need to be able to support legacy data format, we need encryption not for security, but for back compatibility. We know we do not provide any data security and our customers know it too. Is where any way to force Play Store to ignore the error and publish our app without moving encryption and decryption functions to NDK?
I have actually one SPA in ReactJs + one mobile application in Flutter + one REST API developed with SailsJs running on a separate server. I managed user authentication with the secured session cookie generated by Firebase Authentication sent back by the API when we are login with valid information (id/password).
Now, I want to encrypt highly sensitive data (medicines, treatments, patients) in the Firestore database so no one can see the data in clear when an intrusion happens or with the basic admin access to the console for the production database.
Do I need to encrypt the data at the client-level considering the fact that the connection between the clients and the API server is over HTTPS? Or can I just encrypt the received body at the api-level before storing it in Firestore and decrypt the encrypted data at the GET endpoints?
My idea is to generate an encryption key with AES at the user registration and store it in another database from an European/French hosting company in order to avoid any risk with the US Cloud Act or whatever (user id from Firebase Authentication <-> encryption key). Is it a good idea? What other solution can I choose to securely store and use the encryption keys of my users?
Thanks for your help.
Do I need to encrypt the data at the client-level considering the fact that the connection between the clients and the API server is over HTTPS? Or can I just encrypt the received body at the api-level before storing it in Firestore and decrypt the encrypted data at the GET endpoints?
If you encrypt/decrypt the data in your custom API, that API will need to have access to the encryption keys. While the chances are small, it does mean the keys could be taken from here, and then be used to compromise the data.
If you encrypt/decrypt the data in the client-side code, only that code will need access to those keys. If you then exchange the keys through some out-of-band mechanism, something that doesn't get stored on your servers along the way, there is no way for anyone with access to those servers to decrypt the data.
I've seen similar questions regarding the Export Compliance Information encryption question when uploading an app with App Store Connect, but I'm still looking for a straight answer for my question. I am uploading an iOS app and have to answer the following question:
Export Compliance Information
Does your app use encryption? Select Yes even if your app only uses the standard encryption within Apple’s operating system.
My app has a login page that uses email and password credentials to allow users to log in if they are a user in my Firebase Authentication section of my Firebase project. I found that Firebase Authentication uses hashing for user passwords, but my question is does the inherent encryption that is part of Firebase mean I should answer yes? Or should I say no, given that I don't implement any encryption of my own. My project also uses Cloud Firestore to store client data inputted through the app.
Update: I realize encryption and password hashing are two completely separate forms of security, but my question still stands regarding info stored with Cloud Firestore.
The Firebase SDK, which is running in your app, connects to the Firebase servers over HTTPS so your app does use encryption. The encryption used is exempt so you don't need to upload any documentation to App Store Connect, but you do need to submit a year-end self-classification report.
As far as I know, Firebase sends data over an HTTPS connection, so that the data is already being encrypted. Although Firebase provides security rules to protect my data structure, I can still be able to see the string messages in the database.
I'm just curious whether it is a good idea to encrypt messages before pushing the data to Firebase or not.
Should I just move on from this topic to something else?
Thank you.
You seem to have a good grasp of how Firebase Database works: the data is encrypted in transit, and it is stored on encrypted disks on the servers. If you enable local persistence on the device, the on device data is not encrypted.
But administrators of the app can see the data in the Firebase console. If it is a requirement of your app that administrators can't read this data, then you'll need to encrypt it on the client before sending it to Firebase. A while ago a developer explained their end-to-end encrypted chat on the firebase-talk mailing list.
Hey Jeff: you're right that when you write some data into Firebase/Firestore, the data:
Is protected over the wire using HTTPS.
Then, when it lands on the Firebase REST frontend server, HTTPS terminates and the server has access to the full payload
Then the REST server routes the data to the backend/database, which also has access to the data.
When the data is written into disk, it's encrypted at-rest, but the at-rest encryption keys are also available to Google and your administrators will also see the Firestore contents
Encrypting data client side (End-to-End Encryption) prohibits all these participants/roles seeing your data.
Encrypting data on client side is fairly simple (compatibility across mobile platforms and browsers is tricky). The other tricky part is the key management to enable one user access to the decryption key without the other user sending the key over in an unsecure channel.
The way you can implement this is:
Create private & public keys for your users when you sign them up
Encrypt data on user1's device with user2's public key
Write the encrypted data into Firestore
When user2 reads up the encrypted data, her private key will be able to decrypt it.
Check out this Firebase E2EE chat sample on GitHub for iOS: https://github.com/VirgilSecurity/demo-firebase-ios and Android: https://github.com/VirgilSecurity/demo-firebase-android
HTH,
David
I am developing a app that uses XMPP. The XMPP server (openfire) is configured to archive all messages so they can be fetched later.
We are facing a problem to decide how to implement end-to-end encryption.
We are willing to use PKI, but the client can access the chat from a mobile app and/or from a browser.
Using PKI only a specific client cand decrypt the message because the private key was generated by this specific client.
Example: If the user access the app from an Android device (where the keys were generated) how will the browser version decrypt the archived messages? (the same user is accessing the two versions)
Can anyone help me with that? Even a different approach is welcome.
I would recommend a scheme based on OpenPGP (RFC 4880). For XMPP this could mean using:
XEP-0373: OpenPGP for XMPP
XEP-0374: OpenPGP for XMPP Instant Messaging.
XEP-0373 allows you to securely synchronize the secret key(s) accross devices. You can either re-use the same key across all devices of the same user, or create a key per device.
Disclaimer: I'm one of the authors of XEP-0373 and XEP-0374.