9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] upas/smtpd password authentication
Date: Mon, 17 Dec 2007 12:52:59 -0500	[thread overview]
Message-ID: <20071217175230.1C7BC1E8C4D@holo.morphisms.net> (raw)
In-Reply-To: <1a579fc66314c00596b0b6f99acf5fc8@quanstro.net>

> i'm not a security expert.  what case that i can't currently see
> would tls solve for me that's worth the extra configuration.
> what am i missing?

I believe you are missing the fact that the 
so-called "inferno/pop" password is no less
powerful from an authentication point of 
view than the "plan9" password.  If you give me
either one, I can convince a host owner factotum
that I am you, and thus change my user id to 
yours on the local machine.

It turns out that the general login access daemons
all require p9any authentication, which can't be
carried out with the inferno/pop password, but 
that's not fundamental.  As far as factotum and
the kernel are concerned, the inferno/pop password
identifies you as much as the plan9 password.
So what I've described is, right now, only a local
escalation, not a network one.  But there's no 
fundamental reason for that to continue.

Better names would have been the "crappy DES"
("plan9") password and the "everything else" 
("inferno/pop") password.  The plan9 password
is not stored on the auth server -- its DES equivalent is.
The inferno/pop password *is* stored on the auth
server, making it possible to use in non-DES protocols.
If the plan9 password text had been stored originally,
the inferno/pop password wouldn't exist.

> tls seems like something extra to break.  i have several
> dozen mac/windows users that need detailed instructions
> for every change.

Around 1999, DHCP was a royal pain, because 
configuring it was difficult or undocumented,
the clients and all the servers spoke slightly different
dialects, and to a first approximation no one could
understand each other.  Now, you just check a box
and it works.  No one blinks at needing to set up DHCP.

IMAP and SMTP over TLS used to be difficult too,
but support for these has converged as they have
become more widespread.  Now you just check a box.

Russ


  parent reply	other threads:[~2007-12-17 17:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-15  0:09 erik quanstrom
2007-12-15  0:16 ` Steve Simon
2007-12-15  0:26   ` erik quanstrom
2007-12-16 18:02     ` Russ Cox
2007-12-16 23:16       ` erik quanstrom
2007-12-17 16:54         ` Jonathan D. Proulx
2007-12-17 17:26           ` erik quanstrom
2007-12-17 18:33             ` Jonathan D. Proulx
2007-12-17 19:40           ` Wes Kussmaul
2007-12-17 17:52         ` Russ Cox [this message]
2007-12-17 21:05         ` Lyndon Nerenberg
2007-12-17 21:08           ` Lyndon Nerenberg
2007-12-17 21:10           ` erik quanstrom
2007-12-17 23:12             ` Lyndon Nerenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071217175230.1C7BC1E8C4D@holo.morphisms.net \
    --to=rsc@swtch.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).