-1
$\begingroup$

I'm developing an intranet for a company where admins are sharing a huge excel file containing all the necessary password, on the common TSE. I've managed making them encrypt it with a common password at least.

I would like to make a "password sharing" system on the intranet, allowing them to store passwords and data encrypted, shareable between them, but obviously, unreadable if it hasn't been shared (even for the db admin).

So, if they used PKI or even knew about it, it would be great. So I'm looking for a way to store encrypted data, which would be decrypted on the fly when a logged in user wants it, but only using common "login" practices if possible (user, password, web browser).

Of course, the server shouldn't be able to decrypt the data alone, it needs something from the logged in user (for instance, deriving the user's password as the users key), so "sharing" a data would only be possible when the data is inserted. For that, I'm can't see how to achieve it without a public part and a private part, which I'm avoiding because they won't take care and will loose them.

It's not the best, but one of my ideas was to create a key-pair (under the hood) for each user stored encrypted using a password derived from the user's credentials. The key-pair and derived password would be stored in expiring cookie (when browser/tab is closed) (decryption will be client side) or more secure, in-memory session files (server side).

What do you think folks ?

$\endgroup$
  • $\begingroup$ "where admins are sharing a huge excel file containing all the necessary password" D: can you please make them use the open-source KeePass, which is designed and hardened to handle passwords? $\endgroup$ – SEJPM Jul 28 '16 at 9:51
  • $\begingroup$ @SEJPM I have written them an "observation report" on which I strongly advise to use KeePass $\endgroup$ – Max13 Jul 28 '16 at 10:12
  • $\begingroup$ What is your scenario? Can you do just about everything because it's a stand-alone app? Are you bound by browser-restrictions? Can you leverage OS (Windows?) features? $\endgroup$ – SEJPM Jul 28 '16 at 10:17
  • $\begingroup$ @SEJPM I can do almost everything. No browser restriction but they're only on Windows (which is not an issue as I want to integrate something on their intranet website). I could leverage OS feature (Windows) but I personally am working on OSX, and I work with them, so I will have to leverage the same feature on OSX also. I guess... $\endgroup$ – Max13 Jul 28 '16 at 10:25
  • $\begingroup$ One trivial solution would be to use something like Windows' DPAPI to encrypt the data in the DB designated for that user. Alternatively you could roll out certificates and private keys to all users using Windows' built-in features and certificate and key store. $\endgroup$ – SEJPM Jul 28 '16 at 11:00
1
$\begingroup$

OK, so here's a quick summary of your scenario: You want to secure an application that can store data on some server, which has to enforce dynamic access rights and all you're given is maybe a username and a password and no limitations on the client / server computations and protocols.


What I now suggest is a multi-step approach to the problem.

  1. Connect and authenticate the client to the server using username and password.
  2. Grab the encrypted private key for the data access from the server.
  3. Decrypt and verify the private key using the very same password from the start (1).
  4. Request and decrypt data as needed, leveraging the advantages of asymmetric cryptography.

Now for the details:

Step 1:
This is a well-studied and solved problem. Connect to your server via TLS, grab the salt from it, do a client-side password based key derivation, send the hash back to the server and hash it one more time there and you're done. This is only the short version, the long version can be found in: "Method to Protect Passwords in Databases for Web Applications" by Contini. Do note however that you shouldn't re-use the salt from this step at any other step.

Step 2 and 3:
Using your favorite database store an encrypted blob which represents the private key for the given user. Enfore using policies or whatever that only the logged-in user can get hands-on this blob.
The blob should contain parameters for the password-based key derivation function as well as a unique (easiest way: random) salt and the encrypted data chunk with an authentication tag. Note that using a multi-step approach can give you backup functionality here, by encrypting the symmetric key using multiple passwords (you'd derive a key from the PBKDF and use that to decrypt the symmetric key) or by encrypting it using asymmetric encryption. Make sure that the authentication tag also covers the salts and the other header fields, and make sure to re-compute the tag whenever you only change the header.

Step 4:
Each data object is encrypted and authenticated using a symmetric key. The symmetric key itself is encrypted using multiple public keys (one for everyone who has access) in the header. As this uses asymmetric encryption you can dynamically grant and revoke access to the object(s) by adding or removing these encrypted copies.


Algorithm recommendations:

$\endgroup$
  • $\begingroup$ Hey really great thank you! It's almost what I thought about (using asymmetric encryption) :) but I don't get the "encrypt the symmetric key with a derived key" part, as in step4, the symmetric key is already encrypted using asymmetric key, isn't it? BTW, do we agree that the encryption/decryption process should be done client side to avoid sending "clear data" to the server? If we do so, the data must not be too big for the browser, right (like a big image or big document) ? $\endgroup$ – Max13 Jul 29 '16 at 3:24
  • $\begingroup$ @Max13, using a PBKDF you derive a key from a password and a salt. You then use this key to decrypt a copy of the symmetric key used to encrypt the actual data. Yes, any decryption operations I described in my answer are supposed to be client-side. The overhead these methods introduce should be in the kilobyte range (or less) and as for the remaining bandwidth stuff, they already had these problems before and this doesn't make them worse. And if you're thinking about using a browser + JS for the client-side stuff, note that an evil admin can modify the JS to dump keys in theory. $\endgroup$ – SEJPM Jul 29 '16 at 9:16
  • $\begingroup$ Sorry, maybe I wasn't clear. I understood that on step 2 and 3, the symmetric key for the file encryption can be either encrypted using derived keys (from user's) or using asymmetric keys (as it usually works). What I don't get is that step 3 and step 4 seems similar: if we already encrypt the symmetric key using a derived password from user's or asymmetric key in step 3, why re-encrypting using asymmetric key in step 4? $\endgroup$ – Max13 Jul 29 '16 at 10:39
  • $\begingroup$ @Max13, you store one asymmetric key in the data-base (step 2 and 3). This key's public key is then used to encrypt and decrypt many data objects and especially you can use the public key to grant the key owner dynamically without him having to agree, access to some objects. $\endgroup$ – SEJPM Jul 29 '16 at 22:17
  • $\begingroup$ Actually that's exactly how asymmetric encryption is already used, I don't know why, some parts of your answer confused me. Thanks for clarification. Something else came up: is the best scenario, I would like to show directly on screen (on the website) the decrypted data. Of course, impossible if I don't have the clear key on the webserver (to send the plaintext to the client) or make use of js decryption (private or symmetric key). Platform keystores can encrypt/decrypt downloaded data, not what's on a web page, right ? $\endgroup$ – Max13 Jul 29 '16 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.