John Szakmeister wrote:
> Wincrypt is based off of CryptProtectData(), which encrypts based on your
> logon credentials. You can read more about it here:
> <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptprotectdata.asp>
>
> FWIW, I've reset several people's passwords on my network, and none of them
> have ever been prompted to re-enter a password.
Thanks, I'll read up on it, but if you can reset their password and they
can still read the encrypted data, doesn't that mean it is broken?
FG wrote:
> The reason I am asking is because you potentially have two separate
> levels of authentication here. The first level is when you hit your web
> server for the SSL connection. If you built your SSL certificate with a
> challenge password, it will require that you enter that password just to
> get use of the SSL connection. This is neither part of the Subversion
> client caching of any password mechanism nor part of the authz_svn
> authentication layer. It's still one level to high.
>
> Humor me....If you try to hit any other non-protected part of your
> website on https://, does it still ask for a password? If so, then you
> do have a challenge password on your SSL certificate, and that
> configuration is not part of the Subversion authenication caching
> mechanism. The password being asked for is to begin any sort of SSL
> transaction. In a "standard" scenario, the client is able to actually
> create the connection and then the subsystems (authz_svn / basic auth)
> will ask for their own authentication.
It most definately is not using the http basic or other conventional
authentication. I had to jump though a few hoops in the apache config
to get it to treat the connection as logged in based on the CN field of
the client certificate. Because of this, if I import the certificate
into a web browser and try to access the repository, I am not prompted
for a password. I have been meaning for a while to run openssl to
remove the password from the client certificate file but have not gotten
around to it.
I had allways thought that svn could not cache the password I used to
protect the certificate file because that was handled by neon, but svn
DOES cache the password. I can delete my auth files and it will
recreate them and with the old version of svn that did not use wincrypt,
I could see the plain text password used to tie the client certificate
file.
What I don't get is why does svn save the password, but not use it
later? That seems like a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 17 19:19:53 2005