Your site did send me a verification request email; the issue I raised was that the webapp allowed me to do everything without answering the verification request. Was that verification just something that came out of a Phoenix generator (or similar) and wasn’t intentional? (I don’t use the Phoenix generators myself, so I don’t know what they produce).
I think in general, it has to be recognized that getting this kind of service implemented correctly is a challenge even for people with solid experience in the areas of encryption and building highly secure systems. The problem in building security sensitive services is that it is utterly unforgiving of any oversight, mistake, or misunderstanding in a way that other software development isn’t. Those oversights/mistakes/misunderstandings become the vulnerabilities that get exploited by malicious parties; working as a solo dev in this space can be even harder since regular vetting of security related designs and code by someone without the built in confirmation biases we all bring to our own work is usually not available in any important way. I have had responsibilities in designing and building systems where a single user’s web form submission could redirect many millions of dollars, where we deal with user’s personal information, including sensitive banking, payment processing (credit cards), and medical information, and similarly security sensitive applications. The only way I’d try a project like this on a solo basis is in building a proof-of-concept to take to others like possible investors; I’d need a lot of other very qualified and smart people with eyes on it prior to a launch of services to the public. (note: I have decent experience in dealing with secure systems, but wouldn’t call myself a security expert.)
1password would be a good study however. The problem they solve is not completely dissimilar to what you’re trying to do (though there are clear differences, too) and they have put a lot of thought into the problem. A link to their whitepaper on their security design is: https://1passwordstatic.com/files/security/1password-white-paper.pdf
For example, they follow a common pattern where the user’s credentials are used to encrypt other randomly generated encryption keys which are the keys actually used to encrypt the data. This is part of the solution for being able to change the user’s password: the randomly generated keys are decrypted with the user’s old password and then re-encrypted with the new user password: this way you aren’t re-encrypting all of the data. This is fairly hand-wavy explanation which glosses a fair amount.
Consider this from the linked 1password document:
All cryptographic keys are generated by the client on your devices, and all encryption is done locally.
The unencrypted data on the server under your model that I raised issues go way in the 1password model. The data arrives to them already encrypted. Naturally, they can’t vouch for the security of your device, but they should have pretty good resilience to a compromise on their side.
Again, read their paper to get the gist of what a security services look like to implement in software… and to operate: a subject I haven’t even really discussed at all, but which is as demanding as the software development side.
I’ll stand down now. Best of luck.
