• Wile E Coyote (unregistered)

    Genius.

  • Frank (unregistered)

    Prevent people changing their own passwords? Would usually be a WTF in itself, but here... can't run the password changer, can't get that file. Possibly.

  • ANON (unregistered)

    TRWTF are passwords

  • flabdablet (cs)

    My friend and I got into trouble in the early eighties for unauthorized use of an admin account on the college mainframe.

    He'd found out that punch card jobs, which were actually all that we as engineering students had ever been taught how to use, got processed in an environment with no access restrictions at all. And it didn't take terribly long to work out that the system's user account records were, as in this story, stored in plaintext.

    He'd also found out that card processing was not limited to the FORTRAN compile-and-run jobs we'd been taught how to submit, but could also handle jobs written in the same scripting language we'd already taught ourselves how to use on the interactive terminals in the business wing.

    If I recall correctly, neither of us had actually gone looking for that knowledge: it simply revealed itself spontaneously one day, after I'd submitted a card job whose end-of-job card had accidentally had a hole punched in the wrong spot, which happened to precede one of the sysadmin's jobs in the card hopper. And that truly was a genuine accident - I'd just fat-fingered one of the card punches.

    Which was easy to do, because the only actual keypunch machine on the entire campus was behind the counter in the I/O Centre, for the sole use of the official keypunch operator. Keen engineering students wishing to punch their own cards had a choice between two kinds of manual punch.

    There was one that looked like an oversized label making machine, with a big wheel on the side that you twisted around until the character you wanted appeared under the cursor and a big button at the front that you'd thump to punch the code for that character into the card. I hated those clumsy bloody things, and preferred to use the other kind: a very low-tech mechanism with twelve hole-punch keys - one per card row - and a column advance key.

    EBCDIC is broken and wrong in all kinds of ways, but its encoding onto 80x12 punch cards is very straightforward.

  • RFox (unregistered)

    TRWTF were non-operator interactive logins on either of those basically batch systems. More normal:

    "Let them punch cards"

  • Tux "Tuxedo" Penguin (unregistered)

    TRWTF is, and always will be, Discourse.

  • Peter (unregistered)

    Face down, 9 edge first.

    At UMass, in the 70s, we had a CDC 3600 and a 3800, then a CYBER 74. I worked at the UCC, repairing Teletypes. A side benefit was a free, unlimited, account on the mainframe. I did the required assembly language course on the CYBER. It was much more fun than a PDP-11, and I could write code in my dorm room, rather than having to sign up for early morning slots on the PDP-11.

    Ahh...the good old days, when computers had switches and lights.

  • operagost (cs) in reply to Frank
    Frank:
    Prevent people changing their own passwords? Would usually be a WTF in itself, but here... can't run the password changer, can't get that file. Possibly.
    Or, run a server process that receives and processes all password requests itself-- but I can't imagine a primitive OS like this would be able to handle the interprocess communication required.
  • excession (cs)

    Control Data's NOS/BE had a password file, for INTERCOM, it was a plain text file, protected by four levels of password.

    But if you knew the password, you were able to find someone who had the Software bit set (system administration), and with their credentials, the mainframe was your oyster.

    Control Data used to provide the ENTIRE source code for NOS/BE, including the password change program, which loaded up the password file. Inside the source code was the hard-coded password. :-) icomblstz ... and three other passwords.

    I didn't need the file, I had admin access, but it was useful knowledge at the time. Dead operating systems are pretty useless now though, so I'm not too reticent to chuck out this little bit of 'secret' knowledge.

    For me, being back working on the guts of NOS/BE, was the highlight of my 32 year career. I never had more eye-opening experiences, nor met cleverer people than I was working with back in the mid 1980's. Absolute geniuses.

  • Jörg (unregistered)

    4K is actually ample for encryption. I develop full medical devices in 20K.

  • Don Q Hoti (unregistered) in reply to Peter
    Peter:
    Face down, 9 edge first.

    Ahh...the good old days, when computers had switches and lights.

    And for the sheer fun of it you could write a short assembly program, convert it to machine language by hand, and thumb it in via the switches. Not that you'd want to do this very often, but when you did - and it worked - you knew that you understood how the thing worked.

    The first time I sat in front of a PC it really bugged me that there were no lights so I could tell what the heck it was doing.

  • Anders (unregistered)

    I worked in a similar environment as the article mentions in the early 90s, similar enough it might just have been the same place. However we found out a much easier way when we needed access to the big gray and red machines: most of the professors/researchers used their login as their password....

  • chubertdev (cs)
  • Not snoofle (unregistered)

    This was the first snoofle story that didn't grate on me. Good job!

    However, I am not sure that we can really laugh at things people did in ancient computing. It's like engineers laughing at the designer of the Tower of Pisa or the Tacoma Narrows bridge.

  • cellocgw (cs)

    To all of this I say: so what?

    That was back when it was pretty much a massive success to get computer hardware and OS to function reliably. Security wasn't perfect, nor was it anywhere near the problem we have today. Most computers were both air-gapped and meat-sack-gapped, and people were more or less expected not to be assholes. Heck, I found a similar "non-protected read area" bug while learning FORTRAN on a multiuser PDP-8 in the early 70s. Yeah, it was funny to read excerpts of the college bursar's finance reports, but to me the real lesson was to write better code so I only retrieved data from the place (or size) I'd written to.

  • UpNDown (cs)

    Ah, yes, CDC 6000 series. Back in the day I actually figured out a way to patch a running PPU program and was able to do whatever I wanted -- all the system authentication happening in the PPUs. Of course, I just figured it all out for the challenge of doing it, I never used it for anything malevolent. Part of the fun was creating a COMPASS macro set to write PPU code.

  • Alex Godofsky (unregistered)

    If this was really pre-ethernet, would we really expect them to be encrypting passwords? Ethernet was 1980 and I don't believe the idea of storing passwords in a hashed form even existed until the mid-70s. Modern cryptography was in its infancy in the 70s.

  • Matt Westwood (cs) in reply to Don Q Hoti
    Don Q Hoti:
    Peter:
    Face down, 9 edge first.

    Ahh...the good old days, when computers had switches and lights.

    And for the sheer fun of it you could write a short assembly program, convert it to machine language by hand, and thumb it in via the switches. Not that you'd want to do this very often, but when you did - and it worked - you knew that you understood how the thing worked.

    The first time I sat in front of a PC it really bugged me that there were no lights so I could tell what the heck it was doing.

    My first professional job (early 80s) was writing machine code programs for an 8085 which required that I type the hex codes into an EPROM programmer. Happy days.

  • Anachronda (unregistered) in reply to flabdablet
    He'd found out that punch card jobs, which were actually all that we as engineering students had ever been taught how to use, got processed in an environment with no access restrictions at all.

    Over where I was a student, we used a system that required username and password cards. Which meant that some careless folks tossed them along with the rest of their decks when they were done. I spent many an hour playing games on accounts pulled from the trash bin.

    They had also forgotten to protect the card reader. Some of the lab assistants had a little game going about who had the shortest program to snag a deck from the reader. It all ended when I discovered that you could just $TYPE CRA0: and get the next deck, username and password and all, displayed at your terminal.

  • M (unregistered) in reply to flabdablet

    You sound a lot like my college roommate from my freshman year, though wrong timeframe as this was the mid-1970s. He never was intentionally malicious, but would find ways access everything on our University's CDC 6400. Snagging himself a copy of one of the system tapes landed him a suspension. "but if you didn't want us to access it, you'd set the permissions accordingly" was his plea and it did seem to get him reinstated eventually. I've always wondered if he's now a black hat or a white hat.

  • hm (unregistered) in reply to flabdablet

    did you neighbors catch you when you wonder in their houses, when they forgot to lock doors?

  • eric76 (unregistered)

    We had a couple of students at college who noticed that the job numbers on the main frame were all 4 digits long.

    In the week preceeding April 1, they created 10,000 decks of jcl jobs that would not execute until some procedure was loaded in the future. Obviously, they wanted to see what happened when they used up every possible 4 digit job number.

    I had a small part in the prank. They were going to just duplicate the same job card 10,000 times but I pointed out that every job would have the same identical user assigned id that would likely make it easy for the mainframe operators to identify and delete the offending jobs. So I wrote a little program for them that generated 10,000 job cards with random ids.

    In the early evening of April 1 -- I think it was a Sunday evening -- they started running the decks through the card reader. It was painfully slow because the card reader would pause after reading the job card and password while it checked the account number and password to validate the job.

    All went well until they had read in about 1,500 jobs. The card reader stopped reading. After about an hour and a half, it started back up again with those 1,500 jobs gone. It was kind of anticlimatic.

  • the way the real WTF is using passwords in the first place. (unregistered)

    Seriously. The place I work at we all know eachother and we can trust eachother. Nobody has passwords and nothing goes wrong. You just need better friends.

  • Jerry (unregistered)

    The age of the dinosaurs was after this foobard story

  • LurkingKiwi (unregistered) in reply to Anders
    Anders:
    However we found out a much easier way when we needed access to the big gray and red machines: most of the professors/researchers used their login as their password....
    When I was studying in the early 80s the university system was just moving from punched cards to interactive login for staff and post-grad use. Usercodes started with a 2-letter departmental prefix, and there were a few departments you could reply on to have staff who kept the default password (GE=geography was a sure winner) so suspects were noted during the day in the user list and tried at night.
  • RichP (cs)

    Shirley the password for a file called VALIJUN would be 24601?

  • Ken T. (unregistered) in reply to Alex Godofsky
    Alex Godofsky:
    If this was really pre-ethernet, would we really expect them to be encrypting passwords? Ethernet was 1980 and I don't believe the idea of storing passwords in a hashed form even existed until the mid-70s.
    1969.
  • cyborg (unregistered) in reply to RichP
    RichP:
    Shirley the password for a file called VALIJUN would be 24601?

    Or Wolverine.

  • Fritz, a.k.a. Fritzo (unregistered) in reply to Jörg
    Jörg:
    4K is actually ample for encryption.

    Yeah this made me raise an eyebrow (which is more physical exercise than I like to get in a day). Especially during those days when programmers were generally used to working in tiny memory, 4 kB would've gone a long way.

  • Peter (unregistered) in reply to eric76

    We had a couple of students at college who noticed that the job numbers on the main frame were all 4 digits long.

    First place I worked had a telephone system that required you to enter a 5 digit code for an outside line. We had some number of thousand people in the facilty. I did the math, tried 100 sequential numbers and found one that worked.

  • Coyne (cs) in reply to flabdablet
    flabdablet:
    EBCDIC is broken and wrong in all kinds of ways, ...

    Shall we list those ways?

    1. Numbers follow all letters.
    2. The upper and lower case letter blocks are not contiguous with gaps between I and J; and between R and S. And the blocks are reversed; lower case precedes upper case.
    3. No brackets.
    4. Contains a ¢. For what reason, no one knows.
    5. Contains two vertical bars (and one of them is broken). Not that kind of broken, the other kind: unbroken | and broken ¦.
    6. Contains a dash-down character (¬). Who even heard of that? It's so weird even the name is dumb.
    7. Contains five spacing characters: SPace (SP), Numeric SPace (NSP) because those digits are uppity, BackSpace (BS) and, just in case the point wasn't clear, Required SPace (RSP). Oh, and also forgot those poor pathetic digits: NBS (Numeric Back Space).
    8. Has a character for tabbing...vertically (VT).
    9. Has an SOS character because it needs help. Oh, wait, Start Of Significance?!
    10. Oh them tabs: Horizontal tab, naturally and...Indent Tab (IT)?!
    11. New Line (NL) character and, we insist: Required New Line (RNL) character. And, of course, a Form Feed (FF) and the obviously requisite Required Form Feed (RFF).
    12. For all you wusses out there, a WUS character (Word UnderScore).
    13. for the character with hexadecimal value 0xFF, the creative name of "EO" (Eight Ones); no idea why not TF (Two Fifteens) or FT (Four Threes). Maybe they should have gone with EA (Eight Aces).
    14. A RePeaT (RPT) character. Because it saves so much space to send a "0" and RPT character instead of sending "00".
    15. A POC (Program-Operator Communication) character. Which suggests the cute thought of that operator communication: ka-POC-eta-POC-eta-POC-eta...
    16. SPS (SuPerScript) and SBS (SuBScript) characters just in case.
    17. And to finish my list, we have the delicate little SHY character (Syllable HYphen).

    Hmmm...they forgot the KS (Kitchen Sink) character. Maybe EBCDIC is TRWTF?

  • BigBen (unregistered) in reply to Not snoofle

    Lol.

  • Zemm (cs) in reply to Coyne

    Can I post? I just got some errors...

  • Alex Godofsky (unregistered) in reply to Ken T.
    Comment held for moderation.
  • pjt33 (cs) in reply to LurkingKiwi
    LurkingKiwi:
    Anders:
    However we found out a much easier way when we needed access to the big gray and red machines: most of the professors/researchers used their login as their password....
    When I was studying in the early 80s the university system was just moving from punched cards to interactive login for staff and post-grad use. Usercodes started with a 2-letter departmental prefix, and there were a few departments you could reply on to have staff who kept the default password (GE=geography was a sure winner) so suspects were noted during the day in the user list and tried at night.
    When my secondary school downgraded from a network of Archimedes to a network of Win95 boxes, we all got new user accounts. Our usernames were formed from the last two digits of the year we joined the school, the first three letters of our surnames, and the first three letters of our first names; and our passwords were all "pupil".

    The staff had a slightly different username formation, but it didn't take long to figure out that their initial passwords were all "staff", and pupils amused themselves by sending WinPopup messages from staff accounts to their friends.

    Guess what the headmaster's password was?

  • Terr (unregistered)

    Back in high-school, Windows 95/98 had a feature where username.pwl files were left behind from anyone who logged on, each containing saved network credentials, like a sort of keyring. The files were rather-weakly encrypted with the user's primary logon password.

    This meant that you could easily do an offline brute-force attack of any user who had previously sat down to the same computer, including, say, the teachers in the computer lab...

  • eric bloedow (unregistered)

    reminds me of a story in a book: an old program called "sendmail" had a bug that allowed it to send "messages" anywhere-including restricted system folders! so if you knew where the user profiles were stored, you could easily "mail" a fake profile, with admin privileges, into the system. the makers of "sendmail" released a patch to fix this, but lots of lazy or sloppy admins simply didn't get around to applying it...

Leave a comment on “Oh So Secret Passwords”

Log In or post as a guest

Replying to comment #:

« Return to Article