You are viewing a single comment's thread from:
RE: Bounty for completion of native JavaScript steem signer
@pharesim Grr you had to post this just before bedtime for me...
I'll byte :)
Do you care about the specific way you're going with this, or just that it works? You seem to be going about it a bit sideways.
@pharesim one final thing, are you trying to do this in a completely cross browser way? I ask because crypto.subtle is a javascript inbuilt function that could be used to secure the keys while in localstorage, but not every browser is quite there yet. Most are but it can be hit and miss. http://caniuse.com/#search=crypto
The advantage here is that the browser sandboxes the hell out of the encryption key used to encrypt the private keys. So no XSS stuff and no malicious script later imports either, can really come in and dink around with the crypto stuff.
Please correct me if I am mistaken, but seems to me that the browser sandboxing the signing private key won’t protect against an attacker’s XSS script which invokes the crypto API for signing.
I should also elaborate, that the encryption key, is protected by the sandbox which allows that key to only encrypt and decrypt content. It will not allow any script to change the parameters of the key, or expose / disclose the key contents. The key is created with these permissions and the sandbox is default deny for anything that wasn't explicitly allowed.
This encryption key is used to encrypt the signing keys, and the decrypt operation is further sandboxed by happening inside of a webworker.
Then end result is that while an XSS might be able to get you to sign something you didn't intend, it cannot extract the key.
If you make the web worker accept a PIN or password in order to do high value operations and use window.prompt to acquire the user's consent, you then at least alert the user that someone is asking them to sign something. This defeats XSS.
@anonymint Replying over here because we hit the comment depth limit.
An attacker wouldn't be able to intercept the actual dialog from the browser and input the PIN to authorize the transaction programmatically.
The very best they could do is push a dialog and try to collect the information themselves. But that would do them no good because the webworker is a process isolate.
If done correctly, it wouldn't be frequent enough to be a major irritant. Just something to notify them that someone has sent a message to the worker requesting a signature. It couldn't just be affirmatively dismissed. They would either need to input the PIN or decline the transaction.
So the salient point is the browser will prompt the user for each signing. So this means the user would have to confirm via prompt to the browser for each posting action such as voting, posting and editing a comment, etc..
That is a significant irritant¹ to the users as compared to perhaps just doing better security. There is a trade-off.
For the more infrequent cases of signing for money transfers where a browser prompt would not be an irritant¹, do you think we could trust sandboxing the money signing private key? I would think hackers would then have the incentive to target the browser and the user's computer. But I guess it is no worse than having the user enter their signing key for money actions every time, because a hacker can still try to intercept these. Really for money signing, it seems hardware wallets are the way to go for larger balances.
Note for those hoped for microtransactions ecommerce in the future where money transfers signing will be frequent, then a prompt from the browser for each one might be an irritant. A better solution may be to have smaller balances for that private key and just use the better security strategy.
¹ Not only an irritant but users may become so accustomed to dismissing these prompts as quickly as possible, that they maybe can be fooled into acknowledging them when the hacker has issued one.
It's protecting the keys and raising the bar.
As long as the latest FF and Chrome (bonus: Safari) support it it's fine. We have to use the latest technology here :)
My goal was to have a wrapper that can sign transactions and forward them to my steemjs. I don't rule out better alternative approaches though.
Hello. Excuse my disturbing you. I would like to get your opinion on this. https://steemit.com/steemit/@acidsun/steemit-t-shirts-accessories-design-from-acidsun