On 19 October 2010 02:17, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
> <stephen.alan.connolly_at_gmail.com> wrote:
>
>> Add a capability called "keyringenabled" to Subversion and now Nico
>> will probably be much happier... but of course he doesn't trust his
>> users so he cannot trust that they report "keyringenabled"
>> correctly... but he might be pragmatic enough to accept that as a
>> compromise.
>
> Now, now. Don't put words in my mouth. I'm concerned about obvious and
> possible and documented attack vectorrs: passwords in cleartext are
> one of them. Eventually, any idiot can write a script that stores
> passwords in clear-text to mishandle local passwords or passphrase
> protected keys, but putting the capability in as the default behavior
> is extremely poor practice and should not be supported by default
> configuration or behavior.
>
> I don't think that "keyring enabled" is sufficient. A protocol shift
> that *requires* a better protected password and blocks the currently
> unsecured local password storage access would be interesting, I
> thought the gpg-agent changes would do that, but Stefan pointed out
> the flaws, dang it.
>
the svn client would only report keyringenabled if the keyring was
enabled for password storage and the client was configured to not
store plaintext... perhaps "plaintextpasswordstoragedisabled" is a
better name for the feature.
> svn+ssh actually works reasonably well: it just doesn't suppor the
> "use my normal login password" approach to managing user access.
>
>> and that's probably a feature we could add in 1.6.14 with only minor
>> effort (most of the work being deciding what the feature name should
>> be ;-) )
>>
>> -Stephen
>
> If it could require the client to actually *use* the keyring, I could
> see it. How would we support that for TortoiseSVN clients?
>
Exposing the feature would not in an of itself force the client to use
the keyring, but it would allow the server to have a start-commit hook
that blocked a commit if the user had plaintext password storage
enabled...
so ok, if I have a client with plaintext storage enabled and I attempt
a commit, there is a possibility that my password will get stored in
plaintext on my system, but the start-commit hook can send back the
message saying something like "Your client is storing passwords in
plaintext, which is against the policy for this server. To commit
your changes you need to configure your client to securely store the
password or else use --no-auth-cache on the command line. See
http://internal-wiki-page-link for details."
The wiki page can describe how to remove the plaintext passwords and
how to configure a keyring.
So you would not get completely secure by default, but one could have
the start-commit.tmpl have code to show how to secure the system, and
you would have what you require to ensure the system is secure going
forward.
-Stephen
Received on 2010-10-19 09:47:03 CEST