On Sat, Oct 16, 2010 at 10:54 AM, Les Mikesell <lesmikes...@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.)
