Apr 28th, 2010, 5:52 AM
Hey Ben,
Thanks for the quick reply. Just adding a couple notes/questions, so please feel free to ignore. I understand this is a back-burner feature at this point:
1. As long as the encryption key could be an easily-typed phrase, or even a txt file stored locally on authorized client machines that could be selected and uploaded when prompted per session, I think that would be a fine tradeoff. In a lot of public spheres, the emphasis (for better or worse) is on "taking steps" to secure data, rather than solving it all at once. Clearly it would be better to solve the problem outright, but incremental progress is often demanded even when it's short of a perfect solution. This is not a reflection on Form Tools; it's a reflection on us and other bureaucratic entities. Even if, say, a key is stored in a config file, and someone gains access to encrypted data, it's still a better position for me to be able to say, "look, online data is online data. We protect it as best we can and we encrypt it on the server, but security measures are not full-proof, and just as a person could break into your office and take something off of your desk, our server, despite our precautions, could be the target of a criminal act that results in compromised data." I guess what I'm arguing is that baby steps toward increased security are still of great utility to some organizations, even if they have limitations.
2. I'm not sure about the file storage outside of the web root issues, but if a user is logged into the Form Tools admin area, and the php files have read/write to a file outside of the web root, couldn't the files be grabbed for download by a php call, or would they still need to be written to a temp directory first? This is a question more than a suggestion... lol... I just don't know. I'm not concerned about losing the functionality of web links in, say, emails... where a straight http call won't be able to grab anything outside of the web root. I realize this is an issue... but maybe it could be an either/or if the "increased security module" is used for a particular form... where file access is only granted through the Form Tools admin area if increased security is selected.
3. As always... I'm very appreciative of the product so far and I look forward to its development moving forward.
am
Thanks for the quick reply. Just adding a couple notes/questions, so please feel free to ignore. I understand this is a back-burner feature at this point:
(Apr 27th, 2010, 9:00 AM)Ben Wrote: 1. encrypting form data
The other option would be to quiz the user when they log in, to supply the encryption key. Annoying! But better from a security standpoint.
Secondly, encrypting-decrypting is fine for the Form Tools Core - but it would break any modules that query the database directly. Offhand, I suspect that's a fair number. So a number of modules would need to be updated.
2. File Uploads
I agree - storing files outside the webroot would be nice. The problem is that as soon as you do that, they can no longer be linked to via a web-browser; you'd need to actually move them to somewhere with a URL so that they can be browsed. I'd have to think about this one... but it actually sounds like a module in of itself!
Anyway, just a few thoughts. Very interesting stuff, but to be honest I don't think I'll be able to work on it anytime soon... I have a couple of modules & a lot of work to do on the Form Builder. That has to take priority.
All the best -
Ben
1. As long as the encryption key could be an easily-typed phrase, or even a txt file stored locally on authorized client machines that could be selected and uploaded when prompted per session, I think that would be a fine tradeoff. In a lot of public spheres, the emphasis (for better or worse) is on "taking steps" to secure data, rather than solving it all at once. Clearly it would be better to solve the problem outright, but incremental progress is often demanded even when it's short of a perfect solution. This is not a reflection on Form Tools; it's a reflection on us and other bureaucratic entities. Even if, say, a key is stored in a config file, and someone gains access to encrypted data, it's still a better position for me to be able to say, "look, online data is online data. We protect it as best we can and we encrypt it on the server, but security measures are not full-proof, and just as a person could break into your office and take something off of your desk, our server, despite our precautions, could be the target of a criminal act that results in compromised data." I guess what I'm arguing is that baby steps toward increased security are still of great utility to some organizations, even if they have limitations.
2. I'm not sure about the file storage outside of the web root issues, but if a user is logged into the Form Tools admin area, and the php files have read/write to a file outside of the web root, couldn't the files be grabbed for download by a php call, or would they still need to be written to a temp directory first? This is a question more than a suggestion... lol... I just don't know. I'm not concerned about losing the functionality of web links in, say, emails... where a straight http call won't be able to grab anything outside of the web root. I realize this is an issue... but maybe it could be an either/or if the "increased security module" is used for a particular form... where file access is only granted through the Form Tools admin area if increased security is selected.
3. As always... I'm very appreciative of the product so far and I look forward to its development moving forward.
am