currently developing a new feature on my Web App i'm having a question:
I encrypted some data because i dont want it public in the blockchain but i have some concern about this, ideally the encrypt/decrypt password should be the privatekey of the keeper connected user but since we don't have access to this info in Waves Keeper, what would be the best practice ?
How can we encrypt/decrypt data in a decentralized manner with Waves Keeper?
im currently using a password predefined by me as an environment variable on the server side but this is far from ideal and definitelly centralized aside of having several downside.
Of course there is few backup options like:
1) Simply avoid put any non public data in the blockchain
2) Add an encrypt/decrypt field in the App requiring user to enter his password everytime
Both would work but are just getting around the problem and not ideal, would like to know if there is any good solution first :)
There are two methods in Waves Keeper API to encrypt/decrypt data. You can find details on the github.
https://github.com/wavesplatform/waveskeeper
Related
I have created a suite of two different Flutter apps that share a single firestore database.
The first app generates a QR code that would then be scanned and verified by a user of the second app. The QR code information is a string that contains some information I don't want users to see by simply scanning the QR code with their camera app.
I want to encrypt the string in the first app before encoding it into a QR code, and decrypt the string in the second app after the QR code has been scanned, but that means I would need to have the encryption key accessible in both apps.
Would I have to hardcode this key into the apps or transmit the key through the database? How can I achieve this in the most secure way possible?
You can use almost any mechanism you want to transmit the keys, but the one thing you shouldn't do is transmit it through the same database as where you store the encrypted data - as that would put that data at risk if the database is compromised.
So mail them, text them, write them on a piece of paper and mail it, or you can organize an in-person meeting/party where you exchange them (h/t to Little Brother). It doesn't really matter how, as long as it's a different mechanism than you used to store/exchange the actual data that is encrypted with those keys.
You can hard-code them in the apps too, but what the keeps anyone from downloading that app too and using it? Or is that precisely what you want, in which case 👍
I am going to use cloud firestore within my flutter app to store data from a questionnaire. Although the questionnaire itself DOES NOT ask for personal information, such as name, phone, email or passwords etc, it DOES ask several questions and produce data that I would not want an admin of cloud firestore to see. During a meeting it was identified that risk to data security was that an admins account could be compromised and people would be able to view/export plain text data. I have looked at end to end encryption for this, however, a designated person from within my company will need to process the data and thus will need to de-encrypt the data later on.
How should I encrypt the data on cloud firestore so that
Admins do not see plain text
A designated person can de-encrypt the data when needed to produce a report
Just from googling my thoughts are that I should perhaps make a public key available on the device side for encryption onto the database. I should keep a private key safe so only the person processing the data will be able to de-encrypt later on.
Is there a workflow that people use for this?
Sorry if this is a basic question!
What you're describing is pretty much how to do this: encrypt the data client-side before sending it to Firestore, then again decrypt it in your dashboards and anywhere else you need to display it. That's the only way to ensure that collaborators on the project won't be able to see the data.
Alternatively, you can consider not giving anyone access to the Firestore panel in the Firebase console for the project that you use for production data. So in that case developers can see everything unencrypted in the development project, but nothing in the production project.
I'm developing an app that's pretty simple, and the important part of it is the content, which consists of lots of info that has been gathered over many years. I want to format it in a nice way to show to the user.
When the user downloads the app and first loads it, it goes to the server to get the whole database into the phone. Then, he can see the important items, and sort/filter through them. To avoid somebody taking my database, I'll use a SSL connection. I know if they want they could use the app to see every piece of content one by one, but there's nothing to do about that.
The thing is: I have the data in the cloud (mine). I can securely download it using an SSL connection (any other ideas to secure the transfer?). When I get it here, I'll save it in a db (Core Data is the obvious choice).
How can I secure the data in the internal database, so if the app is hacked, someone cannot access the db? I would put it in the keychain but it's a rather large db for that and it's not that important. (It's not sensible info, just info I don't want anybody to get massively.)
The other thing I could do is to never store anything in the device and have the user always making calls to the cloud, but I think this would be too time consuming. And just give him the option to save their favorite picks to the device. But that's too time consuming and there is the sync issue.
This is a reference I looked up about a similar issue, without the part I'm asking answered:
How to encrypt iPhone upload and download of info?
Basically, the only choice is to use SqlCipher. Of course, you have to port it to iPhone yourself (unless someone else has posted a port since last I looked). But it's not an insurmountable task.
Of course, even with SqlCipher you have the challenge of storing the key somehow. There's no really secure way to do this -- you have to use some form of "security by obscurity".
Why not just have some private key info stored in the code, and then when you want to download the database just have it query the server with the key? That way you wan't need to worry about SSL or encryption in the downloading part. In regards to storing it I agree with Hot Licks, SqlCipher appears to be the best and only option. However watch out for encryption, as you will have to declare it to apple and get all kinds of export permits (http://stackoverflow.com/questions/2135081/does-my-application-contain-encryption).
Hope this helps,
Jonathan
I'm trying to send data from my application to a webserver.
The catch is that I want to encrypt the sent data and also make sure it comes from my application. (From what I've read so far it's easy to decrypt the data if it's not sent via HTTPS. On the unique application I didn't find anything except the Application ID Apple provides for each application but I don't know how that works).
The data sent are various highscores and achievements that the user can enable. The thing is that the user doesn't have to type in anything but his username and having that associated with the UDID it should be enough.
But how to make sure it's from my application?
Edit:After reading some responses around here I still didn't understand something:
If someone extracts the IPA and reverse engineers it wouldn't he have access to all my .h and .m so he can look up anything in there?
You could generate a client certificate for the iPhone app, and use mutual authentication for your SSL handshake. Then you know that data submitted to the server come from a particular user of the app, and that your app is communicating with the correct server.
Regarding your edited update, yes if someone reverse-engineeres your app they can probably work out how the high-scores are protected. But seriously, how much trouble do you expect most people to go to in order to fake a high score in a game? Are you offering a cash prize or something?
If you are using HTTPS then you can just put an identifier key in your POST to the web server, either as a field or perhaps an HTTP header that identifies your app. The entire connection is encrypted so it will be protected. If you do this you will want to encrypt the key even in your binary and decrypt it as you send it over the connection, that way no one will be able to pull it out with a hex editor.
Another approach if all you want is to know that the data comes from an authentic instance of your application is to use message authentication codes (MAC). I leave deciding how strongly the key needs protecting as an exercise to the reader - you know your security requirements better than I do.
You can use CommonCrypto - part of the iOS SDK since forever - to actually generate the MAC.
I'm storing some healthcare data on a mobile phone and I'd like to know what the best system of encryption is, to keep the data secure. It's basically a bunch of model objects, that I'm serializing and storing using NSKeyedArchiver / the equivalent on Blackberry (the name eludes me for now)
Any tips? I don't want to make up security protocols as I go along, but one of the other threads suggested the following approach.
Generate a public / private key pair
Store the public key
Encrypt the private key with a hash of the user's password.
Use the public key to encrypt the byte stream.
Decrypt the pvt key, keep it in memory, whenever the user logs in, and decrypt the stored data as needed.
Is there a more standard way of doing this?
Thanks,
Teja.
Edit: I appreciate it that you're trying to help me, but the things currently being discussed are business level discussions, on which I have no control of. So rephrasing my question, if you ignore that it's healthcare data, but some confidential data, say a password, how would you go about doing it?
There might be an easier way for secure data storage. With iOS 4.0 apple introduced system provided encryption of application documents. This means that the OS is responsible for doing all the encryption and decyryption in a fairly transparent way.
Applications that work with sensitive user data can now take advantage of the built-in encryption available on some devices to protect that data. When your application designates a particular file as protected, the system stores that file on-disk in an encrypted format. While the device is locked, the contents of the file are inaccessible to both your application and to any potential intruders. However, when the device is unlocked by the user, a decryption key is created to allow your application to access the file.
So only when your app is active, the files can be read back in unencrypted format. But the nice thing is that they are always encrypted on disk. So even if someone jailbreaks the device, or backs it up, the retrieved files are worthless.
This was probably introduced to conform to some specific data security standard that is required. I can't find that anywhere though.
For more info see the iOS 4.0 release notes.
http://en.wikipedia.org/wiki/HIPAA
Make sure you read and understand this!
edit: Sorry, didn't even bother to check to see where the OP is from, but even if they aren't from the USA there are still some good practices to follow in HIPAA.
HIPPA is a business practice and total system level privacy/security regulation. As such, an app can't comply by itself on random hardware for a random user. You need to determine how your app fits into a client health care provider's total regulatory compliance process before you can determine what algorithm might be found to comply with that process.
My best advice would be, don't store sensitive data in the user's mobile phone.
If that is not an option for you, then some kind of public/private key encryption, such as one you described, would be the next best option.