btc-rpc-explorer
btc-rpc-explorer copied to clipboard
janoside
Prevent pasting private key/seed into the search box
Hey guys,
Could we somehow prevent users that have their seed words or private key in clipboard (for whatever reason), to paste those into the search box?
They should not have those on the computer or in the clipboard, but those that made that mistake or are testing something to create some kind of detection that jumps in and stops the pasting into the search bar. Just an idea.
I don't believe this would help security but maybe it'd train people to not use clipboard for secrets. OTOH, If one uses Qubes or other secure method then pasting private key to get the balance could be valuable.
I think this is a good feature request because on the client side the input can be checked and block sending the input to the server if it is obviously a key or seed. This minimizes any accidental exposure when people run the stock code.
I have created a branch to slowly work on this.
Awesome
On Fri, 16 Apr 2021, 20:05 pointbiz, @.***> wrote:
I think this is a good feature request because on the client side the input can be checked and block sending the input to the server if it is obviously a key or seed. This minimizes any accidental exposure when people run the stock code.
I have created a branch to slowly work on this.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/janoside/btc-rpc-explorer/issues/291#issuecomment-821373911, or unsubscribe https://github.com/notifications/unsubscribe-auth/AILPGMGR5Y62LGCH75FCA3LTJB35XANCNFSM4YIA76NQ .
@pointbiz isn't server supposed to be your own? If it's malicious, it will simply send a different version of JS without your patch.
But maybe it'd be interesting if JS derived xpub and send that, but as I said, the server can send malicious JS anyway. At best it'd help if the user saves the site.
I'll be happy to merge a PR for this concept, though I agree the protection it would provide is narrow in scope, especially in the intended self-hosted context.
@pointbiz isn't server supposed to be your own? If it's malicious, it will simply send a different version of JS without your patch.
But maybe it'd be interesting if JS derived xpub and send that, but as I said, the server can send malicious JS anyway. At best it'd help if the user saves the site.
Your point is valid. There's a narrower scope where it helps... honest third party hosting and self hosting where http log entries are avoided.
Yeah, that seems to make sense. I recommend making it into a visible warning that would teach people to be more careful. Derivation may be added later.
isn't server supposed to be your own? If it's malicious, it will simply send a different version of JS without your patch.
Even if the server is self-hosted and not malicious, it still makes sense to avoid sending private keys to it because it might expose them over LAN in plaintext, or over the internet at the mercy of SSL CAs.
If LAN or SSL CAs are MITMed, the attacker can modify the code being sent, same issue. This can really only be fixed by using secure means in the first place.
Not that I would be against the idea. I'm just saying that considering it low-priority is OK.
A passive attack isn't the same as an active one. Modifying in-flight traffic is more risky and is more likely to be detected compared to just listening in on the wire.
But I do agree that its low-priority, just don't think that its useless :)
Cloudflare is ubiquitous and that's another third party that could log POST data.
@pointbiz what does cloudfare has to do with self-hosted web apps?
Depends how you define self-hosted. This software is permission-less. Only if someone uses cloudflare to host remotely (not on their LAN) would that add an additional third party who could access any accidental pasting of secret material.
There's already a PR I created for this low priority feature.