Too Many Login IDs



  • I currently work at a company that some people (especially if you live on the East coast of the the United States, or in Europe) may recognize, but let's call it Initech. I currently have three different login IDs on as many domains, all of which I must use for different things on a daily basis. There is a reason for this, but it's a bit difficult to explain.

    When I first started working here, I got a login on the domain INTC. All logins are numeric, by the way, in the form INTC\x123456. So, I used to use this to log in to my laptop and to connect to the various servers my team works on, mostly SQL Server instances, as well as to get into my company email and to access network storage drives.

    Now, I'm a contractor (not of the highly paid variety, unfortunately) and am technically paid by Initech's corporate master, Outertech. Sometime last year, it was determined that, for unspecified administrative reasons, all Outertech contractors must have an id on the Outertech domain, SCKST. (No, I cannot explain the domain name.) So, all us contractors got new ids of the form SCKST\xi246810. All contractors had to have their laptops "migrated" to the new domain, which required them to be taken away for several hours.

    The first of my colleagues whose laptops underwent this process found various side effects, including the inability to access servers, email or network storage drives, and the revocation of local administrator privileges. This did not stop the IT department from attempting to pick up other people's laptops for the same purpose, and my immediate supervisor had to order everyone not to allow this until they fixed the first laptops to the extent that my colleagues could do their jobs. The result was that by the time my laptop was migrated, the major difficulties had been solved. I still had to log in with my old INTC id to get email, although this was later solved by a second migration, changing us to a new email server.

    We're still working on getting access to all the servers we work on with our SCKST ids, and must use the old ones on some servers. The network-drive-access problem was "fixed" by the advent of a VBScript that runs automatically whenever I log in with my SCKST id, and I have to enter my INTC id and password in two InputBoxes (both unmasked) so that it can map the drives with correct credentials. I understood originally that the drive ownership would eventually be changed so that this would become unnecessary. However, I am now being told that the original domain change might possibly not have been legal (no, I don't understand how that can be), which would require reverting everything to the way it was before.

    The third login came about a part of a project involving some data on a server in a foreign country that is both generated and used by people here. (That entire project probably represents a WTF of its own.) It took a couple of weeks to get any kind of access to that server, and I wasn't able to get in until I realized that, instead of granting the access to my INTC\x123456 id as I had understood, they had gone ahead and created a new id, MXINTC\x123456. I am not sure if there were legitimate problems with granting access to an id from outside the domain (network admin isn't really my area of expertise), or if there was some kind of language or moron problem, but now all work on that project (which may now be cancelled anyway after several weeks of work) must be done using a third ID.

    Did all of that make sense? If so, can you explain it to me?



  • SCKST is clearly the word "SUCKIEST" with all the vowels removed.

    Also, as for MXINTC, is this data in Mexico by any chance?



  • @Robert_Morson said:

    SCKST. (No, I cannot explain the domain name)

    Well that's simple. You start with AAAAA, then when the domain controller shits itself and it turns out there are no backups, you move to AAAAB...



  • Yes, Mexico. That name makes sense; it's just Mexican Initech. It's the other one that it unrelated to any name I know. Actually, since I anonymized this one without knowing what the original letters stood for, maybe it is unintentionally suckiest. (It's entirely possible that the original stands for something in Spanish, which of course I wouldn't understand.)


  • kills Dumbledore

    Socksite. You work for @accalia


  • FoxDev

    @Jaloopa said:

    Socksite

    what? wait! no!

    for one thing i don't own the socksite domain..... :-P



  • @Robert_Morson said:

    Did all of that make sense? If so, can you explain it to me?

    Your explanation makes sense. I've suffered through companies where my login was a serial number as well; gives you that nice "concentration camp" feeling first thing in the morning when you log in.

    The companies refusal to set up a trust relationship between the domains does not make sense.


  • :belt_onion:

    Well it's obviously insecure to trust another domain, so they must.... MUST be kept seperate.

    Yeah, it makes no sense. Sounds like these guys don't really know what they're doing.......



  • I have often thought that they don't know what they're doing. The fact that I don't know what a trust relationship is (other than what I can guess from the name) or how to set one up somehow doesn't invalidate this feeling.



  • @Robert_Morson said:

    The fact that I don't know what a trust relationship is

    A trust relationship is a mechanism that allows the computers in one domain to "work with" the domain controllers in another domain to validate a user account that is from that other domain. Without trusts, every domain is an island.

    It's important to note that trust relationships don't give any permissions. You will either grant or deny permissions to a user depending on your needs, not depending on what your software allows. If you want person X, who normally uses stuff in domain Y to use something in domain Z, then you have two basic courses of action.

    1. Do something to make it possible to grant person X permissions in domain Z. This is what a trust is.
    2. Create a domain Z account for the person.

    Note that #2 is another account with separate password policies, history enforcement, admin staff to unlock accounts, etc. Even worse, the user doesn't interactively log into their computer with this account, so they never get a password expiration reminder. Depending on how the user connects, they might not even have the ability to know if the "must change password" flag is set, and/or may not even have a mechanism to change the password. Those are just some of the technical challenges - on the human end you get problems like "how does the user remember many passwords?" Some people handle this well - many people create security nightmares.

    All these down sides so an admin somewhere can say "I don't want him to use that account, who knows what policies that admin has set". What the admin forgets is that the best he can hope for is that the user sets all his passwords the same and therefore never has to write any of them down. In this case, if any of them are compromised, then all of them are compromised - so that initial worry about that other admin still apply, since if that other guy screws up badly enough, an attacker gets the user's "universal password" and admin 2's system gets accessed anyways. That's the best case. Worst case is that the user chooses different passwords for each, but the user can't remember all the passwords - so he puts them in an Excel spreadsheet and accidentally stores it on a shared drive. Even if the users doesn't make a mistake that colossal, pretty much any potential place the user might put a password is less secure than how Active Directory secures passwords by default.

    The last place I worked, suggesting a system store accounts any where other than the one official repository managed by the Identity Management Team, would get you a serious hand-smack during architecture review. If your solution absolutely required it due to technical reasons, then you had to get a variance from one of a very small group of people who were allowed to grant them. Where I work today, putting clear-text passwords in database tables is seen as "troubleshooter-friendly".



  • @Jaime said:

    putting clear-text passwords in database tables is seen as "troubleshooter-friendly".

    I see trouble, and somebody needs to be shot.



  • Thanks, Jamie. Yeah, it does seem like the Mexican domain doesn't trust the US ones. The two in the US sort of work together, -- you can get permissions on a INTC-domain server for a SCKST-domain id if you go through the proper morons channels, but I've not been able to do the same for the Mexican domain.



  • @HardwareGeek said:

    @Jaime said:
    putting clear-text passwords in database tables is seen as "troubleshooter-friendly".

    I see trouble, and somebody needs to be shot.

    Is see opportunities…



  • @gleemonk said:

    @HardwareGeek said:
    @Jaime said:
    putting clear-text passwords in database tables is seen as "troubleshooter-friendly".

    I see trouble, and somebody needs to be shot.

    Is see opportunities…

    If the opportunities you see involve shooting, I don't want to know anything about it.

    Filed under:



  • Hmm, on an unrelated incident here I googld an MD5 hash I'd found in some test data. Turns out the password wasn't entirely trivial but actually one of some old test accounts we'd have configured on systems (HAHAA NOT A WTF BECAUSE I SAY SO). Some site (written in cyrillic) knew about that hash and the plain text for the hash in 2011! NOT GOOD.

    I found a forum where one user posted five hashes along with usernames, and got an answer with the reverse MD5 for four of them. 2011 must have been around the time we'd finally implemented salted and iterated SHA1. For legacy reasons some DB still have MD5 hashed passwords in them to this day. So yay for enabling attackers.

    Say I searched for 0807520eb3739939ae409fab8350cb03, then found this question

    foo: 0807520eb3739939ae409fab8350cb03
    bar: 86f12932d3285fdcbf19535a72f58916
    baz: 048174b32585600de39d65335b257d92
    admin: 7f76b2c6375938af1c2fe1221869015c
    shmoe: 14b6e2a1a21e684d80495e0376af8817

    where the answer was

    0807520eb3739939ae409fab8350cb03 : testfoo
    86f12932d3285fdcbf19535a72f58916 : testbar
    048174b32585600de39d65335b257d92 : testbaz
    14b6e2a1a21e684d80495e0376af8817: shmoe

    So :wtf: shmoe wise choice of password.

    Trouble is, I don't know what DB they pulled those entries from, or who shmoe is.

    @HardwareGeek said:

    Filed under:

    I... do not. Googl is my rainbow.



  • @Jaime said:

    putting clear-text passwords in database tables is seen as "trouble, shooter- friendly".

    Fixed.



  • Non random-salted password hashes have been a WTF since the... late 80s at least. MD5 as the hash algorithm has been a WTF since the early 2000s at least (more likely late 90s).



  • But look how convenient now I know one of our customers had their DB stolen.



  • @powerlord said:

    MD5 as the hash algorithm has been a WTF since the early 2000s at least

    I'd put that WTF as beginning with the introduction of bcrypt in 1999.


Log in to reply