On Monday, January 13, 2003, at 07:28 PM, Benjamin Pflugmann wrote:
> On Mon 2003-01-13 at 14:02:10 -0600, Ben Collins-Sussman wrote:
>> <firstname.lastname@example.org> writes:
>>> I just discovered that the svn client is caching passwords by
>>> This seems like a huge security hole, especially since it isn't
>>> that it is being done [...]
>> I'm not following your logic. It's a security hole because users
>> don't know it's happening by default?
> Yes. It's called "unsafe defaults" and is the what the most active
> worms targetting Microsoft Windows exploit mainly - several years
> after the deficiency is well-known, fixes are long available and
> everybody should know.
> (I am well aware that the setting we are talking about does not have
> the same reach.)
>> (What would happen if every user read about it in documentation first?
>> Would it still be a security hole?)
> Yes. Because humans are lazy. If a setting has security implications,
> good software should encourage the user to make an active, reasonably
> informed decision for case she wants to use the less safe setting.
> IMHO, it cannot and should not enforce that, but it should help to do
> the Right Thing.
> No, it wouldn't be a security hole anymore if you could be sure that
> every user reads the documentation and changes the settings to the
> safer one if she is unsure what to use or does not care. Notice the
> paradox with the latter part?
How bout we just have the command line client warn them the first time
we ask for and cache a password, right before asking for the password
(in addition to moving passwords to ~/.subversion):
"Warning: The password you type will be saved to disk and reused for
later authentication to this repository. Please read the documentation
if you do not understand the security implications of this. This
message will not reappear for this repository.
Would that make you feel better about the whole thing?
The user would know what is happening, and that if they are unsure
whether to care, it points them to the documentation (which presumably
will spell out what will happen so they can decide whether they care).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jan 14 08:17:47 2003