Re: Some security-related suggestions
Ned Freed <NED@sigurd.innosoft.com> Thu, 09 June 1994 00:49 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08967; 8 Jun 94 20:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08963; 8 Jun 94 20:49 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa19099; 8 Jun 94 20:49 EDT
Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.6) id UAA07938; Wed, 8 Jun 1994 20:44:31 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Wed, 8 Jun 1994 20:44:30 -0400 (EDT)
Received: from po2.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.0hxaKsy00Uda5ioE51>; Wed, 8 Jun 1994 20:43:38 -0400 (EDT)
Received: from sigurd.innosoft.com (SIGURD.INNOSOFT.COM [192.160.253.70]) by po2.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id UAA28352 for <ietf-pop3+@andrew.cmu.edu>; Wed, 8 Jun 1994 20:43:08 -0400
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HDAYPYTXCW9KM1RM@SIGURD.INNOSOFT.COM>; Wed, 08 Jun 1994 17:42:51 -0800 (PST)
Date: Wed, 08 Jun 1994 17:18:57 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: Some security-related suggestions
In-reply-to: Your message dated "Wed, 08 Jun 1994 16:56:01 -0400 (EDT)" <ghxX1V600WBwA10EIh@andrew.cmu.edu>
To: John Gardiner Myers <jgm+@cmu.edu>
Cc: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>
Message-id: <01HDB3JNDOLO9KM1RM@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="ISO-8859-1"
Content-transfer-encoding: 7bit
> Ned Freed <NED@SIGURD.INNOSOFT.COM> writes: > > "Providing an indication of the existence of an account in the absence of > > a proper password lets attackers narrow the search to known accounts, and > > thus represents an increased security risk." > There are people who still believe this? Yeah, I happen to believe it because it happens to be true. > Attackers can narrow the > search to known accounts by examining the local-parts of addresses in > messages sent from the site. Not at most of the larger sites I deal with, they can't. Most of them unconditionally rewrite all addresses on outgoing mail so that no information is given about the actual account names involved. The local-parts are therefore totally worthless in determining actual account names and even specific systems containing the accounts (getting rid of system names in headers is a harder problem, but it can be done if you torque on it hard enough). Often as not their account names then become some numeric code or other crap I don't care for and which make my life hard when I have to debug stuff, but hey, I wasn't asked for permission to do this, you know? Besides, even the dumbest crackers out there know that the best accounts to break into are the old ones lying around that nobody ever uses (and hence never appear in a local-part). Find one of these and you'll be sitting pretty, since nobody will ever go running to the system manager saying that they saw someone else logged in on their account. > These issues aren't mentioned at all in RFC 1510. If the issues > aren't important enough to deal with in Kerberos, why should they be > addressed in POP? I never said that the IESG is consistent in its consideration of such issues. (No disrespect intended, but my observations have indicated that they aren't.) All I said was that documents have been sent back to committee for their failure to address such issues. This is proven fact. Since someone has been kind enough to specify some prose that may help, I don't see any compelling reason for its exclusion and at least one good reason to include it. Ned P.S. I once spent almost three months tracking down a cracker. They found an unused account using precisely this sort of attack and then used this account as a springboard to attack systems all over the Internet. We caught on early and started in on a daily ritual where we watched this clown break into system after system after system using this sort of technique as well as several others. (There was a strong preference for military sites, which on average seemed to be a bit more vulnerable than most.) After that came the daily ritual of cold-calling administrative contacts listed by WHOIS and telling incredulous people that their systems had just been invaded. Then there were the return calls, personal visits from military personnel, and whatnot as we worked out ways to reliably exchange information about how the breakins were done back to these admins so they could plug the holes. And finally, after this clown broke into some important military databases and did some really serious damage once again using this same sort of attack, the FBI managed to bestir itself enough to issue the warrants we'd been asking for, and they nailed the cracker. Needless to say, my stolen three months of time weren't returned to me...
- Some security-related suggestions Michael D'Errico
- Re: Some security-related suggestions John Gardiner Myers
- Re: Some security-related suggestions Ned Freed
- Re: Some security-related suggestions John Gardiner Myers
- Re: Some security-related suggestions Michael D'Errico
- Re: Some security-related suggestions Steve Dorner
- Re: Some security-related suggestions Michael D'Errico
- Re: Some security-related suggestions Ned Freed
- Re: Some security-related suggestions John Gardiner Myers
- Re: Some security-related suggestions Michael D'Errico
- Re: Some security-related suggestions Steve Dorner