I'm after setting up a small amount of 'secure' data on my web server that I can access and, preferably, modify via the internet using a browser. I.e. I basically want a web page (or a hierarchy of web pages) whose content is password protected. The ideal sort of interface would be a Wiki sort of approach - I think. Is there anything out there that can do this sort of thing? There are a number of PHP based password storage utilities but these are rather restictive of the format in which you can store data, I'd much prefer to be able to store free format text. There are two basic approaches as well:- Use client side decryption (i.e. Javascript or Java) so that only the encrypted data is sent over the internet. For me it wouldn't even be necessary to send the decryption code with the pages as I'm quite happy to install that on the two or three systems where I want to be able to view and modify the data. This approach has the advantage of not requiring an encrypted (https:) web server. User server side encrypt/decrypt and an https: server. This requires more effort to set up apache to do https: but I suspect is rather easier to do the actual encrypting and decrypting. In fact, given that the 'source' code lives on a fairly secure machine at home how vulnerable would the data be if it was just in a password protected Wiki? (i.e. the data itself isn't encrypted) Any and all ideas welcome. (well, except writing it down on a piece of paper and carrying that around with me) -- Chris Green (chrisisbd@leary.csoft.net)
On Mon, 2006-05-22 at 05:37 -0500, chrisisbd@leary.csoft.net wrote:
User server side encrypt/decrypt and an https: server. This requires more effort to set up apache to do https: but I suspect is rather easier to do the actual encrypting and decrypting.
It's not as much effort to set up as it seems, there are about a million guides on the interweb on how to do it. In fact certificate generation aside it's pretty much automatic on most modern distros. Depending on how sensitive the data is you can probably use self signed certs. This has the benefit that you can then format the data in anyway that works as a web page...just bolt a bit of authentication on the front and you are done.
In fact, given that the 'source' code lives on a fairly secure machine at home how vulnerable would the data be if it was just in a password protected Wiki? (i.e. the data itself isn't encrypted)
But the server would have to pass the data in plain text to your browser so that it can be rendered. So anyone sniffing the network would be able to see your data as you viewed the page. Unless you mean that you want to make the data available as downloadable files that are encrypted by another means themselves...but that would be very cumbersome.
On Mon, May 22, 2006 at 01:20:10PM +0100, Wayne Stallwood wrote:
On Mon, 2006-05-22 at 05:37 -0500, chrisisbd@leary.csoft.net wrote:
User server side encrypt/decrypt and an https: server. This requires more effort to set up apache to do https: but I suspect is rather easier to do the actual encrypting and decrypting.
It's not as much effort to set up as it seems, there are about a million guides on the interweb on how to do it. In fact certificate generation aside it's pretty much automatic on most modern distros. Depending on how sensitive the data is you can probably use self signed certs.
Yes, I just read one of them and it seems pretty straightforward.
This has the benefit that you can then format the data in anyway that works as a web page...just bolt a bit of authentication on the front and you are done.
Only if the computer it's on is itself secure against attack as the files will be in unencrypted form. There's no way I'd do this on anything except my own machine at home and even then I'm not totally convinced it's a good idea. So the connection is secure but is the data itself secure?
In fact, given that the 'source' code lives on a fairly secure machine at home how vulnerable would the data be if it was just in a password protected Wiki? (i.e. the data itself isn't encrypted)
But the server would have to pass the data in plain text to your browser so that it can be rendered. So anyone sniffing the network would be able to see your data as you viewed the page. Unless you mean that you want to make the data available as downloadable files that are encrypted by another means themselves...but that would be very cumbersome.
I was meaning an SSL connection to a password protected Wiki page (I think!). Going back to my original doubts the question is really whether one's data is more likely to be compromised by someone grabbing it in transit or by someone breeaking into the system where it is stored. It strikes me as unlikely that anyone will 'sniff' my communication with my home server - why would they? There's no way that they could determine that the data I'm transferring is useful. It's not at all the same as if I was using a web browser to access an internet banking site where there is a very large chance of signifcant data being transferred. On the other hand how secure is my home system itself against someone hacking into it and finding some files with passwords stored in them? It just seems odd to be paranoid about 'sniffing' but not to encrypt the data on the computer which seems to me just as (if not more) vulnerable. -- Chris Green (chrisisbd@leary.csoft.net)
On Mon, 2006-05-22 at 07:39 -0500, chrisisbd@leary.csoft.net wrote:
Only if the computer it's on is itself secure against attack as the files will be in unencrypted form. There's no way I'd do this on anything except my own machine at home and even then I'm not totally convinced it's a good idea. So the connection is secure but is the data itself secure?
Ok not sure how to do this but..... You could have an encrypted loopback filesystem that holds the "secure" bit of your www root. Apache then serves an SSL page prompting for a passphrase which it then uses to unlock the key to mount the secure filesystem which it immediately umounts as soon as the page is transmitted. That way not only would your machine have to be compromised, they'd have to either hack Apache (or the clever scripting you use to do this) to hold the passphrase or sit and wait until you next looked at that page so that they could quickly jump in to the mounted volume and grab the data. If you did this with encrypted files rather than a volume then even better (but I guess that's pretty close to your initial suggestion, but without the requirement to build client stuff) Now there's a project for someone.
It strikes me as unlikely that anyone will 'sniff' my communication with my home server - why would they? There's no way that they could determine that the data I'm transferring is useful. It's not at all the same as if I was using a web browser to access an internet banking site where there is a very large chance of signifcant data being transferred.
It's kind of hard to guess the most likely attack vector, but sniffing the network is a common one. For example any machine on the (presumably shared) network you are accessing the data from could have been compromised and may be being used to sniff traffic. Without SSL you have to consider the security of both your own system and the system you are accessing the data from as well as the security of the (public in this case) network the data is transmitted across. Sniffing a network isn't always targeted or even always of malicious intent. Ask yourself if you would be comfortable with a random admin (at your current location or at your ISP) seeing the data as they were using ethereal to diagnose a network problem at the same time you were accessing your pages ?
On the other hand how secure is my home system itself against someone hacking into it and finding some files with passwords stored in them?
This is true. But then you'd have to assume if your machine was sufficiently compromised that the data had been as well. For example even if you held the data in encrypted disks or containers there is the possibility that your machine could be rooted and a keylogger installed to watch you type the passphrase when you access this data locally. Apache in itself can be set up to be fairly hardened to an attack. Sure you could get caught out by a 0 day exploit or by miss-configuration but as you point out with the sniffing you're probably not that much of a target and it's generally only the older (and therefore hopefully patched) holes that get in the hands of script kiddies who will issue random attacks (and maybe fall upon your data as a result)
It just seems odd to be paranoid about 'sniffing' but not to encrypt the data on the computer which seems to me just as (if not more) vulnerable.
Not really, your computer is pretty much under your control (even more so because you are running Open Source Software) You are unlikely to be in a position to have the same control over the entire network you access the data from. Having the passwords held in an encrypted container is good for protecting them against someone who has a one time access to the machine (for example if it gets stolen) but I think in your case having the files served by a carefully configured installation of Apache (perhaps even locked down by a firewall so you can only get to it from certain locations) and the transmission protected by SSL probably offers security at least as good as the security on the systems those passwords protect.
On Mon, May 22, 2006 at 09:22:18PM +0100, Wayne Stallwood wrote:
On Mon, 2006-05-22 at 07:39 -0500, chrisisbd@leary.csoft.net wrote:
It strikes me as unlikely that anyone will 'sniff' my communication with my home server - why would they? There's no way that they could determine that the data I'm transferring is useful. It's not at all the same as if I was using a web browser to access an internet banking site where there is a very large chance of signifcant data being transferred.
It's kind of hard to guess the most likely attack vector, but sniffing the network is a common one. For example any machine on the (presumably shared) network you are accessing the data from could have been compromised and may be being used to sniff traffic. Without SSL you have to consider the security of both your own system and the system you are accessing the data from as well as the security of the (public in this case) network the data is transmitted across.
In fact the machines at both 'ends' are pretty secure, I'm not doing this from any old machine, it'll nearly always be either from home (where it's going to be hosted anyway) or from work which is behind a pretty strong firewall. Thus it's only the bit 'out in the internet' where the data is going to be visible if it's unencrypted. For the moment I've gone for a rather simple solution using an ssh connection to my home system and using vi (well vile actually) to view the files with the confidential data in them. I use the vi 'crypt' facility to encrypt the files, not *very* strong encryption but fairly OK. I've written a little wrapper script that allows me to pop this vi session up in a 'sidebar shaped' window adjacent to my browser so it's very convenient to use. It's not perfect or very beautiful to look at but I think it'll serve my needs. -- Chris Green (chrisisbd@leary.csoft.net)
participants (2)
-
chrisisbd＠leary.csoft.net -
Wayne Stallwood