Is it safe to store wallet credentials in chrome storage? about nami HOT 10 CLOSED

Curious if you have an alternative idea, or if this is just an open-ended question? It's a great one for what it's worth.

from nami.

I think yes, I have a solution to this.
How about we store the info in a Decentralised graph DB, running and integrated with the Cardano chain, which will differ Nami quite a lot from what Metamask does. See here : https://www.logosphere.io/

Just for a quick insight, this is a Catalyst Fund5 winning proposal.

from nami.

As per the code,

https://github.com/Berry-Pool/nami-wallet/blob/9cb160bbb740434ff6c4968140c5852546a2bdac/src/api/extension/index.js#L37

for every new wallet created, the accessors are stored in the chrome storage. As high-lighted by the Google Chrome dev portal : https://developer.chrome.com/docs/extensions/reference/storage/, its unsafe to store any confidential information in chrome storage. Additionally, the information stored isn't encrypted by default. Besides, browser wallets are the easiest ways to be hacked into, plus storing the wallet information in browser may lead to security flaws.

Sensible information like the private key are encrypted by libraries we use. So they are not open in the chrome storage. The only other alternative to chrome.storage.local is the localStorage API. I think there is not much of a difference between these two. However the chrome.storage.local is seperated from the browser context. There is no way a webpage can access this storage. It needs to get through 3 layers of messaging protocols.

from nami.

Does the last line hold true when there is a local copy of Nami-wallet running on a machine, which tries to access the chrome.local.storage? Would the information still be intact?

from nami.

I'm not sure what you mean here with local copy. Do you mean if other extensions have access to the same chrome local storage instance? It's not the case, it's also isolated from others.

from nami.

What I mean is that, Say there is NamiWallet, talking to Testnet for this example, installed in a machine with a user having little or Zero knowledge of how Nami or Metamask wallets store data internally... and some developer deploys a local running env of Nami wallet in that machine... would that developer be able to access Nami stored data from chrome.storage.local by running the exact same process that Nami uses to login?

from nami.

I think there is a misunderstanding of the encryption process here.
Nami doesn't "login" to access/decrypt the storage.

The wallet secret key is encrypted and stored upon wallet creation/restore process. The storage isn't encrypted, it is the stored key that is encrypted. The rest of data is stored in plain text as it is all publicly accessible from Blockfrost API.

When you do need to sign a transaction, the encrypted key is pulled from the storage and decrypted "in memory" at runtime when you input your wallet password. The key is never persisted anywhere in a "decrypted" state. Wallet password is never stored, the password you input when signing is required can either decrypt the key or not. When you do see "Wrong password", it means the decryption process failed.

Does it shield you from every kind of attack? No. If your system is compromised, an attacker could log your password as you type it. There is a lot of possible threat and this is true for every wallets out there. This is why it is highly recommended to use an Hardware wallet (ex: Ledger/Trezor) to secure any substantial amount. As for now, Nami doesn't support these devices.

from nami.

True. That was the concern behind this Github issue, and this is why I was stressing on not using local storage for this crucial approach, as these browser supported Soft wallets are most vulnerable to attacks, and hence "loss of assets".

As a solution, what I suggest is :

1. Delegating the encrypted storage to SPOs, who are running the Cardano Node backed with Logosphere [https://www.logosphere.io/], which is written using Fluree [A Decentralised blockchain inspired DB : https://flur.ee/]
2. Using Fluree's smart function capabilities, we can allow the encrypted information access to only the wallet owner

This way, the wallet data will never be stored on a centralised browser storage, and hence little to no chances of attacks. Besides this can be integrated with Alta Prism in future, as everything will be backed with Cardano.

from nami.

The local storage is locally on your machine as the name already says. There is no such thing as "centralized browser storage". If I would use your suggestion I would still need to query the encrypted private key to build the transaction. So each time I would need to make an https requests for pulling the key, this makes stuff risky.
Also nothing prevents the SPO from brute forcing the storage.

from nami.

Having the secret key encrypted and stored in chrome storage is no less securred then having them encrypted and stored on your OS file system, this is the same. So I disagree that "soft/light" wallet keys are less secure than full node wallet keys (Daedalus). They both have their keys encrypted by a password only as strong as the user makes it. Both can be brute forced if compromised.

Thanks for sharing your solution using the product you are working on, I looked at some part of it related to security & data access right. There is obviously interesting use case for it, but it wouldn't really make the wallet more secure.

Using Fluree's smart function capabilities, we can allow the encrypted information access to only the wallet owner

Even using your solution, a user still need to identify himself, theses credentials are exposed to the same risk.

Current solution:
(User PWD) --(gives access to)--> Encryption Key --(gives access to)--> Assets stored on blockchain
Proposed solution (maybe in a too simplistic manner):
(User PWD/Credentials) --(gives access to)--> Encryption Key --(gives access to)--> fluree chain --(gives access to)--> Encryption Key --(gives access to)--> Assets stored on Cardano blockchain

Maybe I got the concept completely wrong, you'll tell me. But from my point of view, no matter the numbers of security layer added, the week point still the same.

I'm closing this issue as this vulnerability will be fixed with the implementation of hardware wallet support.

from nami.