My iOS/Android app needs to display a QR. However, this QR is stored encrypted in the DB. Who should decrypt it? The front-end/apps (considering the secret is stored as a secure value) or the back-end? Which option is more secure (and why)?
Related
I have encrypted data in AES-GCM with the crypto API. The initialisation vector is then added to the data, forming a unique encrypted string stored in local-storage. Finally, the secret key is stored in IndexedDB.
Since the secret key is non-extractable I though it was secure enough for most use-cases. To my understanding, an attacker would have to rob both the local storage and the indexed db, find the initialisation vector inside the data, convert it to a buffer array and then directly perform the decryption in the browser before sending the data back to his server. Indeed, it seems the non-extractable nature of the secret key means that he would not be able to send the raw secret key to his server and thus not being able to complete the decryption.
But I've been told I was very wrong, and that my strategy was actually barely more secure than letting all the data directly readable in local storage.
So, how could I improve this workflow? Is it really that insecure? Would it be possible to encrypt and decrypt the secret key thanks a unique password provided by the user? The password would be in a .env file and thus never exposed to an attacker. How would you do it?
Here is how the secret key is generated so far:
crypto.subtle.generateKey(
{ name: "AES-GCM", length: 256 },
false,
["encrypt", "decrypt"]
);
Thanks for your help!
I have the following use case:
My web application is used for creating prescriptions. When I send the prescription creation request to the government API it is signed with the current user's certificate. The certificate is stored on the application server and is encrypted with a password which only the user knows.
Users want to be able to store their password in my app temporarily so that they don't need to paste it in for each prescription they create.
What would be the most secure way to store this password? Couple of ideas:
Local storage in the browser.
Bad because anyone with an access to the user's device can see the
password even if they're not logged in. Also if the app is not running I have no way to clear the password if the desired storage time expires.
Frontend app memory.
Bad because if user refreshes the page or opens another tab the stored password is gone.
Backend, in database
This sounds like the best option because I can encrypt the password. Is it even worth encrypting though? I would have to encrypt it with some key stored on the same machine so if someone gains access to this machine the encryption doesn't matter because they would be able to decrypt it quite easily.
Separate the password encryption key and the encrypted password:
Generate and store a random key (and nonce / salt)
Encrypt the password (e.g. AES-256-GCM) with the random key
Store the encrypted password on your backend
Send the random key with the request to temporarily decrypt the password
Delete the encrypted password on the backend when the session expires
That way:
The random key stored in the browser can only be used within the current user session and is useless on its own
The encrypted password on your backed can only be used with the random key stored in the browser and is useless on its own
I want to do client side encryption in mobile app and the encrypted data will be saved in server. The data should be decrypt when user logged in another device also.
Is there any other way to store the "key" securely, which is used for encrypt and decrypt my data other than my server? Usually we store encryption "key" in server, but i need more secure place than my server?
Can we use solutions like AWS KMS for this?
You could just never store the (presumably symmetric) key on the device, but instead deterministically regenerate the key each session using a Password-Based Key Derivation Function
I'm building a single page app with express.js as backend. Currently I'm using passport.js local strategy for authentication, saving on db the encrypted password with bcrypt. During authentication, the password provided by the user is encrypted again and confronted with the one stored on db. However I'm currently sending the password to the server as clear text, and I'm understanding this is a really bad and unsecure practice. To do this correctly I'm understanding I have to:
create random bytes on the server and send them to the client
create random bytes on the client
concatenate the encrypted password and the the two set of bytes and encrypt all of them
send back to the server the encrypted object and the bytes generated on the client as clear text
reproduce the same encrypted object on the server and check for a valid authentication
I could do this again with bcrypt and some random generator on the client, but I have the strong feeling I should NOT implement this on my own. There's some integration with passport or some node library I'm not aware of?
You can use HTTPS (SSL) to encrypt the communication between server-client
Is a cookie secure if it is only stored locally on the client's browser and never sent over the internet to a server?
Edit - Im making an encrypted file service, the way it works is that the user has two passwords, one for logging into his account and another for encrypting and decrypting their files. Upon logging in they are presented with a window that asks them for their decryption password. This password is stored in a cookie on the user's browser. A encrypted list of files is sent from the server and javascript uses the cookie to decrypt it(and encrypt uploaded files once in the browser and then php encrypts it on the server). Is this a secure way of doing things or is their a better way? P.S. I do use an SSL but I'm trying to add more security.
Yes, but how secure it is, it still depends on what information you stored in that cookie. For authentication, it's best to use session and server-side validation.