jak@talcott.UUCP (Joe Konstan) (03/16/85)
> They namely did that with some knowledge of how people choose there passwords. > It seems to be very difficult for students and staff here to think of > passwords which are hard to guess. *** REPLACE THIS LINE WITH YOUR PASSWORD *** I don't see why there should be any difficulty in choosing passwords. If the general guideline of not picking anything that could be found in /usr/dict/words, and not picking immediately available public info is adhered to, passwords should be unguessable. For example, I had a password of $SR#>PU! for a long time, and I doubt anyone ever did or would guess its significance (CAPS lock for a HASP command). What I think is more dangerous is allowing externally available computers to have passwordless accounts. This can make access really easy. Also, a better solution might be storing an incorrect count, and disabling an account for 24 hours or so if 10 incorrect passwords were entered in a row. We've had this at times here, and I know of no problems other than with people who leave their forst names, or other similar stuff, as passwords. Mithrandir jak@talcott
dave@inset.UUCP (Dave Lukes) (03/23/85)
jak@talcott sez: > >What I think is more dangerous is allowing externally available >computers to have passwordless accounts. This can make access really >easy. Agreed >Also, a better solution might be storing an incorrect count, and >disabling an account for 24 hours or so if 10 incorrect passwords were >entered in a row. We've had this at times here, and I know of no >problems other than with people who leave their forst names, or other >similar stuff, as passwords. > Read the AT&T Bell Laboratories Technical Journal (yawn) Oct. '84 UN*X issue, there's a paper there on UN*X security which explains what's wrong with this: If you do this for root, you've got problems ... Also, more importantly, I can go up to your machine, knowing that it has this particular misfeature, and knowing the login names of the local administrator(s) and I type: login: <administrators login name> Password: <anything> Login incorrect login: <administrators login name> ... and so on, until it disables the logins for the administrator(s), (or you accidentally type the right pasword). then I have 24 hours (or until the admins guess) of peaceful hacking. And the moral of this story is: ********** IT'S ALWAYS MORE PAINFUL THAN YOU THINK !!! ********** Yours insecurely, Dave.
tihor@acf4.UUCP (Stephen Tihor) (03/26/85)
dave@inset sez: >Read the AT&T Bell Laboratories Technical Journal (yawn) Oct. '84 UN*X issue, >there's a paper there on UN*X security which explains what's wrong with this: [disabling accounts with some high % of failures] >If you do this for root, you've got problems ... Thats only true if you implement the naive mode of a single counter for all each account and include everyone...etc. There is some interesing discussion of this issue in the VMS guide to system security. The solution implemented there was to allow (1) local control over all the parameters, (2) an emergency entrance at the physical console to let root have at the system when all else fails since physical access to the console implies control of the system anyway, (3) couts login failures in most cases on a SOURCE X USERNAME basis and then support disabling for a variable period of time after the last failure of suspicious set of failures.