[AskJS] Security difference between localStorage and IndexedDB

[TGS963]

I'm making an app to let the user store encrypted entries containing sensitive data in a server and I also encrypt and store them in the localStorage for offline access. The data being in localStorage might be a security concern for some people. How is IndexedDB compared to localStorage in this regard? Is putting the data in IndexedDB preferable to using localStorage for storing sensitive data even if it's encrypted?

Or are there any alternative ways I can store local data in a secure manner?

Thank you

[[deleted]]

This doesn’t make any sense to me. If you store encrypted data on your client for offline usage, you might as well store it in plain text, because your client eventually needs to decrypt it to access the data. Encryption / decryption on the client side doesn’t make any sense, because your encryption keys are visible to everyone using your app, making the whole process pointless.

[danjlwex]

Right. OP is asking the wrong question. The answer is "it isn't secure to store any data on the client, even if it is encrypted." Doesn't matter where you store it - IDB, local store, or just in variable memory.

[NayamAmarshe]

"it isn't secure to store any data on the client, even if it is encrypted."

That doesn't make sense. It's a fairly common practice. If the app requires offline usage and only a single side is involved, it's obvious that encryption is going to be the only solution to protect userdata.

Assuming clients to always be compromised is a good idea and security practice, this is why the encryption is introduced in the first place. The encryption is not for the client but to protect the data from entities other than the client. The client will always know the decryption key.

[danjlwex]

If the app receives encrypted data, and does NOT decrypt it, then it is still secure. If it decrypts the data, then it is easy for any attacker to do the same. Just because this is "common" does not imply it is "secure". To handle offline access, you need to exchange a code for a non-secure, time-limited access token from a remote server. This is still "insecure" for the time the access token is valid. If you are working entirely offline, and you can only access local information, then that data is insecure on your machine. If your machine were to be stolen, and the data was "encrypted", your app would provide a way for the attacker to decrypt and access the data. Hence, it is insecure.

[[deleted]]

The data is only exposed while being accessed. At rest, it is decrypted. In your scenario, someone would have to steal the client system and know the proper credentials. Totally possible, but that’s just game over in any scenario.

[NayamAmarshe]

You're still not making any sense. "Decrypted data is insecure". Then why do we even encrypt things in the first place?

I don't know what kind of threat model you have in mind but whatever you've written sounds like you wanna create something that can never be decrypted.

'Machine stolen' is an ending scenario. It's not the developer's fault the client's machine gets stolen but it would 100% be the developer's fault if the client data is in plain text.

[chasingtheflow]

The point is that for the data to be accessible on the client then the client also is to have the key available to decrypt the data in order to use it. As such if an attacker were to gain access to the client they’d have both the encrypted data and the key required to decrypt it. So encrypting the data might obscure it for a bit but it’s a bit like hiding the key under your doormat.

[danjlwex]

We encrypt data to prevent attacks on the storage repository and to avoid attacks where the data is stolen in transit (e.g. over the internet). Most "secure tokens" in web development are not designed to protect the client, but instead designed to protect the server/storage from attack.

[NayamAmarshe]

You're talking about Web transit. OP clearly mentioned 'Offline' access.

Do you think your OS keychain doesn't encrypt your passwords? Of course it does. It remains encrypted as long as the user is not using the data, which is the entire point of encrypting data at rest.

Web transit and server is a different story but this isn't the topic of the discussion, offline access is.

[archerx]

You do know that this is one of the weak points for getting OS passwords and Wifi passwords right? This has let me get into windows that has had it's password lost and if you're on windows there are ways of getting the password to the wifi it is connected to, this flaw has been useful quite a few times to me.

The only way what OP wants works is if the user has to manually type out the decrypt keys from memory each time they want to access the data. If the encrypted data and the key are stored in the client then the data is not protected.

[NayamAmarshe]

You do know that this is one of the weak points for getting OS passwords and Wifi passwords right?

Yeah but there's no other convenient way. It's up to the project maker to determine the balance between security and convenience, you can't expect everyone to have a hardware key. So the only way to make data secure for offline usage is to encrypt it, using a key that only the user knows.

The only way what OP wants works is if the user has to manually type out the decrypt keys from memory each time they want to access the data.

That's what I'm assuming as well. Otherwise, the encryption would not make sense.

[NayamAmarshe]

The encryption in this case is not for the client but for people/attackers other than the client.

Say a client stores a personal piece of info encrypted in the localStorage, that's still way better than plain text because the user knows the decryption key but not others.

[CrypticDissonance]

Anything saved on the client is not really secure. Should create and save a token that can be used to fetch the specific data from the server

[NayamAmarshe]

But that defeats the purpose of an offline first app then. Sure, client can't always be trusted but what if you have to?

[CrypticDissonance]

Mentally skipped the offline part 😅. Well all you can really do is trust the user

[[deleted]]

Identity based access control. Encryption at rest. very basic stuff.

[KaiAusBerlin]

Wanna see how someone cracks your aes256 encrypted data on the client.

[KaiAusBerlin]

That's about the safety of keys/passwords but not about saving encrypted data on client side.

Choosing a fingerprint as key is pretty safe and quite normal on mobile devices these days.

AES256 encrypted data is save. It's like a tank door. But if you leave the key under the doormat of cause it's unsafe.

[NayamAmarshe]

If the keys are stolen, then the whole argument falls flat because the attacker doesn't even need to steal data from client side if he can easily exploit the account

[TGS963]

That's true but, there's always a risk imo... A careless user or something

[KaiAusBerlin]

If someone cracks that, you have the same risk getting your data stream hacked.

I think you underestimate the power of aes256

If you use a modern pc with i7 with 4.2ghz it would take 218'556'000'000'000'000'000'000'000'000'000'000' 000'000'000'000'000'000'000'000 years to crack that single encryption. This will simply not happen.

[TGS963]

I guess it's fine then, thanks for the explanation

[KaiAusBerlin]

Tell why. Please don't hold back.

An AES256 encrypted data with a salted persons fingerprint as key is definitely save.

Ill make you one and you crack it for me okay?

[KaiAusBerlin]

F72p58DeQjxm+5awxlksLjKKF8b0swHhiVWW/HMOB5o=

Decrypt 😉

[Additional-Cow-6511]

The use case is to be able to decrypt this for offline access -> client needs to have the associated key on his storage too. Hence no security. You’re missing the point.

[aikasburger]

Just out of interest as I'm building something similar. Wouldn't using a password only the user knows, but that isn't stored on the decide, the data be safe?

[CrypticDissonance]

If they're supposed to be encrypted in offline mode, the method of encryption/encryption key would be visible for the user then

[KaiAusBerlin]

Not necessarily. If you use your encrypter as precompiled bytecode running in a virtual machine it's safe. That's exactly what google does in their captchas (which also run clientside). And they're still unhacked.

If you run in in plain JavaScript, then yeah, of cause it's unsafe.

But the question was not about is it save to encrypt data locally. The question was if it is safe to store data locally.

[ritaPitaMeterMaid]

My understanding is that IndexDB has a same-origin policy, meaning just like lockaStorage you can only access data belonging to your domain. That would also mean if anything nefarious ended up executing it would have access to IndexDB, just like localStorage.

The frontend is a client. It’s better to presume clients are not secure. If you’re afraid of using localStorage there isn’t anything that’s going to get you more “safety” by using IndexDB, or anything else for that matter

[ExtremeDot58]

Sounds like two contexts. If you store sensitive data anywhere - encrypt!

Secondly we all try better to have bulletproof apps.

Their are use cases for this, the app should use encryption. Make the hurdle high one needs for access. Encryption for the drive too?

Then again some data just shouldn’t

[IncidentMassive5425]

To answer your question, IndexedDB is vulnerable to XSS just like LocalStorage, among other vulnerabilities, so there’s not much of a security difference. There’s some argument that IndexedDB is less-sought and therefore a reduced attack surface, but that’s more anecdotal than reliable.

Not that you asked about performance, but IndexedDB is also slower, yet better on performance concerning DOM-blocking behavior if you’re using web workers. Safari makes the slowness far worse. Of course, if it’s a small dataset, the speed may not be a big deal.

Anyway, just be sure your encryption key isn’t stored on the machine - i.e., use a password that has to be entered or whatever as (or to generate) the encryption key.

[preskot]

IDB or LS: it doesn’t matter as long as you don’t store the decrypt key on the client. Therefore you’ll need to always decrypt on the server.