Branko Čibej wrote:
> Mark Mielke wrote:
>
>> The Windows security model for Subversion satisfies me from a security
>> perspective. If a patch to support "in memory" key rings for GNOME
>> keyring were to be proposed for Subversion 1.6 and it was small, would
>> anybody here have objections to the patch on principle?
>>
>
> Not in principle, but I'm confused. Why would you like to use in-memory
> password store on Linux, but are satisfied with the way we store
> encrypted passwords to disk on Windows?
>
In the sense that Windows already keeps the Windows password in memory
while the user is logged in, and it is this password that is required to
decrypt the password "stored to disk". In our environment, the Windows
login password is the same as the Subversion password. The GNOME keyring
and KDE keyring are not as tightly controlled. There are problems with
both if the user password is used for the key ring (such as when the
user changes their password and the key rings stay locked with the old
password), and users can use a password with lower strength.
>> This sort of problem is often solved from the webpage using "cookies".
>> Instead of sending the user + password with each request, a cookie is
>> sent back to the client, and the client will send the cookie with
>> future requests. The cookie is a standard fixed life time data
>> structure that allows server side state to be maintained providing the
>> appearance of a "session" to the user. If they logged in 10 minutes
>> ago from the same environment, why should they need to login again?
>>
>
> Your definition of "security" must be somewhat different from mine if
> you propose to replace per-request authentication with cookies, which
> are notoriously susceptible to replay attacks.
>
Maybe, but I think not. Specifically, HTTP basic auth is just as easily
replayable as cookies, and cookies have a fixed life span. So captured
while in transit, cookies are safer than HTTP basic auth. Captured on
disk they're both protected by user permissions to the file on disk.
Passwords encrypted to disk are safer because they need the decrypt key.
Cookies stored to disk are safer because they are useless after enough
hours have passed. I don't see how cookies are "less secure" - I can see
how they are "more secure".
>> what level of technology does the US government believe the user
>> should be allowed to see?).
>>
>
> You'll have to explain a bit more why you think this community should
> cater to corporate interests that find it beneficial to indulge in
> big-brother policies according to whatever is the whim-of-the-day of
> some government that has no jurisdiction in most places where Subversion
> is used. If someone wants such a feature, they can damn well pay premium
> consulting fees for a customized Subversion server and keep this
> version-control project blissfully ignorant of local politics that do
> not concern the rest of us
Sure. However, you should accept that Subversion is not only for use by
non-corporations, and many Subversion users exist in Canada or the
United States and are legally bound to abide by the laws of the country
(whether "free" or not - it's just harder to fine a "free" project for
violating these rules). You will remember the RSA/PGP battles I assume?
The government has a big stick if it wants to use it. Open source means
that such a corporation could make a change and contribute back to the
community such that it is not a fork. This allows the most people to
benefit from the feature.
I'm not asking you to implement country of origin rules in Subversion.
I'm asking if you have a legitimate complaint against presenting
Subversion accesses as a "session" using the traditional model of
"cookies", allowing the session object to store whatever data is
required to implement resource-based authorization.
Cheers,
mark
--
Mark Mielke <mark_at_mielke.cc>
Received on 2008-11-02 21:36:46 CET