You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexis Huxley <ah...@gmx.net> on 2006/10/20 14:07:04 UTC
using (or coding support for) encrypted passwords
Is there any way to use encrypted passwords in <repo>/conf/passwd
instead of plaintext?
Secondly, is there any way for the server (apache+mod_dav_svn and
svnserve) to 'force' the client not to cache svn:// and http://
repo access passwords in plaintext?
(Clearly a user could install their own client, so perhaps the word
'force' should be 'ask' instead.)
If either of these are not possible, then ...
Are these even desirable features? If not, then why not?
And if they are desirable, then could someone please offer pointers
to the places that need to be changed? I would guess as a minimum:
- client side: after reading password from tty, write it
encrypted to ~/.subversion
- server side: after reading the plain text password passed
across the network, encrypt and compare with the (encrypted)
passwd in <repo>/conf/passwd
- both sides: add support for some sort of
I-already-authenticated-myself mechanism akin to CVS's
I am aware svn+ssh:// and https:// not storing plain text passwords,
but in preliminary performance tests, we see that svn is somewhat
faster than http is a lot faster than svn+ssh is somewhat faster than
https; speed may be one of the criteria critical to user acceptance
for this migration project.
I've searched tigris/issues/book/google and also asked on the 'user'
list but not turned up anything.
Any advice appreciated! Thanks!
Alexis Huxley
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: using (or coding support for) encrypted passwords
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Oct 23, 2006 at 11:55:56AM +0200, Alexis Huxley wrote:
> > > Is there any way to use encrypted passwords in <repo>/conf/passwd
> > > instead of plaintext?
> And for the server side? Is any reason for not encrypting the passwords
> there? If not, is this something planned? Is it a bite-size problem?
>
This is partly the same as the client problem -- there's no global
Keychain-like service that we can rely on.
Additionally, though we could use {ROT13, CryptoAPI, Keychain} storage
on the server side, we'd need a utility to manage those passwords.
The 'right' answer might well be to use a SASL-enabled server - you can
then use whatever secure password storage that you have available.
Regards,
Malcolm
Re: encrypted /conf/passwd? coming soon/easy to implement?
Posted by Marcus Rueckert <da...@web.de>.
On 2006-10-26 10:00:26 +0000, Alexis Huxley wrote:
> On 2006-10-23, Alexis Huxley <ah...@gmx.net> wrote:
>
> > ... for the server side ... Is any reason for not encrypting the passwords
> > there? If not, is this something planned? Is it a bite-size problem?
>
> Nobody answered this so I thought I'd just give the thread a little
> poke before I block svn:// access.
>
> Is this something planned or easy to implement?
if you are already worried about the server side. do you know that
passwords are stored on the client side in plain text too?
even for http(s) based access. only svn+ssh doesnt suffer from that.
the explaination is pretty simple: CRAM-MD5 as used in the svn://
protocol requires the plain text password on both sides. but on the
other hand it gives you secure password transport on the wire. without
the need of SSL/TLS.
hope this helps
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
encrypted /conf/passwd? coming soon/easy to implement?
Posted by Alexis Huxley <ah...@gmx.net>.
On 2006-10-23, Alexis Huxley <ah...@gmx.net> wrote:
> ... for the server side ... Is any reason for not encrypting the passwords
> there? If not, is this something planned? Is it a bite-size problem?
Nobody answered this so I thought I'd just give the thread a little
poke before I block svn:// access.
Is this something planned or easy to implement?
Thanks!
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: using (or coding support for) encrypted passwords
Posted by Alexis Huxley <ah...@gmx.net>.
> > Is there any way to use encrypted passwords in <repo>/conf/passwd
> > instead of plaintext?
>
> http://svn.haxx.se/dev/archive-2006-10/0508.shtml
>
> This is basically just like ~/.cvspass, i.e., not actual encryption.
And for the server side? Is any reason for not encrypting the passwords
there? If not, is this something planned? Is it a bite-size problem?
> The alternative is to interface to a system-level password management
> daemon which, presumably, needs to be "unlocked" with a password, to
> decrypt its stored data, when the user starts his session. The
Ok, indeed with a bit more googling I found
http://svn.haxx.se/dev/archive-2004-11/0596.shtml which suggests
the same thing.
Thanks!
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: using (or coding support for) encrypted passwords
Posted by Peter Samuelson <pe...@p12n.org>.
[Alexis Huxley]
> Is there any way to use encrypted passwords in <repo>/conf/passwd
> instead of plaintext?
http://svn.haxx.se/dev/archive-2006-10/0508.shtml
This is basically just like ~/.cvspass, i.e., not actual encryption.
But the client-side hash verification scheme you propose is pretty much
equivalent, since in both cases anyone who gains access to
~/.subversion can authenticate with the server. The only advantage to
a one-way hash is the case of "perhaps I used the same password for
amazon.com".
The alternative is to interface to a system-level password management
daemon which, presumably, needs to be "unlocked" with a password, to
decrypt its stored data, when the user starts his session. The
advantage is that Subversion doesn't have to reinvent secure password
storage - it's a complex job much better left to someone else. No need
for Subversion to know about Blowfish, USB flash drives, or smart card
readers. Subversion already supports such facilities on Windows and
Mac OS X; there is talk of supporting more such daemons, such as GNOME
Keyring, kwallet, and quintuple-agent.
> Secondly, is there any way for the server (apache+mod_dav_svn and
> svnserve) to 'force' the client not to cache svn:// and http:// repo
> access passwords in plaintext?
No, there is in general no way for the server to control client
configuration. What you want is in ~/.subversion/config, in the [auth]
section, "store-passwords = no".
Pushing client configuration from the server is one of those things a
lot of people request, but nobody has produced a design. It also has
security implications - you don't want the server to control very much
of the client configuration, as there is no reason for a random client
to trust a random server (svn is often used in an "anonymous" situation
where the client user does not, in fact, have any particular way of
knowing that the server administrator is trustworthy).