pull down to refresh
109 sats \ 10 replies \ @k00b 14 Oct \ on: Minor complaint meta
Tagging @ek so he doesn't miss this.
I don't think we considered someone clearing their browser history frequently. I'm not sure if we can persist the key when this happens, but perhaps there's something we can do to better handle this situation.
reply
reply
Can users set their own pass phrase? Then they can decide how easy or secure they want to make it
reply
No, at least not currently.
The reason the passphrases are generated is so we don't have to worry about spending wallets with weak encryption that we or a hacker could crack if they ever gained access to our database.
But I think I was mostly biased against user-generated passwords because I'm sure some will pick weak ones and I'm not sure in what position this puts us. The obvious solution would be password rules but I was also biased against them because most of the times their UX sucks. But maybe our UX doesn't have to suck? Mhh
I also thought about PINs:
However, maybe a PIN chosen by the user would be even better?Since we're trying to make it easy to unlock the wallets, and this is currently only possible by entering the passphrase, a user-chosen PIN should be even easier than entering a (custom) passphrase, right?The issue with that is that encrypting the passphrase with a PIN for easy unlocking is very insecure unless the encrypted data is deleted after a few failed attempts. However, since the encrypted passphrase is stored in our database, we cannot actually enforce a limit on the number of attempts by anyone who has access to the database.
But as you can see, I don’t see how we could implement PINs without compromising too much on security.
reply
I can see how it puts you in a tough situation. Even if it's the user's fault, you don't want to be caught up in any issue regarding stolen funds.
reply
reply
Next to PINs, another idea was to seed a PRNG with a device fingerprint and generate a key pair from that. This would mean that the device can always regenerate the same key pair without any user input required.
The first device would generate the passphrase as usual, but then encrypt it with its own public key.
New devices would then be approved by a previously authorized device to also gain access to the passphrase1 and, therefore, to the wallets.
This is essentially a scheme to sync the passphrase that would only require user interaction when adding a new device.
However, I’m really not sure about using device fingerprints to seed a PRNG for cryptographic key material, lol.
So this still doesn’t solve how to deterministically derive a key (pair) on the client device with minimal friction for the user.
But if we can assume that a user doesn’t lose their key on all devices at once—so there’s always at least one device left to approve a new one—then just the “approve device” part of the scheme could make entering the passphrase much less frequent.
(We talked about this before, so this isn't really a new idea except maybe the part about using device fingerprints as seeds.)
Footnotes
-
We could probably just store another copy of the passphrase encrypted with the new device’s public key ↩
reply