[COFF] Origination of awful security design [COFF, COFF]

[bill at CORCORAN.LIFE (William Corcoran)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3536 bytes --]

Okay, who or what organization did it?  A wretched security issue that remains in many UNIX variants even to this day...

Is this an example of boneheaded groupthink or a lone wolf trying to achieve parallel structure in design without thinking of the consequences:

There is a command called “last.”  Typically, when used with -R you can tell the last successful logins on the system along with origination IP.  Very clean command.

Then, presumably, someone else comes along and writes its corollary: lastb

The “lastb” command is the “last” command’s evil twin.  The lastb command is one of the finest examples on the need for taking human nature, if not common sense, into the deliberation process when deciding available commands and functionality.   

The “lastb” command takes whatever was keyed into login that fails to register as a successful login and writes the output to file.  

Thus, any user making a fat finger mistake is certain to key in a  password into the “login:” (log name) request of the login command over time.  

Over time, say three (3) years with even a small user population, passwords will be revealed in the lastb file:  btmp, bwtmp, and so on.   

The problem, of course, is that there is no attempt to encrypt this file used by lastb on many UNIX systems.  Oh, your cron kicks off a job that truncates the files used by lastb every week you say?  That’s playing fast and loose. 

Anyway, this reminds me of a trick a ten year old (the boss’s kid) pranked on everyone in the office any chance he could:

In 1985, this little hacker would silently  stand by your terminal as you return from lunch and just after you enter your response to login:, he would reach over and depress the return key directly after you depressed the return key in response to login. 

Well, that double return key action would enter a return in response to password.  The login command would promptly comply and print login again.    As you keep your momentum of logging in, not really realizing you were just victimized, you press on and enter your password followed by a return key. 

At that point, echo is turned on and surprisingly (to the uninitiated anyway) your password appears on the tube for all to see. 

And, yes, login complies with its security unconscious codebase (assuming you pressed return after your password was displayed) and this further memorializes the nefarious transaction by writing the offense into the file used by lastb.  

For example, a relatively recent version of a well known UNIX still has the lastb command.  It can be disabled.  

Look, if you really want the lastb feature, why not encrypt it.  Or, only allow lastb entries where a particular login exists on the system.  (Although, this too is an awful practice as you clue the hacker into valid logins.  Our Founding Fathers taught us that just counting the milliseconds (now even more granularity than a millisecond is required) of response time can alert a savvy hacker as to the validity of a login. 

Just knowing that a login is valid wins the hacker almost half the battle.  Here, my complaint is that the nearly clear text password is likely placed in the files used by lastb over time.  I realize this functionality can easily be turned off.  But, human nature reminds us that simply having dangerous functionality available is a problem. 

Can anyone on our Forum elucidate the impetus leading to the rationale for the lastb and why it’s warts have been around for so long?  

Bill Corcoran