0

I'm working on a web app, and I know little about security/cryptography (for now, still learning) but I'm trying to set up a front-end where:

At the very beginning, the user puts in their private key.

The key is stored as a variable in javascript.

Any time the user does anything to interact with the backend, the key is used to sign or encrypt whatever data it needs to, the data is sent, and when the user is done with everything, they close the browser.

Is this a secure way of doing this? Can anything but my JS code access this key in the process?

(P.S. it's gonna be RSA or ECC so asymmetric, private key is only known by front end user)

12
  • 1
    Why the extra signing with the key? Is regular HTTPS not good enough? If the idea is to make it so that you can prove that the client affirmatively did something, this would be disqualified on the grounds that the client has now given you (access to) their key, and it could be exfiltrated and used to sign whatever you (not necessarily the client) want. Oct 15, 2019 at 20:59
  • Are you using crypto/other libraries from a CDN? Very unlikely but untrusted code could be used to steal the private key. Oct 15, 2019 at 21:07
  • Are you familiar with XSS? Oct 15, 2019 at 21:09
  • @Clockwork-Muse, the way I read it, they're thinking of having the user enter the key, then save the value to a variable without doing a POST or an AJAX request... but I, too, am wondering what the actual use case here is. ml888: If it's just for identification or authentication, or data integrity, then there are user friendly ways that are just as secure. If it's for non-repudiation or confidentiality, then keep in mind that the browser itself offers no guarantees (plugins and extensions can usually execute arbitrary JS on every page a user visits).
    – Ghedipunk
    Oct 15, 2019 at 21:21
  • @Ghedipunk - save the key to a variable with the user assuming there is no POST or AJAX request. That is, what happens if I, as a client, argue that the server maliciously stole my key and signed data, because they sent me the code in the first place. Oct 15, 2019 at 21:27

2 Answers 2

2

You may want to consider using the Web Cryptography API. Then, you can store the user's private key in the CryptoKey object, with the .extractable property set to false. This way the private key can only be used for decrypting and/or signing messages within the browser - but can not be read (even by client-side scripting in the browser).

0

I'd suggest looking into this blog post and corresponding presentation by Pomcor. Storing the key in the browser does have security vulnerabilities, in particular malware and physical takeover attacks. That said, there isn't currently a great way to avoid this. Ideally, the private key could be stored in the device hardware, but browsers don't expose access to this today. As @mti2935 notes, Web Cryptography is your best bet today.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .