https://www.multicians.org/shell.html
CTSS was developed during 1963 and 64. I was at MIT on the computer center staff at that time. After having written dozens of commands for CTSS, I reached the stage where I felt that commands should be usable as building blocks for writing more commands, just like subroutine libraries. Hence, I wrote "RUNCOM", a sort of shell driving the execution of command scripts, with argument substitution. The tool became instantly most popular, as it became possible to go home in the evening while leaving behind long runcoms executing overnight. It was quite neat for boring and repetitive tasks such as renaming, moving, updating, compiling, etc. whole directories of files for system and application maintenance and monitoring.
In the same vein, I also felt that commands should be usable as library subroutines, or vice versa. This stemmed from my practice (unique at the time) of writing CTSS commands in MAD (Michigan Algorithm Decoder), a simplified Algol-like language. It was much faster and the code was more maintainable than the IBM 7094 assembly code. Since I needed MAD friendly subroutine calls to access CTSS primitives, I wrote in assembly code a battery of interface subroutines, which very often mimicked CTSS basic command functions. Or I wanted to make commands out of subroutines which handled common chores. I felt it was an awkward duplication of effort. However, I did not go further in the context of CTSS.
Then in 64 came the Multics design time, in which I was not much involved, because I had made it clear I wanted to return to France in mid 65. However, this idea of using commands somehow like a programming language was still in the back of my mind. Christopher Strachey, a British scientist, had visited MIT about that time, and his macro-generator design appeared to me a very solid base for a command language, in particular the techniques for quoting and passing arguments. Without being invited on the subject, I wrote a paper explaining how the Multics command language could be designed with this objective. And I coined the word "shell" to name it.
(Score: 2) by bzipitidoo on Saturday April 27, @02:35PM (14 children)
Ahh, CTSS. I wanted to trace down the origin of the whole idea of logging in with a username/userID and then a password. From what I found, CTSS is the first system to do that.
But why that way? Why not ask for the password first, then the username? Why ask for a username at all? Why not just a password? Was it to give users the freedom to use the same passwords? I doubt that. I guess they thought it would be a lot more secure if a cracker could work on only one account at a time, instead of all of them simultaneously. But the system could greatly strengthen and guarantee the uniqueness of passwords by adding a few extra characters.
Today we're stuck with that legacy login method. And, it's become another case of the contradiction in which some information, the username, is supposed to be simultaneously public and secret. I've read bank advice to users to keep their usernames secret. But, the design intended for usernames to be public, like a telephone directory. To wit, you can't email someone without an email address which so often doubles as a username.
More on subject, sure is a lot of fun insecurity to put passwords into shell scripts, LOL.
(Score: 2) by Snotnose on Saturday April 27, @02:47PM (12 children)
What difference does it make what order you enter your name and password in? As for just using a password, what about people who use the same password? This was especially prevalent on college campuses. It's also the reason passwords are salted. If Joe and Jenny both like GoHuskies as a password, by using a salt an attacker doesn't know those randombits represent the same password.
When the dust settled America realized it was saved by a porn star.
(Score: 5, Interesting) by Snotnose on Saturday April 27, @02:55PM
Forgot to point out that, until recently, Microsoft didn't salt their passwords. My niece put a password on my parent's windows box some 10 years ago. She then forgot what it was. I made a CD with a rainbow cracker, set the PC to boot from CD, and a couple minutes later the password popped out.
For those of you who don't know, a rainbow cracker encrypts all possible 8-9 character passwords and stores them in a huge file. The cracker asks Windows for the encrypted password, which it then finds in it's table right next to the plaintext key.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by bzipitidoo on Saturday April 27, @07:18PM (10 children)
For the username, shouldn't have a separate prompt at all. Should be part of the password. Salt is a great idea. The password should be further strengthened by not leaving the choice entirely to the user, sort of more salt, the difference being that the user must have it to log in.
(Score: 2) by acid andy on Saturday April 27, @07:38PM (8 children)
Fine for an old single user system, but how would an admin control the user's permissions if the OS can't separate the username from the password?
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 3, Interesting) by bzipitidoo on Saturday April 27, @09:04PM (7 children)
Oh no, still have user accounts. The system just doesn't use the username for authentication. Use only a password. A good password enhanced by the system to guarantee uniqueness and strength.
(Score: 0) by Anonymous Coward on Sunday April 28, @12:12AM (3 children)
"Sorry, that password is already in use. Please choose another."
Oops.
(Score: 2) by bzipitidoo on Sunday April 28, @01:22AM (2 children)
"A good password enhanced by the system to guarantee uniqueness"
You missed that part.
(Score: 2) by owl on Sunday April 28, @03:09PM (1 child)
I believe the point the AC may be making is that there is a need for an existing user to be able to change their password. If everything is mapped to just a "password" then much more "bookeeping" may need to be done in the system for a password change.
If username is separate from password, then the only bookkeeping that needs changing is just the password referenced by that username, nothing else for that user needs to change.
(Score: 2) by acid andy on Sunday April 28, @06:45PM
It could still work as long as the OS kept a lookup table to get the username from the password and then use the username everywhere else to identify the user.
The real danger is given that the user never has to type in their username, except possibly the moment they first set their password, it increases the likelihood they will forget both their username and password at the same time and have no way to identify themselves to the computer.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 4, Touché) by owl on Sunday April 28, @03:25PM (1 child)
Ok, so it is properly hashed and salted then too, since it is a "good password enhanced by the system".
If so, and you have 47,324 user accounts (because you are a large University with a central timeshare system for your students and rooms of VT100's for them to use for their CS classes). For now we will also ignore the fact that at least two of those users will attempt to use "Password!" as their passwords.
Each time any one user attempts to log into a VT100 somewhere on campus, the central timeshare system has to take their input password, and run (worst case) 47,324 salted hashes and compare the result against the stored hash values to determine if that single user is allowed to log in.
Now, transport yourself back to the early 1970's, and said central timeshare system is something about as powerful as a PDP11 or thereabouts (where the Unix crypt() call was said to be very slow, which was why K&R chose it for their password hash algorithm).
With that little CPU, and that slow a salted hash algorithm, the worst case login for a user is 47,324 salt-hash rounds -- which might equate to several hours of runtime on the central CPU (if it could run nothing but the login hash) or several days (since it has to timeshare the login hashing with all the other users who previously did get logged in after very log waits).
That's the reason for not doing "password only" -- it is terribly inefficient. With a "user id" which isn't secret, the system knows that "Joe Merchant" is logging on, and can go do a salted hash just one time of Joe Merchant's password and decide "allow" vs. "deny" the login attempt. But it does not have to do up to 47,324 salted-hashes to discover if the password just entered happens to "allow" Joe Merchant to logon.
(Score: 3, Interesting) by bzipitidoo on Sunday April 28, @04:57PM
Good points. However, there are relatively simple ways to avoid those problems. If you use boneheaded methods, then, yes, logging in could take hours. One system I once used took a full day to update a changed password. Threw me for a while that my new password was being rejected, and after several tries to assure myself I hadn't made a typo, thought to try my old password, and, it worked! Another problem I have experienced several times is slowness between accepting the username and presenting the password prompt, resulting in my password being visible in plain text because my keypresses were still being echoed while the system was slowly getting around to prompting for the password. One way out of this problem of having to salt and hash every user password is not to salt the entire password, only part of it. The unsalted part can be used to narrow the login attempt down to one user. Undoubtedly, other methods can be devised to avoid such bottlenecks.
You also show a penchant of old school computing, in which computer needs are given higher priority than human needs. The computers serve us, not the other way around. There used to be a whole lot more cases of us inconveniencing ourselves for the sake of hardware and software limitations that eventually proved largely bogus. Like having to set jumpers on the motherboard because the hardware was incapable of figuring out for itself how much RAM was installed. Early PCs were infamous for issues of that sort. Had to tell the BIOS how many sectors, tracks, and cylinders the hard drive had, set the IRQs manually to avoid conflicts, juggle the order in which DOS loaded TSR utilities and drivers to get as much as possible into HIMEM, etc. Much of that could have been entirely avoided had the PC had a system for managing that kind of info.
A login system that prompts users once, instead of twice, is a fairly easy improvement in usability that is not a huge burden for the computer, if well implemented. Don't dismiss it as a trivial improvement! Consider how much Single Sign On was (and still is?) wanted. Single prompt is better than SSO.
(Score: 3, Funny) by DannyB on Monday April 29, @05:23PM
Oh, no, do you mean I'm going to have to change my password from 12345 ?
This also means I'll have to change the code on my luggage!
Every performance optimization is a grate wait lifted from my shoulders.
(Score: 2) by sjames on Sunday April 28, @06:34PM
You need some identifier to hang all of the data about the user on. You don't REALLY want a system to have to try an entered password against a database of 10000 entries one by one (and it WOULD be one by one since each password entry has a different salt) for every authentication, do you?
(Score: 2) by owl on Sunday April 28, @03:03PM
Considering the timeframe of all these developments, and the net CPU power of the systems involved,, the why likely comes down to performance. Consider that today you can by a low end ESP chip module for a few dollars that has more CPU compute power than a VAX780 (and CTSS would have been developed on systems less powerful than that VAX).
With password only (ignoring the "users pick the same PassWord1!" problem) your "login system" has to compare that password to all the existing users (and for this timeframe, there could be many users, far more than today's usual one per CPU) to find which one matched. Which is at best an O(N) complexity. Which results in a slow login (i.e., a modern ms-windows style login for a single user on a system with CPU and disk performance unheard of in the 60's).
If the passwords are stored encrypted and salted (I don't know if CTSS was or was not) then you have to repeat the "crypt()" call once per user on the system to see if the entered password matched, and we are starting to approach O(N^2) complexity (where above a certain size of N logins begin to exceed that needed my MS for a W11 login).
But, if you ask for username first, then the authentication system only needs to lookup that single user's password, and perform one crypt() with a single salt, to verify if that user is allowed access, which is more on the order of an O(1) operation (takes roughly constant time, no matter the number of users).
And, remember, supposedly Ken and Dennis picked their modified DES for crypt() in Unix because, at the time, on the CPU's they had, their crypt() function was very slow (which thwarted dictionary attacks). CPU power increased by multiple orders of magnitudes such that on a modern CPU, crypt() is anything but slow anymore. But in the early 1970's, with a slow crypt() function, you did not want to run more than one crypt() call per logon attempt.
So they why is most likely: Because that is the most efficient, least resource intensive, way to do it. Folks back then worried about not using more CPU than necessary, because they had little to begin with. The performance increases over the last 40-50 years has let companies ignore that fact (MS, cough) and still appear to have somewhat performant systems.
(Score: 2) by mcgrew on Saturday April 27, @03:18PM (4 children)
I was only 12 in 1964. But I was always glad someone had invented the batch file! It sure made it a lot easier to run a DOS game from Windows 95. I had a batch file for each game that renamed autoexec, renamed a different batch file to autoexec, then booted the computer with a four byte program I wrote named BOOT.COM that loaded registers and called an interrupt.
The new autoexec would set all of the interrupts and run the game, rename everything back and reboot the computer again.
mcgrewbooks.com mcgrew.info nooze.org
(Score: 2) by JoeMerchant on Saturday April 27, @03:19PM (3 children)
>I was only 12 in 1964. But I was always glad someone had invented the batch file! It sure made it a lot easier to run a DOS game from Windows 95
Born in 1952, would have been 44 when Windows 95 came out (in 1996....)
🌻🌻 [google.com]
(Score: 2) by janrinok on Saturday April 27, @04:37PM
I was also born very early in 1952! I seem to recall that there was someone a year or two older than me but I cannot remember who it was. I can still remember sugar rationing after the war, but only vaguely !
(Score: 2) by mcgrew on Monday April 29, @03:31PM (1 child)
Yep, had a TS-1000 in 1982, bought a used IBM-XT in 1987. Had a batch file menu I'd made, like most DOS users back then. But it was 1996 or 7 before I got Windows 95. It served me well until all the games were for Windows.
mcgrewbooks.com mcgrew.info nooze.org
(Score: 2) by JoeMerchant on Monday April 29, @04:22PM
I think it was 1996 before anybody got (a released version of) Windows 95.
I bought an Atari800 in the summer of 1982, by fall of 1984 I was living at University where they had "PC labs" filled with IBMs, so I just carried around a box of floppies for them until I finally bought a 486 of my own - around 1992 - grad school, and later work, were supplying $5K PCs for me to use as much as I wanted, why spend 30% of my annual income on one for myself?
🌻🌻 [google.com]