2

I'm looking for some advise on designing a secure web app for storing passwords. Why reinvent the wheel? Because I don't trust a 3rd party with all of my passwords.

Here are my thoughts:

  • There are 3 main components: Client, Application Server, Database Server. Ideally, I would like the system to be robust enough, so that if either the Application Server or the Database Server is compromised, the attacker doesn't get all the data (if the client is compromised, I can't see any way to protect the data).
  • To accomplish this, I would think doing all encryption on the Client makes sense. So, if the Database Server is compromised, they would only get encrypted data, and if the Application Server is compromised, they wouldn't get the encryption keys because the Client keeps those.

  • That creates at least 2 problems:

    • Client side crypto in this context means javascript crypto which is problematic. Here is how I'm planning to get around some of the main issues.

      • No good CSPRNG. Only use browsers with getRandomValues() and use a js crypto library that supports it.
      • Man in the middle. Force TLS for all connections (doens't help if App Server is compromised, of course).
      • XSS vulnerabiliy. Write a companion user script (Greasemonkey) that calculates hashes of each page on the app, and alerts the user when any page content has changed. Obviously, this will lead to false positives when you make updates, but it should allow you to detect if anyone has modified your code on the App Server or successfully injected any content into the page.

    • Searching on encrypted data is complicated.

      • I don't have a concrete solutions for this yet, but if the general plan seems feasible, there are good options out there.

I realize this question is a bit broad, so feel free to close it if it's not a good fit for the site. I'm just hoping to get some general guidance on what I might be missing or where the holes in my plan are.

Update: Thank you all for the very helpful feedback. In light of some of the issues brought up, my new plan is to make everything much simpler. Keep a single, compressed and encrypted JSON file on the server. Write a JS app that runs locally. All it does is grab the file, decrypt it locally, and then reupload it when changes are made. Thoughts?

Also, I do see your point about using a well vetted and proven system. Call me tinfoil-hat paranoid, but I just can't trust someone else with that much access. All it takes is one disgruntled employee/contributor or one security hole for you to have a really bad day.

Improve this question
3
  • 1
    I'm struggling to see how calculating a hash of the page helps. You would need to keep the hash clientside, so why not store all the code clientside. And if the data is securely encrypted then just use jdrop?
    – symcbean
    Commented Jan 22, 2015 at 23:37
  • 3
    Long story short, this is silly. If you want to use it as an exercise to learn more about security, go for it. But whatever intentional sins you expect the authors of KeePass, LastPass, or 1Password to have committed, the unintentional flaws in whatever you build will be orders of magnitude worse. Additionally, KeePass is open source, and neither KeePass nor 1Password require syncing to a central server to operate, so all of the data is stored either entirely locally on your own machine, or on whatever independent cloud storage provider you deem secure enough.
    – Stephen Touset
    Commented Jan 22, 2015 at 23:42
  • @symcbean, thanks for the feedback. I suppose I could store all or most of the code client side. My thinking was that calculating hashes would allow you to alerted when a hash changes unexpectedly (e.g. XSS)
    – Dominic P
    Commented Jan 23, 2015 at 8:06

3 Answers 3

Reset to default
3

The thing about a web app is it's fundamentally insecure if the source code (e.g. JavaScript) is delivered to the client over TLS. You can run the best encryption you want e.g. one-time pads or cascaded stream ciphers, but it will only be as secure as the ciphers and "security" in the TLS suite which is not secure against spy agencies. There have been fundamental flaws in TLS for years. Probably bad by design because NSA is on all the standards committees. Also read about the OpenSSL Heartbleed fiasco. Not to mention the whole protocol is trivially insecure against nation state adversaries with just one CA in their pocket. All they need to do is MITM the connection and swap in a few lines of dodgy JavaScript to steal the encryption keys and passwords.

You have to make a browser extension or run the web code locally from the file path. Use CORS to make requests to the application server. All code is loaded and run locally. All encryption done client side. No server delivered code.

You can also add custom code on the client and application server to encrypt the transport traffic from the client to the app server to protect the meta data as well if you want.

Improve this answer
1
  • Thanks for the insights. I wasn't aware that TLS was so broken. That's definitely some food for thought.
    – Dominic P
    Commented Jan 23, 2015 at 7:55
1

This is one of those jobs best left to INFOSEC professionals. Too much to go wrong. The closest thing I've seen to what you're describing is Clipperz:

https://clipperz.is/security_privacy/

Running that from a local file hardcoded with your server's I.P. address over SSL or IPsec would be a start. I agree with NDF1 that a native app is better mainly due to reduced attack surface & greater development flexibility for security engineering tech. That's why projects like KeePass already built useful, cross-platform, password managers for us. I'd say just use a tool like KeePass or study such tools' methods if you choose to roll your own. Also, to help, here's my essay on many cutting edge and typical approaches to web application security with links:

https://www.schneier.com/blog/archives/2014/04/the_security_of_8.html#c5626550

Improve this answer
1
  • 1
    I hadn't come across Clipperz. Thanks for the suggestion and the interesting reading.
    – Dominic P
    Commented Jan 23, 2015 at 8:04
0

I think what you may want to look at is secure multi-party computation. Even if one 3rd party is compromised your passwords still stay secure unless all the 3rd parties collude in order to steal your passwords. I am not sure what your threat model is. Do remember that storing keys on the client may not always be the best idea (e.g., use of browser-based client side storage is hardly quite secret). If you are using iOS devices and you are relying on the storage using keychains then you are probably doing one thing better but multi-function machines like computers can be incredibly difficult to store really secret information on.

Improve this answer

You must log in to answer this question.

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