2

I work on a web application with the client side being a single-page Javascript application and the server side being a REST service. This application manages sensitive user data which must not be readable even by an attacker with full read-access to the live database or some database archive.

Our plan is to:

  1. when the user registers, generate asymmetric keys on the client side and send them to the server, with the private key encrypted with a key derived from the user password
  2. authenticate the user by asking the encrypted private key from the server and decrypt it on the client side using the user password. Successful decryption equals successful authentication
  3. generate symmetric keys when a sensitive document is created, encrypt the document and share these keys with the authorized users, PGP style
  4. for password recovery we give the user his plain private key and trust him to keep it safe

Note that we assume that the attacker doesn't control neither the browser nor a running server.

In this scenario, what attack vectors do you see?

Is it possible to implement a simpler recovery mechanism that doesn't require the user to store the private key?

Do you have any other concerns/recommendations?

Thanks

Improve this question
9
  • You don't have to complicate things so much. If it's just read access to the database it means he doesn't have read access to the memory of the server. You can safely encrypt everything on the server before storing it in the database and do the same thing for retrieval.
    – Gudradain
    Commented Feb 7, 2017 at 15:00
  • You can't have a recover method. A reader attacker means "someone who could clone the server DB", meaning they would then be able to do the recover process. Recovering would then have to be out of DB. Memory sounds not reliable (what about a reboot?). Server's file might be (but then, what about a FTP-read-only attacker?!)
    – Xenos
    Commented Feb 7, 2017 at 15:01
  • @Gudradain all the Crypto-Fu will have to happen anyway so, in this case it's not a big deal if it happens on the client side or on the server side. The advantage of doing it on the server is that the client code is smaller and uses less CPU. Or am I missing something?
    – vidi
    Commented Feb 7, 2017 at 15:13
  • @Xenos we thought about qr-encoding the key such that the user can print it and store it safe. If he has to recover the password he has to provide the qr-code of the private key. Another approach we thought of is that if the user loses the password and also the private key he loses access to his key-ring and then we re-create his account based on his phone number with an empty key-ring. Access to the documents he had access to before has to be granted again.
    – vidi
    Commented Feb 7, 2017 at 15:44
  • @vidi Sounds like the QRcode is the password then. Printing it/the private key sounds unsafe... Even "encoded". And you cannot grant back an access: documents should be lost forever since user lost their password.
    – Xenos
    Commented Feb 7, 2017 at 15:55

2 Answers 2

Reset to default
1

In this scenario, what attack vectors do you see?

If your platform is the browser, then one possible attack might be to modify your javascript code in transit and add in a few lines of code that share the client-generated keys with the bad guys.

This implies a successful MITM attack on the downstream traffic. This may be made possible by design in contexts where there is content filtering going on between you and the client which needs to read encrypted content in order to make filtering decisions. If an attacker attacked the content filtering server instead of your server or the client browser, it's probable he could succesfully pose as your server and modify the javascript that the client sees, and you'd never know it.

You said that neither the browser nor the server are under an attacker's control, but if either was the case, obviously it would be a piece of cake to break the protocol.

Providing the browser with a plugin which can verify signatures on downloaded javascript may make this safer, but I don't know enough about the browser security model to make an informed guess.

Is it possible to implement a simpler recovery mechanism that doesn't require the user to store the private key?

Based on your comment to clarify the design, I'd say no.

Improve this answer
2
  • As I said, when Alice creates a document she also generates a symmetric key and encrypts the document with it and stores the symmetric key in her key-ring. If she wants to share the document with Bob then she encrypts the symmetric key with Bob's public key and adds it to his key-ring. This way if Malory has read-access to the DB she cannot access the document. This is what I meant by "PGP style". I don't understand how this can be done without asymmetric cryptography.
    – vidi
    Commented Feb 7, 2017 at 15:31
  • Ah! Now I understand.
    – Out of Band
    Commented Feb 7, 2017 at 15:34
1

If it wasn't the browser, the scheme would be sound. Unfortunately, due to several problems imposed by browser, it isn't:

  1. MitM: as mentioned previously, attackers can send you wrong JS by compromising transport. Moreover, verifying javascript won't help, due to code execution model in browser - we could easily add another <SCRIPT>, which will overlap some of the functionality, instead of replacing it.
  2. Assuming that attacker cannot control browser is a wrong assumption you can't really make. Everything on your page is content-controlled: any part of DOM tree can affect any other part of DOM tree. Any insecure external resource on your page is a subject to MitM, too. You include assets via HTTP connections? Attacker does not even have to attack your connection.
Improve this answer
2
  • I don't understand how this script injection would happen if the connection is HTTPS and all the resources (scripts, css, images, fonts etc) are downloaded from my server
    – vidi
    Commented Feb 9, 2017 at 8:53
  • Then you're a bit better: if you do your part right and your clients are paranoid enough, you might avoid most obvious attacks. However, HTTPS does not prevent CSRF / XSS. Moreover, HTTPS is MitM-prone too, in cases where client isn't paranoid enough (dumb client + smart proxy intermediary, fake certificates signed by true root certificates, browser not verifying certificate validity,- endless stream of possibilities).
    – pFarb
    Commented Feb 9, 2017 at 11:59

You must log in to answer this question.

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