- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Or a large soulless corporate conglomerate which has reams of documented, draconian IT policies that are largely unenforced and ignored.
Admin
My first job was with a Big Faceless Company that had just brought in a team to revamp security. They put all sorts of sophisticated measures in place, including it took three separate user ids and passwords to get on the system, and the passwords were changed every month. Everyone was grumbling about what a pain all this new security was. And it's not like there were a lot of spies out there desperate to know how much it cost us to make a blender or when we would next order half-inch screws.
One day I was searching through the files when I stumbled across "system.log." ... something or other. Curious, I opened this file -- and in it was a log of sign-ons, including date, time, terminal id, user id, and a text string that looked a lot like a password. I scrolled through until I found an entry for me. And sure enough, there in a file accessible to anybody on the network, was everyone's user name and password in plain text. (Anyone who'd logged on in the last few days, anyway.) I was thinking of putting together a memo to send to the security team, listing each person's user id and password, and saying "Please confirm that this is your correct password and then pass this on to the next person on the list." A co-worker talked me out of it.
Admin
I've worked for small companies; at one of them, I was the IT manager.
I learned quickly that you can't save everyone. What you CAN do, is present the costs and benefits of a security policy/action/system, and then leave the decision to Those That Can Make Decisions. One of two things will happen:
When they don't adopt it, and you've made your case, then your responsibility ends. Yes, it's bad for the company. Yes, it's your job to manage these risks. No, you can't do what needs to be done because you're not in charge, and those in charge won't let you do your job.
When, inevitably, there's a problem, of course they'll come and tear you a new orifice over it, since it was your responsibility. At that point, there are several possibilities:
While you'd think 1 would be the preferred outcome, 2 is actually preferable to me, as you can tell future employers that you presented a solution to the problem before it happened. You weren't allowed to implement it, resulting in a breach that could have been prevented, and were made a scapegoat for the problem. Also, you can collect unemployment benefits if they fire you.
Either 2 or 3 results in your no longer working for a company that doesn't allow people to do their jobs because of ignorance, and you're better off not there.
In my case, there were a couple of things the company did while I was there that make me glad that I got laid off:
They decided that to save money, they'd use a VoIP system for the office phones. Not a bad idea, really, but if you do that, you have to make sure your internet access is reliable, lest you lose a five-figure sale because the phones drop out. They insisted on using a 'business class' cablemodem for all access, including the phones. Needless to say, it dropped out at random two or three times a day, resulting in the following conversation:
"Otto, the phones dropped out!" "Yes, I know. Try it now." "OK they're back again, why did that happen" "The cablemodem froze up." "Why?" "Ask Comcast, they've been here ten times and haven't been able to fix it."
The solution I provided was to get a real t1 line at an additional expenditure of $300 per month. It was too much money, and The Boss wouldn't sign a contract. So I had the above conversation several times a week.
Then, since part of my duties was to maintain and extend the company's web site, I found it stunningly insane that there was no development server, and all changes were made on the production server directly. (No source control, either. I overwrote four hours of the VP's work because we were working on the same file.) I managed to crowbar the $500 it took for me to build a Fedora machine out of The Boss, but was not allowed to set up a system for deploying changes overnight. The reason? "We want to be able to tell our clients their changes will be on the site immediately."
The solution was "Don't tell them that, tell them the changes will be there tomorrow morning after testing." Unacceptable. The dev server sat there doing nothing.
Needless to say, they went Chapter 11 due to horrendous financial mismanagement. They took "penny wise, pound foolish" to previously unheard of levels.
Admin
I'm surprised at the comments excusing the company's behavior. Then again, not really. I've seen similar behavior at a couple places where I've worked.
The problem is that if something bad is done, suspicion naturally lies on the account holder. The fact that everyone had the account password doesn't seem to mitigate the situation much.
If someone logs in to your account during the night and (badly) attempts embezzlement, you're going to find yourself fired long before you can find out what happened. If you live in a "right to work" state, you pretty much have zero recourse. And "fired under suspicion of embezzlement" looks bad no matter how ridiculous that suspicion might be.
Admin
I agree that this isn't all that uncommon a situation in a startup. My current employer has only been around for about 3 years. All of our SQL servers have a DBO account that is used by dev, test, and production, and the password has never been changed. I'm not sure if it was an oversight to use it in production, or just a time saver, as I wasn't here when the decision was made. At this point, we can't easily change it because it gets used in so many places in our code that to do so will mean significant dev and test time dedicated to something that won't increase revenue. And when you're trying to get off the ground, revenue is everything. Still, we realize it's a problem, and there's a work item scheduled to fix it in the next release.
Admin
Aaannnddd... <cue TRWTF music>
I've co-founded/worked for two different "raw startups" over the past 3 years or so. In both cases we did things "right" (in terms of security, source control, etc.) from day one. Technical stupidity should not be the downfall of your company - you'll have enough management-level screwups as it is.
Admin
Still remember the company I worked at where user logins were all synced to the same password so the "Administrator could get into your comp when needed". I changed my password one day however and nobody seemed to care...but after enough IT gripes worthy of the daily wtf about that company I finally left too...
Admin
I work for a small company that has shared email folders. We have individual addresses, but they're all deliberately set up so that everyone in sales can see each other's inboxes, same for production, etc. It's odd, but we've come to like it, especially when we need to address issues quickly and the person who normally handles it is gone for the day. Plus there's an email search database to retrieve anything ever written. It works well for a small company that relies heavily on email for communication with our customers. Management/HR stuff is sectioned off, though, we're not that stupid. As for the rest of us, it keeps us honest.
In my opinion, the WTF here isn't the unsecured email accounts so much as the general attitude towards security. Surely the boss doesn't need to see everyone's email... and if he does, surely he doesn't actually need their password to do so, and if he does, surely he could keep a list rather than forcing them to use the same one!
Admin
Sorry, my own experience with just such a place is that they think that anyone who comes up with good security ideas must be a devious and untrustworthy person. I was at such a place for about three months and all attempts to suggest anything resembling effective backup procedures and/or security measures were met with blowoffs, and, eventually, comments about what kind of mindset it takes to think of such things. Yes, I'm serious, as absurd as that sounds. I shook my head as I walked away from that job.
Admin
I agree with Akatherder -- some companies are small enough to get away with non-security; it just never comes up on the radar.
It reminds me of a Foundstone Security class I took. They were talking about security in web stores, and in their example, the shopping cart math was being calculated client-side -- obviously a huge security hole. They intercepted the request with a proxy, edited some fields, and "bought" ten textbooks for a dollar to show how bad the system was. The problem with their example? The store was for a mom-and-pop outfit that obviously had the owners hand-shipping every item. If they see a receipt for five bucks, they're not just going to blindly stick a dozen books in a box and drop it in the mail. I'm not saying the online store shouldn't have been fixed, but the way it was being used made up for its shortcomings.
Admin
A few years ago, I briefly worked with a very large business in the UK, who will remain nameless. They had a similar policy: All accounts set up with a standardised password that never expired.
Usernames were standardised too, taken from initials and surnames and so on. Consequently, anybody who'd been exposed to the business' processes for more than a few minutes would know how to use any other person's account, as long as they knew that person's name.
(This had been going on for years: I found a long-time employee who'd never got round to setting up a new account when they arrived at the business, and just shared a colleague's account.)
An attacker or disgruntled employee could easily have done all kinds of naughty things in the name of the CEO, or finance director, or HR, or whoever. However, the retail chain is still trading so I presume the worst hasn't happened, for whatever reason :-)
Admin
Get away from here...
Admin
I think the WTF here is the fact the guy left. Small companies work very differently to large companies in my experience. The trust scheme tends to work quite well and if there are problems then you are usually welcome to fix the problem.
There isn't necessarily the skill set in larger companies, so if this guy had been able to fix it, then he should have.
I feel sorry for the guy that left, it sounds like it was a company that got things done.
Admin
Come on. We're talking about common sense here. Doing security half-decently isn't for "big soulless companies", it's for anyone with more than two people. And the situation described in the post doesn't show a lack of effort or a "we don't need that" attitude; it just shows a lack of competence. It's downright stupid. Doing it right would require hardly any work, and would provide real benefits, so the fact that it wasn't done right shows that someone has no clue how to do it right. I would run too.
Admin
there are large companies who give all users admin rights. Although I'm sure there are costs associated with this, I don't think there are lots of security violations going on because of it.
Oh I could tell you of another company trying to do encryption on the cheap and once they started using it a lot of users died.... ah well.
Admin
I've found the cause to be that the encryption 'driver' intercepts calls to the hard disc and does its cypher-magic in unallocated memory; but the programmers neglected not to create an exception not to encrypt the swap file on the hard disc ...
The workaround was to disable virtual memory, but this led directly to a big-blue vendor's tech-support answering calls about 'error: the swap file too small' ...
Admin
Alright, so I'm a couple years late responding, but... I agree, this is a wtf, but a pretty minor one. Having a password to your login that everyone in the company knows is weird (why even have logins, then?), but... it's nice to know you're trusted, and that you can trust everyone else. We have logins here, complete with passwords we're allowed to change to our liking, but... for instance, by default, everyone in development here can access the root of everyone else in development's hard drive. Which has been great when, say, someone broke the build cause they forgot a file - it's much nicer to come in and hear that you forgot a file, but don't worry, someone located the file and committed it for you.
The honor system is pretty great. (But everyone sharing the same password to their standard login is still a wtf. As opposed to, say, everyone knowing the admin login to a particular server, but not using it unless they needed it.)