Looking for Subversion server-side SSH key manager - Security

This is a discussion on Looking for Subversion server-side SSH key manager - Security ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Looking for Subversion server-side SSH key manager

  1. Looking for Subversion server-side SSH key manager

    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.

    The remaining more securable approaches are basically SSH based: the
    "svn+ssh" approach normally has a designated SSH user on the server,
    with SSH public keys stored under a particular account name on the
    server (http://svnbook.red-bean.com/en/1.0/ch06s03.html), with the SSH
    keys set to restrict the operations usable by that shared account.

    That's fine, but leaves the problem of "how do authenticated users
    change or add new keys"? So I'm looking for an SSH key management
    tool. Ideally a simple web GUI to allow a set of authenticated users
    (such as Active-Directory or Kerberos based password web
    authentication) to be able to set new SSH keys. Upload is fine: but
    given the presence of Windows users and the interactions of Pageant
    generated SSH keys, I think that downloading the private keys would be
    easier, and would allow forcing the user to have a passphrase based
    key at least to start out with.

    Does anyone have such a tool already built, or something close to it?


  2. Re: Looking for Subversion server-side SSH key manager

    Zawartość nagłówka ["Followup-To:" comp.os.linux.security.]
    On 16.06.2007, Nico 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.

    --
    Secunia non olet.
    Stanislaw Klekot

  3. Re: Looking for Subversion server-side SSH key manager

    On 16 Jun, 12:34, "Stachu 'Dozzie' K."
    wrote:
    > Zawartość nagłówka ["Followup-To:" comp.os.linux.security.]
    > On 16.06.2007, Nico 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!!!! Numerous tools, such as Internet Explorer,
    Firefox, and ssh-agent, store keys encrypted on local disk that are
    unlocked by the user 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, 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. 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..


  4. Re: Looking for Subversion server-side SSH key manager

    On 16.06.2007, Nico wrote:
    > On 16 Jun, 12:34, "Stachu 'Dozzie' K."
    > wrote:
    >> Zawartość nagłówka ["Followup-To:" comp.os.linux.security.]
    >> On 16.06.2007, Nico 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

  5. Re: Looking for Subversion server-side SSH key manager

    On 16 Jun, 13:31, "Stachu 'Dozzie' K."
    wrote:

    > 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.



    Let's surmmarize. I'm already using ssh-agent. That's what I was
    looking for a decent ool to work with, so that users can submit or
    generate their SSH keys via a decent webform, instead of via various
    random means currently in place. That's about as good as we're going
    to get in the Subversion world, until and unless some other local
    piece of key handling is implemented. This is why Sourceforge uses SSH
    keys.

    You may go and read the Subversion book on "client credential
    caching". It's englightening: by default, almost every Subversion
    client in the UNIX or Linux world stores the passwords in plain-text.
    The Windows ones generally don't.

    Thre are computational and legal issues incorporating encryption into
    public software products: there are serious code-base and stability
    issues as well in a project as large and popular as Subversion, so I
    don't see any other straightforward approach coming down the pike.
    There are conceptually interesting things that could occur with public/
    private key handling and svnserve, but I don't have the skill to write
    that myself.

    Far, far, far too many Subversion implementations are based on typical
    login techniques where the user authenticates with their system
    passwords. It's exceedingly common: at every one of the half dozen or
    so commercial implementations I've done of Subversion source control
    services, the client or users first wanted to use their own login
    names and system passwords, and I had to explain the local password
    security issue. It's nasty, nasty, nasty business, and they don't
    generally realize they're doing it.

    In fact, the local password storage for Linux/UNIX users should
    probably be turned *off* by default, to force people to notice that
    they're doing it.


  6. Re: Looking for Subversion server-side SSH key manager

    On 17.06.2007, Nico wrote:
    > On 16 Jun, 13:31, "Stachu 'Dozzie' K."
    > wrote:
    >
    >> 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.

    >
    >
    > Let's surmmarize. I'm already using ssh-agent. That's what I was
    > looking for a decent ool to work with, so that users can submit or
    > generate their SSH keys via a decent webform, instead of via various
    > random means currently in place. That's about as good as we're going
    > to get in the Subversion world, until and unless some other local
    > piece of key handling is implemented. This is why Sourceforge uses SSH
    > keys.
    >
    > You may go and read the Subversion book on "client credential
    > caching". It's englightening: by default, almost every Subversion
    > client in the UNIX or Linux world stores the passwords in plain-text.
    > The Windows ones generally don't.


    Of course they do. They just store it in some kind of Base64 or
    UUEncode, so one can't read it directly. Otherwise they would simply
    annoy user with password prompt each time he access the remote
    repository. And *that's* what you can't understand so far.

    --
    Secunia non olet.
    Stanislaw Klekot

  7. Re: Looking for Subversion server-side SSH key manager

    On 17 Jun, 10:15, "Stachu 'Dozzie' K."
    wrote:
    > On 17.06.2007, Nico wrote:
    >
    >
    >
    >
    >
    > > On 16 Jun, 13:31, "Stachu 'Dozzie' K."
    > > wrote:

    >
    > >> 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.

    >
    > > Let's surmmarize. I'm already using ssh-agent. That's what I was
    > > looking for a decent ool to work with, so that users can submit or
    > > generate their SSH keys via a decent webform, instead of via various
    > > random means currently in place. That's about as good as we're going
    > > to get in the Subversion world, until and unless some other local
    > > piece of key handling is implemented. This is why Sourceforge uses SSH
    > > keys.

    >
    > > You may go and read the Subversion book on "client credential
    > > caching". It's englightening: by default, almost every Subversion
    > > client in the UNIX or Linux world stores the passwords in plain-text.
    > > The Windows ones generally don't.

    >
    > Of course they do. They just store it in some kind of Base64 or
    > UUEncode, so one can't read it directly. Otherwise they would simply
    > annoy user with password prompt each time he access the remote
    > repository. And *that's* what you can't understand so far.


    OK: who is this "they" you're pointing to? The SSH keys that I've
    recommended as the way to do this, and that I'm trying to integrate
    better upstream tools for? Or are you saying "Windows security is
    poor, so I'll use even worse security for my Linux clients! That'll
    show them how smart we are!"

    The passwords do not have to be in clear text. Kerberos and SSH and
    SSL showed basic approaches for this *years*, even decades ago for
    SSH. And I'm looking for servers-side tools to help with the key
    management, which is the missing keystone for doing drop-in solutions.

    Let's be clear. While storing the passwords with poor encryption is
    poor security, leaving them lying around in plain text is worse, and
    it's encouraged to be common place because people like you seem to
    think there's no point in even trying. So the tools are not being used
    safely, even though they can be, and people are basically leaving
    their passwords in plain text on their home drives and on their backup
    tapes because they can't be bothered to do things right.


  8. Re: Looking for Subversion server-side SSH key manager

    On 20.06.2007, Nico wrote:
    > On 17 Jun, 10:15, "Stachu 'Dozzie' K."
    > wrote:
    >> On 17.06.2007, Nico wrote:
    >>
    >>
    >>
    >>
    >>
    >> > On 16 Jun, 13:31, "Stachu 'Dozzie' K."
    >> > wrote:

    >>
    >> >> 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.

    >>
    >> > Let's surmmarize. I'm already using ssh-agent. That's what I was
    >> > looking for a decent ool to work with, so that users can submit or
    >> > generate their SSH keys via a decent webform, instead of via various
    >> > random means currently in place. That's about as good as we're going
    >> > to get in the Subversion world, until and unless some other local
    >> > piece of key handling is implemented. This is why Sourceforge uses SSH
    >> > keys.

    >>
    >> > You may go and read the Subversion book on "client credential
    >> > caching". It's englightening: by default, almost every Subversion
    >> > client in the UNIX or Linux world stores the passwords in plain-text.
    >> > The Windows ones generally don't.

    ^^^^^^^^^^^^^^^^
    >> Of course they do. They just store it in some kind of Base64 or
    >> UUEncode, so one can't read it directly. Otherwise they would simply
    >> annoy user with password prompt each time he access the remote
    >> repository. And *that's* what you can't understand so far.

    >
    > OK: who is this "they" you're pointing to?


    Try guessing.

    > The passwords do not have to be in clear text. Kerberos and SSH and
    > SSL showed basic approaches for this *years*, even decades ago for
    > SSH.


    What do you mean: "have to *be* in clear text"? To be stored in clear
    text? To be transfered over the net in clear text? I don't know if you
    realize that in Kerberos the *clear text* password is used to encrypt
    ticket from authentication server, so it *have* to be stored in form
    that allows using it as a key (it may be intermediate hash, though, from
    key derivation algorithm). And SSH, on the other side, transfers the
    password in clear text over a previously set up encrypted channel.

    > And I'm looking for servers-side tools to help with the key
    > management, which is the missing keystone for doing drop-in solutions.
    >
    > Let's be clear. While storing the passwords with poor encryption is
    > poor security, leaving them lying around in plain text is worse,


    But you don't understand. In Windows' case *it's not* a poor encryption.
    It's simply not an encryption, when the only protection is a secret
    storage format. *That's* what I'm talking about. And such
    (non)protection is worse than clear text, because some people (you as an
    example) confuse it with real but weak protection.

    --
    Secunia non olet.
    Stanislaw Klekot

  9. Re: Looking for Subversion server-side SSH key manager

    Stachu 'Dozzie' K. wrote:
    > Zawartość nagłówka ["Followup-To:" comp.os.linux.security.]
    > On 16.06.2007, Nico 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?


    Well, in a hash to start with.

    > 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.


    What do you thing something like PGP uses ?

    > "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.


    Windows stores passwords hashed. The subversion client stores them
    *unencrypted* and *unhashed*.



    Igmar

  10. Re: Looking for Subversion server-side SSH key manager

    On 27.06.2007, Igmar Palsenberg wrote:
    > Stachu 'Dozzie' K. wrote:
    >> Zawartość nagłówka ["Followup-To:" comp.os.linux.security.]
    >> On 16.06.2007, Nico 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?

    >
    > Well, in a hash to start with.


    OK. How then would you like to use it in svn protocol or with HTTPs with
    basic authentication?

    >> 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.

    >
    > What do you thing something like PGP uses ?


    You mean, protecting password with password? You would end up with
    prompting user for password for each checkin/checkout. Situation similar
    to not storing password 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.

    >
    > Windows stores passwords hashed.


    What passwords does Windows store hashed? Passwords to websites (IE)?
    Passwords to e-mail (OE, MSO)? Or what else? Or maybe you're talking
    about passwords to user's system accounts, what is slightly different
    from Subversion as the password doesn't need to be sent anywhere just
    after getting it from the user?

    --
    Secunia non olet.
    Stanislaw Klekot

  11. Re: Looking for Subversion server-side SSH key manager

    On 27 Jun, 15:14, "Stachu 'Dozzie' K."
    wrote:

    > You mean, protecting password with password? You would end up with
    > prompting user for password for each checkin/checkout. Situation similar
    > to not storing password at all.


    OK, guys? This has jumped way off my original topic of SSH public key
    management on the server side for Subversion use with svn+ssh.

    But yes, there are reasonably graceful ways to do "public-key"
    encryption where the file with the private key is stored locally,
    encrypted, and is dynamically unlocked for use. That unlocked key is
    stored only in RAM, and sometimes protected by fascinating layers of
    authentication and protection, but it does not reside locally on disk.
    This prevents most casual theft by people with access to backup tapes,
    NFS shares, etc. In this case, ssh-agent is well documented and
    supported for managing and unlocking encrypted SSH keys for active
    session use. There are hundreds, if not thousands, of web references
    on exactly how to do this, including the Subversion manual itself.

    Please take a look at ssh-agent, the handling of encrypted SSL keys,
    and even at tools like Kerberos (which is an underlying authentication
    technology behind Active Directory). It's a very common and respected
    technique, including with major software repositories such as
    Sourceforge. It's also part of why I find you handwaving that "but you
    have to have the key somewhere!", and your corresponding lack of
    concern that it's being kept locally, on disk, in plain text, to be a
    very foolish and dangerous practice.

    There's just no excuse for it.


  12. Re: Looking for Subversion server-side SSH key manager

    Stachu 'Dozzie' K. wrote:

    > OK. How then would you like to use it in svn protocol or with HTTPs with
    > basic authentication?


    By letting the server hash the received password. Basic authentication
    is a different issue. It isn't an easy task, I admit. This is one of the
    reasons I use SVN over SSH.

    >>> 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.

    >> What do you thing something like PGP uses ?

    >
    > You mean, protecting password with password? You would end up with
    > prompting user for password for each checkin/checkout. Situation similar
    > to not storing password at all.


    No, by using public key authentication. The same thing for example SSH uses.

    >>> "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.

    >> Windows stores passwords hashed.

    >
    > What passwords does Windows store hashed? Passwords to websites (IE)?
    > Passwords to e-mail (OE, MSO)? Or what else? Or maybe you're talking
    > about passwords to user's system accounts, what is slightly different
    > from Subversion as the password doesn't need to be sent anywhere just
    > after getting it from the user?


    I'm talking about system accounts. Storing passwords in plain is a bad
    thing.



    Igmar


+ Reply to Thread