Re: Looking for Subversion server-side SSH key manager
- From: "Stachu 'Dozzie' K." <dozzie@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 16 Jun 2007 12:31:07 +0000 (UTC)
On 16.06.2007, Nico <nkadel@xxxxxxxxx> wrote:
On 16 Jun, 12:34, "Stachu 'Dozzie' K."
<doz...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Zawartość nagłówka ["Followup-To:" comp.os.linux.security.]
On 16.06.2007, Nico <nka...@xxxxxxxxx> wrote:
Morning, folks:
Subversion has long had a fundamental flaw in its Linux or UNIX
command line clients: like CVS, from which it evolved, it stores
passwords locally in the clear on the client side. Using SSH or HTTPS
authentication does not address this. Many good clients, such as
TortoiseSVN, use the local operating system's password storage, but
for CygWin or Linux or UNIX clients, it's an amazingly fundamental
security problem.
Erm. How would you like to store Subversion password? Subversion must be
able to read it. If the password is encrypted in any way, Subversion
must ask user for decryption key. Otherwise everything could be stored
as plain text, since "encryption with publicly known key" is no
encryption at all. "Windows password storage", whatever are you talking
about, is affected exactly by the same facts. It's just a matter of
reading appropriate object from the system.
I believe I just said. It's an issue I've raised before in the
Subversion developer's and discussion lists. The Subversion client
must be able to access it, true. That *does not* mean it has to be
stored in plain text!!!!
You mean, it should bother user with password prompt each time it access
the repository? Then simply disable storing credentials.
Numerous tools, such as Internet Explorer,
Firefox, and ssh-agent, store keys encrypted on local disk that are
unlocked by the user
LOL. I always thought that IE and Firefox store remembered passwords in
a manner that allows reading them if you can read the IE/FF config,
without need to run browser itself. That is, it's just a protection
against one's younger sister.
at login or software activation time and are not
available to any schmuck who can read a backup tape or convince an NFS
server that he's actually got the same login name as the software
owner,
I'd like to point that NFS protocol doesn't have an idea about
username/password.
plug in a USB stick at an unattended console and read the
user's stored SVN configuration settings, etc., etc., etc.
"Reading appropriate objects from the system" should require access to
RAM, not to the backup tapes or the disk from a botnetted machine or
shared home directories in a corporate network.
Of course an access to backup tapes, except when you have an encrypted
home directory.
No one but the key
owner should be able to extract the key, even if they have access to
the user's files: this is a serious basic of network security..
Let's summarize. You claim that you know how to store passwords on the
disk, so user don't need to enter his password each time he access some
resource, right? And someone who has an access to the whole filesystem,
but doesn't know user's password, can't read this password? We aren't
talking about home encrypted with LUKS or Windows' encryption or
something similar, since in that case storing passwords in plain text is
similarly secure.
Am I right?
--
Secunia non olet.
Stanislaw Klekot
.
- Follow-Ups:
- References:
- Prev by Date: Re: Looking for Subversion server-side SSH key manager
- Next by Date: Re: Details regarding computer forensic
- Previous by thread: Re: Looking for Subversion server-side SSH key manager
- Next by thread: Re: Looking for Subversion server-side SSH key manager
- Index(es):
Relevant Pages
|
|