Re: Re: Gmane readers - please subscribe

[Nick Dokos <nicholas.dokos@hp.com>]

Ben Finney <ben+emacs@benfinney.id.au> wrote:

> Tyler Smith <tyler.smith@eku.edu> writes:
> 
> > Ben Finney <ben+emacs@benfinney.id.au> writes:
> >
> > > A large part of my reason for reading via Gmane is to avoid yet
> > > another set of authentication credentials. Especially one that I
> > > never use; that's a security nightmare waiting to happen. So I'm not
> > > interested in increasing my security exposure by making a Mailman
> > > account on yet another site.
> >
> > Yikes! What nightmare awaits those of us who've foolishly gone ahead
> > and subscribed? What's my exposure, beyond some nefarious cracker
> > impersonating me on emacs-orgmode?
> 
> The assumption here is that logging into the mailing list account is
> something done infrequently to never for any given user. That's
> certainly the case for just about any list I've subscribed to.
> 
> For an infrequently-to-never used passphrase, one of two things is the
> case: either it's unique, or it is identical to the passphrase that
> accesses some other set of services for the user.
> 
> Since it's an infrequently-to-never accessed service, it's an
> unreasonable burden to expect the user to maintain unique passphrases
> for every such service. If for this list, why not for every such list?
> 

Why not indeed? See below.

> So what usually ends up happening is they're identical for a given
> person across many different services. But the more that's the case, the
> greater the exposure: any one of those services could manage their
> security poorly, or simply be unlucky enough to attract a bored and/or
> motivated cracker; and a compromise on any one of them removes any
> expectation of security on any of the rest of the services where the
> user has the same passphrase.
> 
> The sensible policy, therefore, is to cull the proliferation of such
> passphrase-requiring infrequently-to-never-accessed accounts. Which, in
> turn, means saying a polite “no thank you” to most requests to set up
> new accounts.
> 

It seems to me that another sensible policy is to generate a random
password, set it and forget it. If I ever need it, I use the password
reminder mechanism. The policy has the advantage of reducing the load on
the administrators.  The disadvantage is that I have to wait a few
minutes before I can make changes. I'm perfectly willing to make that
trade-off.

The most serious problem with this approach is how to generate a
password that obeys whatever stupid (and in many cases, undocumented)
restrictions the program designer imposes on acceptable passwords.
Witn mailman, you can let *it* generate the password.

There may be other problems of course that I have not thought about. I
also sympathize with your point of view[1]: there are many cases where
I *have* to have another password and it drives me up the wall, but in
this one case, I really don't mind.

Nick

[1] For mailman in particular, Jamie Zawinski published an essay
    entitled "Mailman considered harmful", attacking the mailman
    password policy (among other things):

        http://www.jwz.org/doc/mailman.html

    Barry Warsaw's rebuttal is here:

        http://www.gnu.org/software/mailman/jwzrebuttal.html