Hi,
I may be about to embark on creating an app that has to decrypt images downloaded from the web.
The provider of images is absolutely insistent on that.
Anybody done this?
Any alternative solution?
I had thought about using zip files with a password, but seems the zip plugin doesn’t support passwords.
Thanks
network.request() and network.download() both support HTTPS.
So whichever web server you’re downloading the images from, make sure they are only available via HTTPS (and not HTTP)… and you’re done.
Thanks for that. Would this mean that the files would have to be un-encrypted on the server though?
This might make the client nervous. There is real value in the images, and they would be afraid of hacking.
Yes, the files would be unencrypted on the server and accessible to everyone. Only the transport of the files would be encrypted, i.e. no one would be able to grab them while they are being routed between the server and the app.
Encrypting the files on the server and storing the password to decrypt them in the app adds no security, because both data and source code of apps can be accessed without significant hacking skills. If additional security is needed, you will need to store the password somewhere safe, such as in the mind of the user. This means you would need to provide the user of the app with username/password and let them enter the password manually.
Thanks for that. I think the client would accept the security risk of the app, because that’s less likely to be compromised than their server.
Still leaves me with the issue of how to decrypt images on the device.
Apps are much easier to hack than servers because anyone can download them from the app store, decompile them, and see the full source code. So if your client accepts that the encryption keys for their valuable assets are hardcoded into a publicly available app, then they have very little understanding of IT security.
In that case, I recommend that you make sure you don’t take responsibility for that decision in your contract with the client, because when their apps get hacked (which can be done by a 10 year old), all the data on their server will be compromised also, and the client may be quick to blame you.
network.request() and network.download() both support HTTPS.
So whichever web server you’re downloading the images from, make sure they are only available via HTTPS (and not HTTP)… and you’re done.
Thanks for that. Would this mean that the files would have to be un-encrypted on the server though?
This might make the client nervous. There is real value in the images, and they would be afraid of hacking.
Yes, the files would be unencrypted on the server and accessible to everyone. Only the transport of the files would be encrypted, i.e. no one would be able to grab them while they are being routed between the server and the app.
Encrypting the files on the server and storing the password to decrypt them in the app adds no security, because both data and source code of apps can be accessed without significant hacking skills. If additional security is needed, you will need to store the password somewhere safe, such as in the mind of the user. This means you would need to provide the user of the app with username/password and let them enter the password manually.
Thanks for that. I think the client would accept the security risk of the app, because that’s less likely to be compromised than their server.
Still leaves me with the issue of how to decrypt images on the device.
Apps are much easier to hack than servers because anyone can download them from the app store, decompile them, and see the full source code. So if your client accepts that the encryption keys for their valuable assets are hardcoded into a publicly available app, then they have very little understanding of IT security.
In that case, I recommend that you make sure you don’t take responsibility for that decision in your contract with the client, because when their apps get hacked (which can be done by a 10 year old), all the data on their server will be compromised also, and the client may be quick to blame you.