peter@stca77.stc.oz (Peter Jeremy) (12/08/88)
In the wake of thr RTM worm, there has been much discussion on system security in various newsgroups. One item that caught my eye (sorry, I can't remember the reference) suggested running a daemon that checked for trivial passwords, and mailing the user and sysadm when one was found. This sounded like a good idea, until I thought it through. The core of such a daemon is a password _cracker_. Whilst the daemon itself should be innocuous (subject to bugs :-), the source would make an excellent basis for a worm. Question for all you wizards out there: Is such a program "legitimate"? What should I do with the source (and presumably the executable) to prevent misuse? Or is such a program such a trivial exercise that it is not worth protecting? The other logical approach is an improved PASSWD(1) program that prevents users using trivial passwords. Does anyone have such a beast? What is a good (quick*) way of deciding whether a password is trivial? -- Peter Jeremy (VK2PJ) peter@stca77.stc.oz Alcatel-STC Australia ...!uunet!stca77.stc.oz!peter 41 Mandible St peter%stca77.stc.oz@uunet.UU.NET ALEXANDRIA NSW 2015
henry@utzoo.uucp (Henry Spencer) (12/13/88)
In article <375@stca77.stc.oz> peter@stca77.stc.oz (Peter Jeremy) writes: >... suggested running a daemon that checked >for trivial passwords, and mailing the user and sysadm when one was found. > >This sounded like a good idea, until I thought it through. The core of >such a daemon is a password _cracker_. Whilst the daemon itself should >be innocuous (subject to bugs :-), the source would make an excellent >basis for a worm. This is a general problem with many kinds of security checking and security logging: the programs and their output are potentially valuable to crackers. At the very least, even if your regular sources are generally available to your users, the sources for these programs shouldn't be. Output preferably should be offline entirely (e.g. on a printer in a secure area), and failing that should at least be protected. (This isn't necessarily sufficient, though, even if the protection system is uncompromised. For example, if you run a password prober regularly, and have it send mail to folks whose passwords it finds, the modification dates on mailboxes point to accounts with weak passwords.) >... Or is such a program such a trivial exercise that it is not >worth protecting? Any competent bad guy can write his own. However, the general principle to follow is "never waste an opportunity to make things harder for the opposition". It's always possible that your program is better or smarter than the one he would write. You should make some effort to protect yours, although heroic measures probably aren't justified. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu