On Sat, Oct 16, 2010 at 10:54 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote:
>
>>
>> And I'd like a pony. More seriously, "doesn't introduce additional
>> setup requirements" is an amazingly high bar for real world security.
>> The small vulnerabilities stack up to a far too common, vulnerable set
>> up that exists world wide.
>
> If you are willing to throw additional setup requirements into the mix, why
> not add an encrypted file system to hold your items that need to be secured.
> And use https with required client certificates as your transport.
Well, I was trying to make the point that very modest security efforts
get you big advantages. For example, activating that warning before
storing local passwords was very helpful. Disabling it in the default
config files would be better.
What you mention are interesting approaches, out of the reach of many
users but available. If you've got the resources to do that, fabulous.
For laptops, or Kerberos servers or GPG key repositories, I think
they're great. It does nothing in the still-quite-common NFS home
directory environments, or the "we need to be able to share files!!!"
environments where users do insist on having easy access.
Required SSL certificates is equivalent to SSH keys. Unless you have
some sort of agent to unlock them for dynamic use without constantly
typing a password or unlocking password, their primary advantage is
that they restrict the access from being based on the user's password,
especially their normal account password, and protect that access. And
unless there is some means to generate or recover that SSL certificate
for new hosts or debugging environments that can only access the
Subversion server, I detect some difficlties.
The problem there is that people do tend to want to have
single-sign-on andn account centralization, such as LDAP based account
management and back-end Kerberos management. As soon as you go there,
you block the use of this kind of private certificate based access.
I've actually been looking at Kerberized access to a subversion
management account, in order to support svn+ssh and allow the Kerberos
keys or LDAP to use Kerberos key, not password based access. The
difficulty is in restricting it to non-shell login on a user account,
much as the SSH public key command restrictions normally work. So I'm
looking at the "rssh" tool to help with that, by providing a
restricted shell for that svn+ssh account owner, but having difficulty
unwinding the user name from the connectoin for Subversion logging and
getting a good clean package.
There are lighter weight approaches. Simply publishing the default
configuration files for Subversion to disable password storage by
default, much as it used to be enabled for silent storage by default,
would be a good move: force people to *think* and do something
manually before they store passwords. The failure of the "make they
say yes" approach is borned out by the number of blank or poorly
written passwords accepted by local "passwd" files where it warns you,
but eventually allows you to store a poor or even blank password by
hitting "Enter" enough times. (Went thorugh that again this years:
demonstrated it for an NIS setup that the owner wasn't aware the users
had published blank passwords in.)
Received on 2010-10-17 05:45:56 CEST