9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: presotto@plan9.att.com presotto@plan9.att.com
Subject: religious wars
Date: Fri, 18 Aug 1995 16:48:37 -0400	[thread overview]
Message-ID: <19950818204837.4YK0kr9T-7cRcYOAnIScxMV2mWVIhSDjOHkfh6HxN80@z> (raw)

We want to make clear why we fear clear passwords
entering the telnet/ftp/etc code.

If one takes Vadim's argument to the extreme, he
should eliminate passwords internally since he
has adequate protection, trusts everyone
internally, and plan 9 is just a toy system.
We ran that way ourselves for years
(till management started using Plan 9 and wanted
something better to keep us from seeing
their secret stuff).

Replacing ARP entries, changing MAC addresses, and
taking over active sessions cause denial or
interruption of service to people and are more
likely to be detected.  The first two don't even work
unless you are on the same side of a gateway.

Just stealing passwords is much harder to detect
since it is entirely passive.  It works an arbitrary
number of hops away.  Once acquired,
the passwords are useable to set up new connections
at any time as compared to the above attacks that
are once only.  These are hardly similar.

In AT&T we are protected by a firewall similar to
what you describe, one of the first in fact and
built by our group.  However, we still have people
constantly creating backdoors to the internet all
over the company, sometimes because we merge with
(or buy out) someone that already has a less protected
gateway, sometimes because someone finds the current
firewalls confining and get their own links.  Creating
crappy internal security just allows others to take
advantage of these lapses.

Also, we use multiple networks, not just broadcast
media like ethernet.  Our ATM and Datakit networks aren't
susceptible to spoofing though they can be snooped.
In these, our security is infinitely better than
clear passwords.

In short, passwords in the clear are a worse mechanism
than what we have.  As Vadim points out, it could be better.

The main reason for wanting passwords
is that they make access from Unix or DOS easier.
Out biggest fear is that this pressure will make
passwords a default mechanism.  We'ld rather see
people working on getting Unix and DOS to use 
better security or making Plan 9 security
tighter like adding expontial key exchange than
to add options to Plan 9 to make it less secure.
Just the ability to do passwords in the clear is
the first step down a very steep slope.  Climbing
back up again is real hard.  We have a chance for
a system that never goes that route, why blow it.






             reply	other threads:[~1995-08-18 20:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-08-18 20:48 presotto [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-08-19 18:24 Rich
1995-08-19  1:27 Paul
1995-08-18 22:51 Scott
1995-08-18 21:35 Berry
1995-08-18  8:51 Vadim

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=19950818204837.4YK0kr9T-7cRcYOAnIScxMV2mWVIhSDjOHkfh6HxN80@z \
    --to=presotto@plan9.att.com \
    /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).