I want to have some respository where I can store passwords, account info and other information and have it be remotely available (I’ll host it on my own server). I have the following restrictions:
Needs to have remote-connection capability (so I can use it from a laptop externally, desktops internally, etc)
Only needs to work with linux but definitely from openSUSE (at least as client)
Remote connection must be secure and not unlock info on server and send unencrypted to remote
Open Source only
Must be capable of working both in GUI and non-GUI environment
I’m not sure this is a good solution. If I want to edit anything in the file (from a remote computer), I’d have download it, decrypt, edit, re-encrypt and replace. That’s not the best solution.
> I’m not sure this is a good solution. If I want to edit anything in the
> file (from a remote computer), I’d have download it, decrypt, edit,
> re-encrypt and replace. That’s not the best solution.
Not necessarily. You can use text based tools to work inside the ssh
shell, without downloading any file. You can also use graphical tools,
but these need more bandwidth.
Kleopatra, for instance, is a nice KDE GUI can encrypt/decrypt files,
handle keys, etc. I have never used it over a remote session, because
normally it assumes you have an “agent” to cache passwords, something
you wold have on a full session.
Seahorse is the equivalent in Gnome. It handles the keys, but not
encryption/decryption of files.
I’m not saying that this is the easiest method; but I do say that it is
the one with safer encryption.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On 05/01/2013 12:26 AM, 6tr6tr wrote:
> I’d have download it, decrypt, edit,
> re-encrypt and replace. That’s not the best solution.
as convenience increases, security decreases–only you can decide how
much security you want and therefore how much convenience you are
willing to give up…
another way to say that: so far, one can’t have computing both easy and secure at the same time.
hasn’t MS been proving that over and over (and over) since 1975?
That’s not the issue here. The inconvenience actually leaves a bigger risk for insecurity and errors/problems. Imagine:
User on remote computer downloads “sometext.asc”
User decrypts the text (which causes it to create a new “sometext” document)
User changes the text and re-encrypts
User accidentally uploads the decrypted version to the server (this is a risk)
OR
User accidentally re-encrypts with the wrong key, and after uploading has locked everyone else out of the document
OR
A race condition starts when users “A” and “B” have downloaded the document separately (at the same time), added new data to it separately and save it back to the server (one after the other, the second overwrites the first’s changes)
> That’s not the issue here. The inconvenience actually leaves a bigger
> risk for insecurity and errors/problems. Imagine:
>
> 1. User on remote computer downloads “sometext.asc”
Download is not strictly necessary, you can work on the remote file
directly. If you do, then the client machine must be secured.
Then, I mentioned a GUI that automates part of the process, mistakes are
not that easy, then.
> 3. User accidentally re-encrypts with the wrong key, and after
> uploading has locked everyone else out of the document
For that he needs have several keys prepared.
You may combine with a versioning system (cvs, svn) and thus protect
about wrong changes.
> OR
> 4. A race condition starts when users “A” and “B” have downloaded the
> document separately (at the same time), added new data to it separately
> and save it back to the server (one after the other, the second
> overwrites the first’s changes)
That’s not something you asked for in your OP, you never said “two
users”
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
