From: Aristotle Pagaltzis Date: 10:32 on 02 Jan 2008 Subject: Subversion and credentials If you stopped reading after the first word in the subject, you took a pretty sensible decision. Anyway, so: Subversion only stores auth credentials you supply on the command line if it used them successfully. If the server refused a request for some reason, it won't store the credentials. If the server doesn't *ask* for credentials, Subversion won't use them to begin with, and you cannot make it. This means you cannot deposit credentials ahead of time if you only need them for some actions -- say, because the repository you're working with only requires credentials at commit but not for checkout. Notably absent is any form of credentials management. You can specifically ask it not to use any cached credentials when it otherwise would, but the only supported form of managing stored credentials is to delete files inside the ~/.subversion/auth/ subdirectories. Which is reasonably doable without the aid of tools, because you can easily inspect these files: Subversion stores *everything*, and that includes the passwords, in pure, untarnished clear text. A marvel. That anyone ever thought this fuming pile of manure is great. Regards,
From: Martin Ebourne Date: 10:56 on 02 Jan 2008 Subject: Re: Subversion and credentials Aristotle Pagaltzis <pagaltzis@xxx.xx> wrote: > Which is reasonably doable without the aid of tools, because you > can easily inspect these files: Subversion stores *everything*, > and that includes the passwords, in pure, untarnished clear text. I say better clear text than rot-13. Unless it has passwords properly encrypted with a master password, and associated session management (which would be nice, but as far as I know no-one has implemented this for svn yet), clear text seems to be the best choice. Cheers, Martin.
From: book Date: 11:12 on 02 Jan 2008 Subject: Re: Subversion and credentials On Wed, Jan 02, 2008 at 10:56:27AM +0000, Martin Ebourne wrote: > Aristotle Pagaltzis <pagaltzis@xxx.xx> wrote: >> Which is reasonably doable without the aid of tools, because you >> can easily inspect these files: Subversion stores *everything*, >> and that includes the passwords, in pure, untarnished clear text. > > I say better clear text than rot-13. Unless it has passwords properly > encrypted with a master password, and associated session management (which > would be nice, but as far as I know no-one has implemented this for svn > yet), clear text seems to be the best choice. Firefox and friends use Base64 for storing passwords.
From: Martin Ebourne Date: 11:31 on 02 Jan 2008 Subject: Re: Subversion and credentials book@xxxx.xxx wrote: >> I say better clear text than rot-13. Unless it has passwords properly >> encrypted with a master password, and associated session management (which >> would be nice, but as far as I know no-one has implemented this for svn >> yet), clear text seems to be the best choice. > > Firefox and friends use Base64 for storing passwords. Yes, that's worse. Absolutely no more secure, but harder to decode a password in your head if you (or a relative in my case) happen to forget one. Cheers, Martin.
From: demerphq Date: 11:44 on 02 Jan 2008 Subject: Re: Subversion and credentials On 02/01/2008, Martin Ebourne <lists@xxxxxxx.xx.xx> wrote: > book@xxxx.xxx wrote: > >> I say better clear text than rot-13. Unless it has passwords properly > >> encrypted with a master password, and associated session management (which > >> would be nice, but as far as I know no-one has implemented this for svn > >> yet), clear text seems to be the best choice. > > > > Firefox and friends use Base64 for storing passwords. > > Yes, that's worse. Absolutely no more secure, but harder to decode a > password in your head if you (or a relative in my case) happen to > forget one. Its not a security thing IMO. Its a peace-of-mind thing. Any syadmin can easily *deliberately* find out a users password in such a system, cleartext or base64 or rot13. But what Base64 does that rot13 barely does which cleartext does not is prevent sysadmins from accidentally seeing a bunch of passwords when they didnt intend to. Which IMO is a good thing. So if you arent going to store them securely storing them in a obfu form is at least better than storing them in cleartext. Opening a config file to a system where the passwords are stored in cleartext is quite hateful IMO. Yves
From: Martin Ebourne Date: 12:02 on 02 Jan 2008 Subject: Re: Subversion and credentials demerphq <demerphq@xxxxx.xxx> wrote: > Its not a security thing IMO. Its a peace-of-mind thing. Any syadmin > can easily *deliberately* find out a users password in such a system, > cleartext or base64 or rot13. But what Base64 does that rot13 barely > does which cleartext does not is prevent sysadmins from accidentally > seeing a bunch of passwords when they didnt intend to. Which IMO is a > good thing. > > So if you arent going to store them securely storing them in a obfu > form is at least better than storing them in cleartext. Opening a > config file to a system where the passwords are stored in cleartext is > quite hateful IMO. Depends on your point of view I guess. I would consider any password =20 stored unencrypted on a shared system as potentially compromised. =20 Hence I would only ever store passwords in that way if I didn't care =20 that they were compromised, so I wouldn't care if a sysadmin did read =20 the password. All other passwords are stored securely or retyped each time they are =20 a required (that includes several of my svn passwords). My rules are simple: - if I wouldn't tell someone the password if they asked, then - I wouldn't trust anyone not to go and find it out, and - it needs to be stored securely. Cheers, Martin.
From: demerphq Date: 12:29 on 02 Jan 2008 Subject: Re: Subversion and credentials On 02/01/2008, Martin Ebourne <lists@xxxxxxx.xx.xx> wrote: > demerphq <demerphq@xxxxx.xxx> wrote: > > Its not a security thing IMO. Its a peace-of-mind thing. Any syadmin > > can easily *deliberately* find out a users password in such a system, > > cleartext or base64 or rot13. But what Base64 does that rot13 barely > > does which cleartext does not is prevent sysadmins from accidentally > > seeing a bunch of passwords when they didnt intend to. Which IMO is a > > good thing. > > > > So if you arent going to store them securely storing them in a obfu > > form is at least better than storing them in cleartext. Opening a > > config file to a system where the passwords are stored in cleartext is > > quite hateful IMO. > > Depends on your point of view I guess. I would consider any password > stored unencrypted on a shared system as potentially compromised. > Hence I would only ever store passwords in that way if I didn't care > that they were compromised, so I wouldn't care if a sysadmin did read > the password. > > All other passwords are stored securely or retyped each time they are > a required (that includes several of my svn passwords). > > My rules are simple: > > - if I wouldn't tell someone the password if they asked, then > - I wouldn't trust anyone not to go and find it out, and > - it needs to be stored securely. I agree with all of this pretty much. Yet... I really don't want to see passwords, even insecure ones, accidentally. Yves
From: Peter da Silva Date: 13:25 on 02 Jan 2008 Subject: Re: Subversion and credentials > Yet... I really don't want to see passwords, even insecure ones, > accidentally. xor them with "Squeamish Ossifrage".
From: Michael G Schwern Date: 00:21 on 03 Jan 2008 Subject: Re: Subversion and credentials demerphq wrote: > Yet... I really don't want to see passwords, even insecure ones, accidentally. Hooray for SSH agent forwarding! Now somebody's going to tell me why that's hateful.
From: Peter da Silva Date: 00:47 on 03 Jan 2008 Subject: Re: Subversion and credentials On 2008-01-02, at 18:21, Michael G Schwern wrote: > demerphq wrote: >> Yet... I really don't want to see passwords, even insecure ones, >> accidentally. > > Hooray for SSH agent forwarding! > > Now somebody's going to tell me why that's hateful. Um. Let me think. Detached screen sessions? OK, weak, but I gotta respond to a challenge.
From: Phil Pennock Date: 11:34 on 02 Jan 2008 Subject: Re: Subversion and credentials On 2008-01-02 at 12:12 +0100, book@xxxx.xxx wrote: > On Wed, Jan 02, 2008 at 10:56:27AM +0000, Martin Ebourne wrote: > > Aristotle Pagaltzis <pagaltzis@xxx.xx> wrote: > >> Which is reasonably doable without the aid of tools, because you > >> can easily inspect these files: Subversion stores *everything*, > >> and that includes the passwords, in pure, untarnished clear text. > > > > I say better clear text than rot-13. Unless it has passwords properly > > encrypted with a master password, and associated session management (which > > would be nice, but as far as I know no-one has implemented this for svn > > yet), clear text seems to be the best choice. > > Firefox and friends use Base64 for storing passwords. Unless you set a master password, in which case this goes into the NSS stuff as an PKCS11 software-based implementation where the master password is used to unlock them. -Phil
From: Phil Pennock Date: 11:08 on 02 Jan 2008 Subject: Re: Subversion and credentials On 2008-01-02 at 11:32 +0100, Aristotle Pagaltzis wrote: > Which is reasonably doable without the aid of tools, because you > can easily inspect these files: Subversion stores *everything*, > and that includes the passwords, in pure, untarnished clear text. > > A marvel. > > That anyone ever thought this fuming pile of manure is great. This is fairly common for authenticated repository systems, that I've seen. I mean, it's not like ~/.cvspass is anything other than fool-yourself obfuscation. Perforce uses environment variables, which aren't particularly secure (hello, ps(1)) and yet it's used in SOX environments. *sigh* svn does at least let you not store passwords, by using an authentication mechanism not based on passwords. I do not use svn+ssh but with pubkey auth I'd be surprised if any passwords had to be stored. Instead I use GSSAPI. It's just a matter of telling Apache use use mod_auth_kerb and serving over https; the libneon subversion client library explicitly disables Negotiate auth unless the access protocol is https. I've assumed that this is to avoid having to write layer wrapping and to just be able to rely upon servers not asking for GSSAPI session protection layers when already using TLS. The svn client tools, cadaver, they all Just Work with GSSAPI. Safari, Firefox after enabling it, yup (and don't need to use the https variant of the site). Not sure if MSIE does, I think that I didn't bother since I wasn't using domain signin but MIT Kerberos for Windows so that I could have tokens for whatever remote sites I had accounts for. I suspect MSIE would work, if you used this in a Windows Domain setup. Untested, but I vaguely recall that MSIE introduced Negotiate so I'd for once be surprised if MS did get this wrong. Now, there's no special support for this server-side, so your authenticated id is just the fully-qualified user@DOMAIN but that's at least The Right Thing. I get around it with AuthzSVNAccessFile which defines the groups and defining a group for the same name as 'user' which contains 'user' and 'user@DOMAIN'. Of course, you need to have unique DNS for Kerberos to be happy. That's why I use IPv6 and why svn.spodhuis.org is IPv6-only. But there's /svn, /ksvn, /viewvc and /kviewvc on that. (Two modules are publicly readable, if anyone's interested). So I could see why libneon chickened out but that doesn't mean that I don't have some resigned vague hate for the lack of stackable IO layers in the standard C libraries; I need to look closer at sfio. I had some ... irritation when I finally figured out the https restriction and then had to wander over my svn:externals references changing the URLs. *sigh* -Phil
Generated at 10:25 on 16 Apr 2008 by mariachi