You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Malcolm Rowe <ma...@farside.org.uk> on 2006/10/18 09:29:56 UTC
[PATCH] Obfuscate auth info
Hello list,
Background for people not at the summit: We discussed the
regularly-reported problem today about the Subversion client storing
plaintext auth info on Unix, and the response that elicits from users.
We all agreed that scrambling the password wouldn't add any security at
all, but we also had a vague consensus that as long as we made sure that
users didn't think the passwords _were_ encrypted, obfuscating them in
some way might not be objectionable, since not doing so aggravates some
people.
Obfuscating passwords solves two problems:
1. It prevents accidental disclosure (e.g. 'grep -r pony ~', if your
password is 'i-want-a-pony', your non-malicious sysadmin reading
it by mistake, that kind of thing).
2. It stops people complaining that "HEY SUBVERSION IS STORING MY PASSWORD IN
THE CLEAR!!1".
I thought I might take a look at how easy it was to do this, and it
turns out to be really easy, hence the attached patch. I'm far too
tired to actually write a proper log message at the moment, but in the
meantime the code's here if we decide that we want it.
[I want to make it clear that if we decide that we aren't interested in
this feature, I'm quite happy to drop the code in the bin. This is not
an attempt to drive the feature in by saying "Hey, I did all this work,
you've gotta commit it".]
The patch adds a new type of simple provider that just base64's the
password and adds a warning to make it clear that the auth info is not
encrypted. The resulting auth file looks like this:
K 7
comment
V 252
WARNING! This file contains a version of your password that has been
slightly scrambled to avoid accidental disclosure.
The scrambled password is NOT ENCRYPTED in any way, and so you should
take the same care of it as you would your regular password.
K 8
passtype
V 10
obfuscated
K 8
password
V 16
aGFycnlzc2VjcmV0
K 15
svn:realmstring
V 59
<svn://localhost:3691> c5ddb573-1120-0410-ba9b-f45616950c8b
K 8
username
V 5
harry
END
Regards,
Malcolm
Re: [PATCH] Obfuscate auth info
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Oct 19, 2006 at 01:44:04AM -0700, David Anderson wrote:
> +1, see Karl's explanation on this. He explains very plainly why this
> is a win in just about any situation. I'd just like to note that we
> are not treating this as an excuse to not investigat password manager
> for !(win32 || OSX). But until that investigation takes place, this is
> a silencer for the recurring complaints the users@ list has had for
> years.
>
I agree, though not strongly enough to push this feature through myself
(I'm +0 on it - my only original interest was in seeing how hard it was
to code).
I agree with almost all of your review comments, though I'll leave
producing an updated patch to someone who really wants to argue for the
change.
A few notes from that review:
> >
> >-/* The password type used by the windows simple auth provider, passed
> >- into simple_first_creds_helper and simple_save_creds_helper. */
> >-static const char windows_crypto_type[] = "wincrypt";
> >-
>
> Why is this removed? Are we replacing "wincrypt" with this 'universal'
> obfuscator?
>
No, that was a stray hunk in this patch - it comes from r22024.
> >+
> >+/* Get cached obfuscated credentials from the simple provider's cache. */
>
> Should this read "from the obfuscated provider's cache" ?
>
No, I don't think so. The wincrypt, keychain, and now obfuscated simple
providers all use the plaintext simple provider's cache (that is, they
store the data in svn.simple/...).
> Good job. As an aside, I motion that the simple auth provider be
> altered to use the obfuscated set_password. That way, the cache is
> progressively updated to obfuscated storage when touched. The change
> should be a one-or-so-liner.
>
I thought of that, but that would unfortunately be a layering violation
- there's no reason to assume that the client wants to use the
obfuscating provider (and if they don't, they won't be able to read back
out the password they've stored).
However, I would really like a solution to this problem in general,
because the Keychain and wincrypt providers are also affected by this --
unless someone cleans out all the unencrypted auth data, we're not more
secure than 1.0.
Regards,
Malcolm
Re: [PATCH] Obfuscate auth info
Posted by David Anderson <da...@natulte.net>.
On 10/18/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> Background for people not at the summit: We discussed the
> regularly-reported problem today about the Subversion client storing
> plaintext auth info on Unix, and the response that elicits from users.
>
> We all agreed that scrambling the password wouldn't add any security at
> all, but we also had a vague consensus that as long as we made sure that
> users didn't think the passwords _were_ encrypted, obfuscating them in
> some way might not be objectionable, since not doing so aggravates some
> people.
+1, see Karl's explanation on this. He explains very plainly why this
is a win in just about any situation. I'd just like to note that we
are not treating this as an excuse to not investigat password manager
for !(win32 || OSX). But until that investigation takes place, this is
a silencer for the recurring complaints the users@ list has had for
years.
> K 7
> comment
> V 252
> WARNING! This file contains a version of your password that has been
> slightly scrambled to avoid accidental disclosure.
>
> The scrambled password is NOT ENCRYPTED in any way, and so you should
> take the same care of it as you would your regular password.
<pedantic>
The warning could maybe do with a little extra formatting. Something
along the lines of:
******************** WARNING ********************
This file contains passwords. They have been slightly scrambled so
that people reading over your shoulder cannot read them.
However, they are NOT ENCRYPTED in any way. Anyone who gets hold of
this file and is serious about it can recover your password in
seconds. Take the necessary care to protect this file from being
stolen.
Just a little more verbose and flashy, to get to the joe end user more.
> Index: subversion/include/svn_auth.h
> ===================================================================
> --- subversion/include/svn_auth.h (revision 21975)
> +++ subversion/include/svn_auth.h (working copy)
> @@ -701,6 +701,26 @@ svn_auth_get_keychain_simple_provider(sv
>
> #endif /* DARWIN || DOXYGEN */
>
> +/**
> + * Create and return @a *provider, an authentication provider of type @c
> + * svn_auth_cred_simple_t that gets/sets information from the user's
> + * ~/.subversion configuration directory. Allocate @a *provider in
> + * @a pool.
> + *
> + * This is like svn_client_get_simple_provider(), except that the
> + * provider will lightly scramble the password before storing it to
> + * disk so that accidental disclosure is harder.
Accidental disclosure becoming "harder" is not the right term imo. "to
avoid accidental disclosure" maybe?
> + *
> + * This provider does @em not encrypt the data in any meaningful way.
> + * To ensure that users are aware of this, it will also add a warning to
> + * the auth file.
> + *
> + * @since New in 1.5.
> + */
> +void
> +svn_auth_get_obfuscated_simple_provider(svn_auth_provider_object_t **provider,
> + apr_pool_t *pool);
> +
> /** Create and return @a *provider, an authentication provider of type @c
> * svn_auth_cred_username_t that gets/sets information from a user's
> * ~/.subversion configuration directory. Allocate @a *provider in
> Index: subversion/libsvn_subr/simple_providers.c
> ===================================================================
> --- subversion/libsvn_subr/simple_providers.c (revision 21975)
> +++ subversion/libsvn_subr/simple_providers.c (working copy)
> @@ -23,6 +23,7 @@
> /*** Includes. ***/
>
> #include <apr_pools.h>
> +#include <apr_base64.h>
> #include "svn_auth.h"
> #include "svn_error.h"
> #include "svn_utf.h"
> @@ -39,10 +40,12 @@
> #define SVN_AUTH__AUTHFILE_USERNAME_KEY "username"
> #define SVN_AUTH__AUTHFILE_PASSWORD_KEY "password"
> #define SVN_AUTH__AUTHFILE_PASSTYPE_KEY "passtype"
> +#define SVN_AUTH__AUTHFILE_COMMENT_KEY "comment"
>
> #define SVN_AUTH__SIMPLE_PASSWORD_TYPE "simple"
> #define SVN_AUTH__WINCRYPT_PASSWORD_TYPE "wincrypt"
> #define SVN_AUTH__KEYCHAIN_PASSWORD_TYPE "keychain"
> +#define SVN_AUTH__OBFUSCATED_PASSWORD_TYPE "obfuscated"
>
>
> /* A function that stores PASSWORD (or some encrypted version thereof)
> @@ -537,17 +540,12 @@ svn_auth_get_simple_prompt_provider
>
> #ifdef WIN32
> #include <wincrypt.h>
> -#include <apr_base64.h>
>
> /* The description string that's combined with unencrypted data by the
> Windows CryptoAPI. Used during decryption to verify that the
> encrypted data were valid. */
> static const WCHAR description[] = L"auth_svn.simple.wincrypt";
>
> -/* The password type used by the windows simple auth provider, passed
> - into simple_first_creds_helper and simple_save_creds_helper. */
> -static const char windows_crypto_type[] = "wincrypt";
> -
Why is this removed? Are we replacing "wincrypt" with this 'universal'
obfuscator?
> /* Dynamically load the address of function NAME in PDLL into
> PFN. Return TRUE if the function name was found, otherwise
> FALSE. Equivalent to dlsym(). */
> @@ -877,3 +875,117 @@ svn_auth_get_keychain_simple_provider(sv
> }
>
> #endif /* SVN_HAVE_KEYCHAIN_SERVICES */
> +
> +/*-----------------------------------------------------------------------*/
> +/* Obfuscating simple provider, stores obfuscated passwords in the creds */
> +/* file. This does not add any security at all, but does mitigate */
> +/* against accidental disclosure. */
> +/*-----------------------------------------------------------------------*/
"but does help to avoid accidental disclosure."
> +
> +/* Store an obfuscated (base-64) version of PASSWORD in CREDS, together with
> + a note to warn users that the password is not encrypted.
> +
> + This function implements password_set_t. */
> +static svn_boolean_t
> +obfuscated_password_set(apr_hash_t *creds,
> + const char *realmstring,
> + const char *username,
> + const char *password,
> + svn_boolean_t non_interactive,
> + apr_pool_t *pool)
> +{
> + size_t len = strlen(password);
> + char *obfuscated = apr_palloc(pool, apr_base64_encode_len(len));
> + apr_base64_encode(obfuscated, password, len);
> + if (!simple_password_set(creds, realmstring, username, obfuscated,
> + non_interactive, pool))
> + return FALSE;
> +
> + const char * warning =
> + _("WARNING! This file contains a version of your password that has been\n"
> + "slightly scrambled to avoid accidental disclosure.\n\n"
> + "The scrambled password is NOT ENCRYPTED in any way, and so you should\n"
> + "take the same care of it as you would your regular password.");
> + apr_hash_set(creds, SVN_AUTH__AUTHFILE_COMMENT_KEY, APR_HASH_KEY_STRING,
> + svn_string_create(warning, pool));
> +
> + return TRUE;
> +}
> +
> +/* Retrieve an obfuscated password from CREDS.
> + This function implements password_get_t. */
> +static svn_boolean_t
> +obfuscated_password_get(const char **password,
> + apr_hash_t *creds,
> + const char *realmstring,
> + const char *username,
> + svn_boolean_t non_interactive,
> + apr_pool_t *pool)
> +{
> + const char *obfuscated;
> + char *plaintext;
> + size_t len;
> +
> + if (!simple_password_get(&obfuscated, creds, realmstring, username,
> + non_interactive, pool))
> + return FALSE;
> +
> + len = apr_base64_decode_len(obfuscated);
> + plaintext = apr_palloc(pool, len);
> + apr_base64_decode(plaintext, obfuscated);
> + *password = plaintext;
> +
> + return TRUE;
> +}
> +
> +/* Get cached obfuscated credentials from the simple provider's cache. */
Should this read "from the obfuscated provider's cache" ?
> +static svn_error_t *
> +obfuscated_simple_first_creds(void **credentials,
> + void **iter_baton,
> + void *provider_baton,
> + apr_hash_t *parameters,
> + const char *realmstring,
> + apr_pool_t *pool)
> +{
> + return simple_first_creds_helper(credentials,
> + iter_baton, provider_baton,
> + parameters, realmstring,
> + obfuscated_password_get,
> + SVN_AUTH__OBFUSCATED_PASSWORD_TYPE,
> + pool);
> +}
> +
> +/* Save obfuscated credentials to the simple provider's cache. */
> +static svn_error_t *
> +obfuscated_simple_save_creds(svn_boolean_t *saved,
> + void *credentials,
> + void *provider_baton,
> + apr_hash_t *parameters,
> + const char *realmstring,
> + apr_pool_t *pool)
> +{
> + return simple_save_creds_helper(saved, credentials, provider_baton,
> + parameters, realmstring,
> + obfuscated_password_set,
> + SVN_AUTH__OBFUSCATED_PASSWORD_TYPE,
> + pool);
> +}
> +
> +static const svn_auth_provider_t obfuscated_simple_provider = {
> + SVN_AUTH_CRED_SIMPLE,
> + obfuscated_simple_first_creds,
> + NULL,
> + obfuscated_simple_save_creds
> +};
> +
> +
> +/* Public API */
> +void
> +svn_auth_get_obfuscated_simple_provider(svn_auth_provider_object_t **provider,
> + apr_pool_t *pool)
> +{
> + svn_auth_provider_object_t *po = apr_pcalloc(pool, sizeof(*po));
> +
> + po->vtable = &obfuscated_simple_provider;
> + *provider = po;
> +}
> Index: subversion/libsvn_subr/cmdline.c
> ===================================================================
> --- subversion/libsvn_subr/cmdline.c (revision 21975)
> +++ subversion/libsvn_subr/cmdline.c (working copy)
> @@ -362,6 +362,8 @@ svn_cmdline_setup_auth_baton(svn_auth_ba
> svn_auth_get_keychain_simple_provider(&provider, pool);
> APR_ARRAY_PUSH(providers, svn_auth_provider_object_t *) = provider;
> #endif
> + svn_auth_get_obfuscated_simple_provider(&provider, pool);
> + APR_ARRAY_PUSH(providers, svn_auth_provider_object_t *) = provider;
> svn_auth_get_simple_provider(&provider, pool);
> APR_ARRAY_PUSH(providers, svn_auth_provider_object_t *) = provider;
> svn_auth_get_username_provider(&provider, pool);
Good job. As an aside, I motion that the simple auth provider be
altered to use the obfuscated set_password. That way, the cache is
progressively updated to obfuscated storage when touched. The change
should be a one-or-so-liner.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/18/06, Alex Holst <a...@mongers.org> wrote:
> Please don't do this. Whilte Such a change may stop users complaining,
> it won't stop subversion from storing the password (effectivly) in the
> clear.
>
> None of this will stop attackers. And, while the change may indeed stop
> users from complaning, you'll simply end up with security professionals,
> like me, complaining that subversion "tricks" users into not
> investigating alternatives to plain text passwords.
>
> To quote Thomas Ptacek (replace 'SAN' with 'svn'): "The lack of
> superficial (or worse, complicated) security mechanisms forces operators
> to confront the fact that SAN security requires network architecture
> support." -- http://www.matasano.com/log/203/radioactive/
>
> Users who complain about the risk of plain text passwords need to be
> educated and motivated to move to ssh keys, certificates or full disk
> encryption (or switch to an OS that provides a safe method of storing
> passwords).
For those not at the summit, my opinion is much the same as Alex's.
However, I am willing to be -0 against this patch if the warning is
present. I still think it's a bad idea, but I realize that I was the
only one in the room who didn't like it. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting C. Michael Pilato (cmpilato@collab.net):
> > None of this will stop attackers. And, while the change may indeed stop
> > users from complaning, you'll simply end up with security professionals,
> > like me, complaining that subversion "tricks" users into not
> > investigating alternatives to plain text passwords.
>
> Did you miss the part of the patch which writes the following to each
> auth storage file?
No, I read it. I don't feel it changes my argument. Users will still
think they are more "secure" because they can't read the password, so
they think others can't either.
Please don't commit this change.
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by "C. Michael Pilato" <cm...@collab.net>.
Alex Holst wrote:
> Quoting Malcolm Rowe (malcolm-svn-dev@farside.org.uk):
>> Obfuscating passwords solves two problems:
>> 1. It prevents accidental disclosure (e.g. 'grep -r pony ~', if your
>> password is 'i-want-a-pony', your non-malicious sysadmin reading
>> it by mistake, that kind of thing).
>> 2. It stops people complaining that "HEY SUBVERSION IS STORING MY PASSWORD IN
>> THE CLEAR!!1".
>
> Please don't do this. Whilte Such a change may stop users complaining,
> it won't stop subversion from storing the password (effectivly) in the
> clear.
>
> None of this will stop attackers. And, while the change may indeed stop
> users from complaning, you'll simply end up with security professionals,
> like me, complaining that subversion "tricks" users into not
> investigating alternatives to plain text passwords.
Did you miss the part of the patch which writes the following to each
auth storage file?
WARNING! This file contains a version of your password that has been
slightly scrambled to avoid accidental disclosure.
The scrambled password is NOT ENCRYPTED in any way, and so you should
take the same care of it as you would your regular password.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting Ph. Marek (philipp.marek@bmlv.gv.at):
> > It is *not true* that any password storage mechanism is insecure ...
> > Mac's keychain, or Window's FS encryption certificate, can only be
> > unlocked with the user's password -- that's done exactly once when the
> > user logs in, the session keys are stored in secure memory (presumably)
> > and go away when the user logs out.
> Which is similar to the ssh-agent problem I mentioned.
> Walk to the machine when the user has gone to fetch a coffee, and you're
> in ...
This has nothing to do with obfuscation of auth data, but I would hope
that anyone organisation who uses single sign-on type technologies have
told their users they will be fired if they leave their workstation
unlocked when it's unattended.
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Thursday 19 October 2006 10:11, Branko Čibej wrote:
> AFAIK, since at least Windows 2000, the LanMAN hash is no longer stored
> in the registry by default. Guess why.
>
> It is *not true* that any password storage mechanism is insecure ...
> Mac's keychain, or Window's FS encryption certificate, can only be
> unlocked with the user's password -- that's done exactly once when the
> user logs in, the session keys are stored in secure memory (presumably)
> and go away when the user logs out.
Which is similar to the ssh-agent problem I mentioned.
Walk to the machine when the user has gone to fetch a coffee, and you're
in ...
I have to admit that it depends on the security you need, and what you want to
protect against. YMMV.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH] Obfuscate auth info
Posted by "L. Wayne Johnson" <wa...@zk.com>.
>>
>> It is *not true* that any password storage mechanism is insecure ...
>> Mac's keychain, or Window's FS encryption certificate, can only be
>> unlocked with the user's password -- that's done exactly once when the
>> user logs in, the session keys are stored in secure memory (presumably)
>> and go away when the user logs out.
>>
>> -- Brane
>>
I am sure you all are aware of this
http://sourceforge.net/projects/ophcrack. This should let you know exactly
how secure your Windows password really is...
I ran it on my laptop and it took about 500 seconds to figure out my 8
character password (Windows XP with service pack 2.) The password uses
random numbers and letters with mixed case. I am not using any of the
updated tables that allow more difficult passwords to be cracked. You can
setup your system so that this is not possible (or at least more difficult.)
I wouldn't even hazard to guess how many people on this list are aware that
this auditing tool even exists ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Branko Čibej <br...@xbc.nu>.
Ph. Marek wrote:
> On Wednesday 18 October 2006 23:57, Alex Holst wrote:
>
>> I claim that, regardless of what warning might appear in the password
>> file, obfuscated auth data will result in many users/admins/managers
>> thinking it takes a lot of effort to recover their password. Anyone who
>> has ever dealt with users or managers knows I'm not kidding.
>>
>> Which is greater? The cost of educating users who post to the mailing
>> list about clear text passwords or the very likely possibility that
>> a user will shoot themselves in the foot because they didn't feel a need
>> to investigate ssh keys, certs or kerberos auth?
>>
>
> I'd like to throw in that even on OS with a "password storage mechanism" (like
> WinNT, WinXP etc) that stores a *cleartext* equivalent in the registry.
> If you say "connect this windows share, remember my password" the password is
> stored as a LanMAN hash - which is *exactly* what is needed to connect to the
> remote site, and can be used for this purpose.
>
AFAIK, since at least Windows 2000, the LanMAN hash is no longer stored
in the registry by default. Guess why.
It is *not true* that any password storage mechanism is insecure ...
Mac's keychain, or Window's FS encryption certificate, can only be
unlocked with the user's password -- that's done exactly once when the
user logs in, the session keys are stored in secure memory (presumably)
and go away when the user logs out.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting Ph. Marek (philipp.marek@bmlv.gv.at):
> I'd like to throw in that even on OS with a "password storage mechanism" (like
> WinNT, WinXP etc) that stores a *cleartext* equivalent in the registry.
> If you say "connect this windows share, remember my password" the password is
> stored as a LanMAN hash - which is *exactly* what is needed to connect to the
> remote site, and can be used for this purpose.
Simply not true. While there may be some brain dead applications left
for Windows that try to store passwords themselves, a full API has
existed for years that allow applications to safely manage passwords in
a properly protected store. See chapter 9 af "Writing Secure Code 2nd",
which covers this is great detail, or, look for the DPAPI documentation on
MSDN.
As far as I know, the identical facility in MacOS X is just as safe as the
one in Windows.
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Wednesday 18 October 2006 23:57, Alex Holst wrote:
> I claim that, regardless of what warning might appear in the password
> file, obfuscated auth data will result in many users/admins/managers
> thinking it takes a lot of effort to recover their password. Anyone who
> has ever dealt with users or managers knows I'm not kidding.
>
> Which is greater? The cost of educating users who post to the mailing
> list about clear text passwords or the very likely possibility that
> a user will shoot themselves in the foot because they didn't feel a need
> to investigate ssh keys, certs or kerberos auth?
I'd like to throw in that even on OS with a "password storage mechanism" (like
WinNT, WinXP etc) that stores a *cleartext* equivalent in the registry.
If you say "connect this windows share, remember my password" the password is
stored as a LanMAN hash - which is *exactly* what is needed to connect to the
remote site, and can be used for this purpose.
*Every* authentication information which needs no user interaction has to be
stored in a way that *everyone with physical access* can acquire it.
If the machine has an encrypted harddisk (with password query or smartcard
access), then *that's* the major block in the pathway of an attacker - not
some obfuscation or storage mechanism which is not known by the average
person.
Storing the passwords obfuscated has one (big!) advantage: supporters who look
at the screen (where the original user has just dumped the authentication
storage) have it *much* easier *not* to remember the password just seen!
So, to make my point (slightly oversimplyfied):
*Every* password storage is insecure. If you have an agent running (which I'd
recommend), then you'll have to protect that machine from your little boy
getting to it and pressing the wrong keys
(http://news.bbc.co.uk/1/hi/england/lincolnshire/5379930.stm).
Please make the passwords unreadable in the file, and print a *BIG BIG*
warning that *EVERY* storing of passwords may be a security risk.
If you like, you could even print a message to STDERR if an automatic
authentication happened - although that would have to be tuneable via some
config setting.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/18/06, Max Bowsher <ma...@ukf.net> wrote:
> Question: If you feel so strongly about it, are you also campaigning for
> the trivial obfuscation to be removed from CVS?
Because CVS is a pile of mud? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Alan Barrett <ap...@cequrux.com>.
I'd like the cleartext passwords to be obfuscated.
On Wed, 18 Oct 2006, Alex Holst wrote:
> I claim that, regardless of what warning might appear in the password
> file, obfuscated auth data will result in many users/admins/managers
> thinking it takes a lot of effort to recover their password. Anyone who
> has ever dealt with users or managers knows I'm not kidding.
What if the warning said: "To undo the trivial scrambling, just run
the following sed/awk/perl/python script: <insert script here>."
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Peter Lundblad <pl...@google.com>.
Justin Erenkrantz writes:
> On 10/19/06, Alex Holst <a...@mongers.org> wrote:
> > You are kind of proving my point here, Karl. If storing a plain text
> > password is enough to keep users from migrating to subversion,
> > obfuscation of auth data is clearly perceived (by some decision makers)
> > as a security benefit at some level, even when it's not one.
>
> +1.
>
> During the conversation at the summit, I raised the point that having
> users complain about their passwords being seen is a *good* thing as
> it forces them to think about the problem seriously. If we obfuscate
> it, then it means that it'll be out of sight and out of mind. I don't
> view that as a good thing at all. -- justin
>
+1.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/19/06, Alex Holst <a...@mongers.org> wrote:
> You are kind of proving my point here, Karl. If storing a plain text
> password is enough to keep users from migrating to subversion,
> obfuscation of auth data is clearly perceived (by some decision makers)
> as a security benefit at some level, even when it's not one.
+1.
During the conversation at the summit, I raised the point that having
users complain about their passwords being seen is a *good* thing as
it forces them to think about the problem seriously. If we obfuscate
it, then it means that it'll be out of sight and out of mind. I don't
view that as a good thing at all. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Bruce Elrick <br...@elrick.ca>.
On 10/19/06, Alex Holst <a...@mongers.org> wrote:
>
> Quoting Karl Fogel (kfogel@red-bean.com):
> > In the meantime, obfuscating the auth data seems like an unambiguous
> > win to me:
> >
> > 1. Organizations that currently don't adopt Subversion because of
> > this (and there are some) will now be willing to adopt it. More
> > users is good. They understand that it's still cleartext, but
> > they want to at least avoid accidental compromises.
>
> You are kind of proving my point here, Karl. If storing a plain text
> password is enough to keep users from migrating to subversion,
> obfuscation of auth data is clearly perceived (by some decision makers)
> as a security benefit at some level, even when it's not one.
I think that's a straw man. The users are not complaining about the
password being easily gotten by bad guys, they are complaining about it not
being easy for good guys to avoid seeing the password. This is meant to
allow the latter and makes no claims to prevent the former.
Bruce
--
Bruce Elrick
bruce@elrick.ca
bruce.elrick@gmail.com
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting Karl Fogel (kfogel@red-bean.com):
> In the meantime, obfuscating the auth data seems like an unambiguous
> win to me:
>
> 1. Organizations that currently don't adopt Subversion because of
> this (and there are some) will now be willing to adopt it. More
> users is good. They understand that it's still cleartext, but
> they want to at least avoid accidental compromises.
You are kind of proving my point here, Karl. If storing a plain text
password is enough to keep users from migrating to subversion,
obfuscation of auth data is clearly perceived (by some decision makers)
as a security benefit at some level, even when it's not one.
If users are willing to complain about storing plain text passwords,
they should be just as willing to complain about obfuscated passwords,
because their concern is probably not "accidental compromises" but the
fact that the password is available at all.
However, because of the perceived benefit of obfuscation, users likely
won't complain or consider alternate authentication methods.
My point is, many users will consider "obfuscation" and "encryption" to
be the same, regardless of what warnings you put into the password
cache.
('recovery' in my previous mail referred to an attacker's ability to
determine a user's password, not the user themselves recovering their
password.)
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
[...]
> Anyway, I give an enthusiastic +1 to the change!
Well and I give it an enthusiastic -1. I trust Alex's arguments, they
match with what my intuition tells me (although IANASU). Just because
users (and admins) are mostly suckers where security is concerned, that
doesn't give us license to give them stuff to suck on.
Uh ... whatever the correct inversion of the idiom is.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Karl Fogel <kf...@red-bean.com>.
On 10/18/06, Alex Holst <a...@mongers.org> wrote:
> Quoting Max Bowsher (maxb1@ukf.net):
> > Alex Holst wrote:
> > > I beg of you: Please don't introduce this obfuscation to auth data in
> > > Subversion.
> >
> > Question: If you feel so strongly about it, are you also campaigning for
> > the trivial obfuscation to be removed from CVS?
>
> No. First, my customers don't use CVS, so I don't really care. Secondly,
> I suspect it would be much harder to remove features introduced many
> years ago in a dated scm tool than it would be to prevent the
> introduction of questionable obfuscation features in a newer, modern scm
> tool.
>
> I also think a mistake made years ago shouldn't be made again.
There is a separate change proposed (at the Summit) to not store
effectively-cleartext authn data by default. That still has to be
discussed here, of course, and it's independent of this obfuscation
change, but it's yet another step in the right direction.
In the meantime, obfuscating the auth data seems like an unambiguous
win to me:
1. Organizations that currently don't adopt Subversion because of
this (and there are some) will now be willing to adopt it. More
users is good. They understand that it's still cleartext, but
they want to at least avoid accidental compromises.
2. Users are no more likely to think that their data is truly
encrypted after this change than before, thanks to the warning.
Sure, most people will never see the warning, but anyone who
looks at their password will also see the warning, which is all
that matters. (Yes, the few people who use 'grep' to look for
their password won't find it and may go away thinking that
therefore it's not stored in cleartext. I'm willing to live
with this slight "regression".)
3. We will stop wasting users@ list time with this issue every few
weeks.
> I claim that, regardless of what warning might appear in the password
> file, obfuscated auth data will result in many users/admins/managers
> thinking it takes a lot of effort to recover their password. Anyone who
> has ever dealt with users or managers knows I'm not kidding.
>
> Which is greater? The cost of educating users who post to the mailing
> list about clear text passwords or the very likely possibility that
> a user will shoot themselves in the foot because they didn't feel a need
> to investigate ssh keys, certs or kerberos auth?
These two paragraphs look like they're talking about the same thing, but
really they're talking about different things.
Easy password recovery was never a design goal of the current system
anyway, it's just an unintentional consequence of not obfuscating the
passwords. And it is unrelated to the phenomenon of a user mistakenly
thinking that their password is stored securely; the latter is highly unlikely
to happen because of the warning comment in the password file.
(I couldn't quite tell if you were implying some sort of connection between
ease of password recovery and users mistakenly assuming secure storage,
but I didn't see any other way to read those two paragraphs.)
Anyway, I give an enthusiastic +1 to the change!
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Samay <ge...@hotmail.com>.
-1 for change to "obfuscation auth info" for what its worth.
It is widely understood that security by obscurity does not work .. same
goes for suggestions about obfuscation .. thats getting into a very wrong
trap ...
If security folks at corporate do not accept clear text passwords, what
gives, they will accept obfuscated passwords! We do not want clear text
passwords, hence we use Kerberos for authentication for our subversion repos
.. no handling of passwords by Subversion .. all handled by OS itself .. be
it Windows or Linux! Likewise with people using SSPI (integratd auth)!
At least we at Subversion can say that users get what they see .. no
pretention of 'secure password storage' just because its not in clear
'clear text'!
I agree we must have a secure password handling, somethng similar to Gnome
keychain or Mac Keychain or Firefox (using master password feature) or
KeepasswordSafe etc ...
regards
S.
----- Original Message -----
From: "Alex Holst" <a...@mongers.org>
To: <de...@subversion.tigris.org>
Sent: Thursday, October 19, 2006 7:57 AM
Subject: Re: [PATCH] Obfuscate auth info
> Quoting Max Bowsher (maxb1@ukf.net):
>> Alex Holst wrote:
>> > I beg of you: Please don't introduce this obfuscation to auth data in
>> > Subversion.
>>
>> Question: If you feel so strongly about it, are you also campaigning for
>> the trivial obfuscation to be removed from CVS?
>
> No. First, my customers don't use CVS, so I don't really care. Secondly,
> I suspect it would be much harder to remove features introduced many
> years ago in a dated scm tool than it would be to prevent the
> introduction of questionable obfuscation features in a newer, modern scm
> tool.
>
> I also think a mistake made years ago shouldn't be made again.
>
> I claim that, regardless of what warning might appear in the password
> file, obfuscated auth data will result in many users/admins/managers
> thinking it takes a lot of effort to recover their password. Anyone who
> has ever dealt with users or managers knows I'm not kidding.
>
> Which is greater? The cost of educating users who post to the mailing
> list about clear text passwords or the very likely possibility that
> a user will shoot themselves in the foot because they didn't feel a need
> to investigate ssh keys, certs or kerberos auth?
>
> --
> I prefer the dark of the night, after midnight and before four-thirty,
> when it's more bare, more hollow. http://a.mongers.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting Max Bowsher (maxb1@ukf.net):
> Alex Holst wrote:
> > I beg of you: Please don't introduce this obfuscation to auth data in
> > Subversion.
>
> Question: If you feel so strongly about it, are you also campaigning for
> the trivial obfuscation to be removed from CVS?
No. First, my customers don't use CVS, so I don't really care. Secondly,
I suspect it would be much harder to remove features introduced many
years ago in a dated scm tool than it would be to prevent the
introduction of questionable obfuscation features in a newer, modern scm
tool.
I also think a mistake made years ago shouldn't be made again.
I claim that, regardless of what warning might appear in the password
file, obfuscated auth data will result in many users/admins/managers
thinking it takes a lot of effort to recover their password. Anyone who
has ever dealt with users or managers knows I'm not kidding.
Which is greater? The cost of educating users who post to the mailing
list about clear text passwords or the very likely possibility that
a user will shoot themselves in the foot because they didn't feel a need
to investigate ssh keys, certs or kerberos auth?
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Obfuscate auth info
Posted by Max Bowsher <ma...@ukf.net>.
Alex Holst wrote:
> I beg of you: Please don't introduce this obfuscation to auth data in
> Subversion.
Question: If you feel so strongly about it, are you also campaigning for
the trivial obfuscation to be removed from CVS?
Max.
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting Malcolm Rowe (malcolm-svn-dev@farside.org.uk):
[snip stuff about CryptoAPI and OSX keychain]
> Yes, we absolutely do not want to mislead people about what we're doing,
> but that's what the large warning in the auth file is for. Is that not
> good enough?
Re: [PATCH] Obfuscate auth info
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Oct 18, 2006 at 03:12:15PM +0200, Alex Holst wrote:
> Quoting Malcolm Rowe (malcolm-svn-dev@farside.org.uk):
> > Obfuscating passwords solves two problems:
> > 1. It prevents accidental disclosure (e.g. 'grep -r pony ~', if your
> > password is 'i-want-a-pony', your non-malicious sysadmin reading
> > it by mistake, that kind of thing).
> > 2. It stops people complaining that "HEY SUBVERSION IS STORING MY PASSWORD IN
> > THE CLEAR!!1".
>
> Whilte Such a change may stop users complaining,
> it won't stop subversion from storing the password (effectivly) in the
> clear.
>
> None of this will stop attackers.
Both true, though neither of those are in any way the intended goals for
this change.
> And, while the change may indeed stop
> users from complaning, you'll simply end up with security professionals,
> like me, complaining that subversion "tricks" users into not
> investigating alternatives to plain text passwords.
>
We'd ideally like to implement an equivalent to Keychain or CryptoAPI on
Unix-like platforms, possibly via the mythical svn-agent, or via
something like gpg-agent or ssh-agent.
But we've been saying that for the past few years. In the meantime, we
still store passwords in plaintext, and this makes some people
uncomfortable.
Yes, we absolutely do not want to mislead people about what we're doing,
but that's what the large warning in the auth file is for. Is that not
good enough?
Regards,
Malcolm
Re: [PATCH] Obfuscate auth info
Posted by Alex Holst <a...@mongers.org>.
Quoting Malcolm Rowe (malcolm-svn-dev@farside.org.uk):
> Obfuscating passwords solves two problems:
> 1. It prevents accidental disclosure (e.g. 'grep -r pony ~', if your
> password is 'i-want-a-pony', your non-malicious sysadmin reading
> it by mistake, that kind of thing).
> 2. It stops people complaining that "HEY SUBVERSION IS STORING MY PASSWORD IN
> THE CLEAR!!1".
Please don't do this. Whilte Such a change may stop users complaining,
it won't stop subversion from storing the password (effectivly) in the
clear.
None of this will stop attackers. And, while the change may indeed stop
users from complaning, you'll simply end up with security professionals,
like me, complaining that subversion "tricks" users into not
investigating alternatives to plain text passwords.
To quote Thomas Ptacek (replace 'SAN' with 'svn'): "The lack of
superficial (or worse, complicated) security mechanisms forces operators
to confront the fact that SAN security requires network architecture
support." -- http://www.matasano.com/log/203/radioactive/
Users who complain about the risk of plain text passwords need to be
educated and motivated to move to ssh keys, certificates or full disk
encryption (or switch to an OS that provides a safe method of storing
passwords).
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org