4
$\begingroup$

I am attempting to make a web-based secure password management and sharing utility, both as an academic exercise and to fully understand and feel safe about using it.

I really like the idea of a "host-proof" application, where encryption/decryption is done on the client side using javascript and only encrypted information ever leaves the browser, much like PassPack or Clipperz. What I cannot figure out is how Passpack manages to allow people to share passwords. I cannot see how it can be done without either plain text or an encryption key being transferred to the other user via the server, making that process inherently break the "host-proof" paradigm.

Can anyone point me towards a solution?

Improve this question
$\endgroup$
5
  • $\begingroup$ What security assurances are given by a "host proof" application? By "to allow people to share passwords" do you mean "not to be insecure if different parties happen to choose the same password"? What functionality do you require from your "password management and sharing utility" that needs to be kept secure? In particular what is your definition of secure if passwords are shared? $\endgroup$
    – ByteCoin
    Commented Feb 23, 2012 at 0:19
  • $\begingroup$ These are very important questions. My aim is to have the ability to store and share account information with only authorized users and no unauthorized users. The theory is that this application could be hosted on a shared host or cloud environment without having too much trust in the host itself. Rather than 'harden' the environment, just not trust it too much in the first place. Please check out this link on ajax patterns: Host-Proof Hosting $\endgroup$
    – Travis
    Commented Feb 23, 2012 at 4:57
  • 1
    $\begingroup$ @Travis: The problem with this approach is that you (your users) still must trust the server to send really the original Javascript, and not a maliciously modified version which (for example) shares the key/password with the attacker, too. Have a look at Javascript Cryptography considered harmful for some elaboration about this (although more from the point of view of sharing data with the server, not protecting data from the server). $\endgroup$
    – Paŭlo Ebermann
    Commented Feb 23, 2012 at 8:44
  • $\begingroup$ @PaŭloEbermann: I understand that risk and know some people have made attempts to fix it, or accept it as a flaw and do what everyone else does - trust the server. There are still benefits to never transferring plain text data to the server, but your link and a few others have opened my eyes to a few of Javascript's other shortcomings. What do you think of using Adobe Flex/Air, as they're compiled? There appear to be some good crypto libraries available. I'm not strong when it comes to Flex, but it seems to fit the bill of compiled client-side code, which could be verified upon download. $\endgroup$
    – Travis
    Commented Feb 23, 2012 at 14:57
  • $\begingroup$ @Travis In Adobe Air you can sign your applications with a certificate issued by a recognized certification authority. The problem with cryptography in AS3 is that it is slow. Thankfully there is a way to circumvent this limitation: using Air Native Extensions, but this requires you to publish your applications as native installers which cannot be signed. If speed is not a requirement, this may be a viable solution on first thought. $\endgroup$
    – Chris Smith
    Commented Feb 23, 2012 at 20:42

1 Answer 1

Reset to default
2
$\begingroup$

Getting data from user A to user B securely generally works via asymmetric encryption. Encrypt the data with B's public key and store the result on the server. B then retrieves the encrypted data and decrypts it using his private key.

This assumes the server does not store the private key, or at least stores it in a form that can only be decrypted by the owner.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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