Slashdot Mirror
The Unspoken Taboo - The Never Expiring Password
anon writes "Every security savvy professional lives with the daily fear of the "never expiring password" being exposed. It's the unspoken taboo, the wide open back door in every corporate network. But no-one ever acknowledges it or discusses it. All applications have got pre-defined passwords that never change. Which means developers, privileged users and hosting third party service providers will all have access to these passwords."
I have never met a security eng who work more than 4 years in the same company. I am convinced the streets are flooded with people who know the security schemes of their previous employers. Which IMHO is worst than knowing the never changing passwords.
What? This certainly isn't the case where I work. I'd say it's a pretty big leap to assume that "every corporate network" has a wide open back door and "all applications have got pre-defined passwords."
Actually for US companies, due to compliance with Sarbanes Oxley and Payment Card Industry DSS standards, the problems the article talks about -- unchanging inter- and intra-application credentials -- are (getting) less of an issue.
SOx is horribly aspecific, and boils down to "you'd better be doing the right thing". The irony of audit company failings leading to an audit company boom aside, that means auditors are scared, pedantic and detailed. In the case of our auditors that includes frequent, documented changes to passwords for both human and machine users, including all applications and components thereof. It's been a pain to implement because people have been used to systems working as TFA states. It's also quite a resource suck to go through each password change cycle. But doing so is best practice that was ignored in the past for the sake of expediency, and now it's enforced with a big stick. As an IT professional, that's not entirely unwelcome.
Are they sure about that?
So where is this wide open back door? In every one of your applications.
These guys are paranoid.
Tell me that Apache/Tomcat has some secret passwords that will give a cracker access to my server. Or MySQL has a secret password that gives root access. Every app I can think of can have passwords changed, and none have hard coded passwords.
This is much ado about nothing.
"Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes."
What decade was this article written in? Who the hell 'hard codes' a user id and password into web based applications?
-- I care not for your foolish signatures.
The never expiring password might be bad, but I think security policies that enforce password expiration after too short a period are perhaps even worse, because they lead to insecure passwords being selected. Never changing a password can certainly be a security risk, but if it is a very secure password, that is still better than rotated ones that are constantly insecure IMO.
No kidding? Do you have any links to info about said building?
It seems like unhardcoding it would be a lot less expensive than wasted real estate in Tokyo. Sounds like a great way to make a fortune!
"...because there is no safety available if you live there."
Couldn't they just intall locks?
Is that credible? Got any links? Seems to me that if a developer built the whole building and paid for some elaborate security system, they could have gotten *someone* to fix the damned thing (or replace the head units) and sue the company that sold it in the meantime.
Any why would it be vacant at bargain basement prices? You're telling me there's nobody in Tokyo that would love a cheap apartment that's fully featured whom isn't rich enough to pass on it? I'd move in, install some pad-locks, and my own security system for a couple hundred. Good enough for me, for a bargain basement price..
- It's not the Macs I hate. It's Digg users. -
Use physical keys (possible also with a password). If SecurID is too expensive (it's a bit pricey for small companies) it's not hard to chuck something together with a U3 key or even a simple USB key.
No it's not. That's one of the major reasons to use free software and one of the best reasons to use a carefully audited free software distribution like Debian. Backdoors are just one of the nasty things that you can check for with an army of careful volunteers.
The only place I've really seen bad practices like this is with expensive closed source junk that gets shared out with Windoze users. The passwords are to prevent access to the program itself, how backward! There's hardly a point to using SSH on such a buggy and exploited platform as Windoze and Windoze lacks X forwarding, so few bother to use anything but telnet and ftp. They try to protect the kludge by putting it behind a firewall and locking down the wireless to the point of uselessness, but people walk their laptops in and out and something is always broken, everything is slow and full of popups. What a cesspool. I don't even want to think about what I've seen "upgrading" banks because I'm going to bed soon and don't want nighmares.
By way of contrast, my home network is all free. A gateway computer shares the network out, rather than restricts access into it. People are welcome to plug into my open wireless router, because they will see the same thing any of the other 250,000,000 internet users do. I've been running this way since 2000 or so and have yet to have a real problem.
Friends don't help friends install M$ junk.
Maybe I'm missing something. It's conventional wisdom that "best practice" is that "everyone" should change their password every x number of days. But often times folks have to change their passwords so often they end up writing them on sticky notes, or choosing the same easy eight-character password over and over and over, with the only variant being the numbers stuck at the end. And this is good for security how?
At a previous company our policy was to have fairly long (16 character) passwords that never expired. For my own password, I chose a pnemonic one that had certain combinations of substituted numbers and special characters. It was never cracked, even though we ran password scans regularly on our Windows domain and Linux boxen.
Show me the empirical evidence that frequently-changing, short passwords are better than long, unchanging ones, and not only will I change my password, but I might even change my mind as well. Until then articles like this are just perpetuating a mythology that people have come to accept as fact.
As it happens, I think passwords have outlived their usefulness. But that's another thread entirely...
.. and Locks only keep honest people honest.
Frankly someone walking away from a live terminal is more dangerous. That's when an "honest" person, or someone with good intentions will make a mess.
Proof by very large bribes. QED.
Actually, the top dogs are the worst. Not only are the passwords simple, never change, and are written on post-its, they also tell me in idle conversation while I provide deskside support that it is the same password for their banking and stock websites. If only I wore a different hat. . .
What a lot of replies on this post are missing is that TFA is discussing passwords for programs to log in to other programs. It has nothing to do with user passwords.
What? You didn't read the article? Oh. Never mind.
I can fairly confidently say that all my important apps, open and closed source, have no hidden backdoors. Most simply have no oppertunity to have one, a video editor, for example, does not run any services much less any Internet services, thus nothing to get in through. For the servers, I am unconcerned because of the intense amount of scruitny. I mean sure, in theory a closed source server like IIS could have a master back door. In theory even Apache could have a back door snuck in as per Ken Tomphson's method with a C compiler (http://www.acm.org/classics/sep95/). However that's extremely unlikely in both cases.
Why? Well products like that face an extreme amount of scrutiny. Hackers, good and bad, are trying to break in all the time. We know this, because every once and awhile they succede via a bug that gets patched. Well, such a universal backdoor would very likely be discovered by these people. After all, no matter how well you try to obfuscate it, the traces will be there in disassembled code and yes, people DO pour over that looking for ways in.
I'm sure some apps have universal backdoors, but I'd bet they are pretty few and far between. There's simply no reason in most cases, and the discovery of such a thing would really shoot to hell the credibility of the company that made the software.
All applications have got pre-defined passwords that never change.
Then put them on their own network segment and mitigate their risk potential.
Much like most other networks, my network is a hybrid *nix/OS X/Win environment. I limit my damage potential by putting the [potentially] dipshit software on it's own segment. I limit the potential for damage further by only buying solutions that are sane (aka *nix based; because it has a 35 year history of being secure) or by buying solutions that offer SLA's that cover damages (very rare in the non-*nix world).
I work in a call-center, and our company will lose tens of thousands of dollars _each hour_ that our phone system is down. Our phone system is embedded hardware, but it still has legacy Windows "requirements". So, rather than trust those Windows machines, I isolate them and the damage they can do. The SLA contract guarantees us that if those Windows machines crash because they "caught a cold and couldn't infect anyone else, so they infected themselves to death", our company doesn't lose money [aka, spambots that can't get out].
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
Raise your hand if your slashdot password would flunk any "best practice" ever invented and is also used on at least 100 other internet sites for a similar login. Guilty here, and been guilty since high school. I only bother with strong passwords for email and anything that has enough access to my data to cost me money.
Help poke pirates in the eyepatch, arr.
Of all the pentests i've done the number of colo box's (mostly the mainframes and applications on box's) have.....default passwords still active. generaly there not disabled nd all the colo/customer does is add there own on top ignoring the defaults.
john the ripper on mainframes, as/400's - tend not to see that level of pre-emptive checking.
As a rule as a admin you should constantly try cracking your own systems passwords, each one you get that user owes you beer. Least they can do for potentialy saving there job and your company.
With the technology available today, the best answer to the password problem is get rid of it. Users would be given a personal certificate from a an issuing authority that is chained to a central controlling authority. The personal cert public key would be associated with a user account or some other system that uses ACL security. That personal cert private key would be 'burned' to some sort of portable media like an ID card or thumb drive. When the private key is burned to the media, a PIN is associated with it. Resoures that the user would need access to would be secured using the user account which now has an association with the cert. To access the resource, the user would be prompted to insert or attach the media with their private key and type in their short PIN number. When they are done, they take their media and leave. Of course there is much more back end crap that goes with this, but it does work if implemented correctly. The only BIG downside to this is physical security of the device which contains the private key...but it's the same concept as an ATM card that has access to your checking account as long as you have a simple 4 digit PIN...
-- SMTP: Spam and Malware Transfer Protocol. Also used on rare occasion to transmit e-mail messages.
which word in the clause "never keep unencrypted passwords around since you dont need them" didn't your application authors understand ?
....)
never keep the passwords as plain text fields, if someone hacks your server, gets the password and then abuses the matching password on their bank accounts/(or elsewhere), you will be the dumb lamb that will be sued for letting their secrets out.
encrypt passwords and be safe, an ordinary md5 gives you more than enough for now.
i'd get my ass fired if someone would discover that i even considered saving passwords as plain text.
ps. for the password story itself, on a windows platform which is terrorized by zillion spyware items, i suggest you never change your password, as the spybot authors know it before your disk synchronizes the changes to disk (keyloggers, blah
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
For example, Apache has no hard coded passwords. But... what if you have your web application accessing a MySQL database on a different server? Well, then you need to login to that MySQL database. The password is stored in your web app. And that, in theory, is easy to do because the web app isn't compiled and it's stored in a single location.
Any webapp written in Java most certainly is compiled. Even if you're using a non-compiled languages you're an idiot if you hard code passwords into the application. It takes what, about 5-10 minutes of extra work to make it minimally configurable?
When was the last time that password was updated?
Hopefully the last time someone with access to the passwords left. Otherwise what's the point? Changing a secure password adds no security. It's like changing the locks on your car every 6 months "just in case someone copied my key". This is especially true for passwords of applications where there's no one typing it in, using it somewhere else, etc.
Legions of these apps were coded by programmers who may be very competant, but are not security aware...
Yah, I think that's actually what the article is getting at. It's a terrible problem and I find no excuse for it other than incompetence. I bet it's often hard to convince the middle managers to spend money on adding password configuration to an app that fully functions. That's the real problem here.
AccountKiller
Well, by the time it hits anywhere that is relatively public, it's encrypted in some fashion. Since most places need to be able to do a password recovery, it has to be in something more open than md5. People get all pissy when they can't get their password back when they forget it.
Even if you do really have a need to keep the passwords around for recovery, that is still no excuse to store them unencrypted in the database. It's big time amatuer hour, and I agree with the GP who calls it grounds for being fired for incompetence. God only knows how many other problems your application has, if this is level of care you take in protecting passwords. Please, find a new line of work.
Well, by the time it hits anywhere that is relatively public, it's encrypted in some fashion. Since most places need to be able to do a password recovery, it has to be in something more open than md5. People get all pissy when they can't get their password back when they forget it.
Why not just reset their password to something random, like everyone else? You aren't doing anyone any favors by storing their passwords as plain text.
In order for these applications to get access to data, they have to "logon" to the systems and applications that store the data, and since the credentials to logon are in the application, they are embedded in the code. Now since it is clearly impractical to rewrite applications on a regular basis, just to change the user ID and password, the result is that the user ID and password never changes.
Really? OK, here's a simple solution to the problem: When someone hard codes a password that controls access to sensitive data such that the application has to be recompiled to change the password, fire them. Problem solved. There's no excuse for hard coding passwords, and I can't think of anyone I have worked with in the past five years that has suggested doing such an idiotic thing on a sensitive application. I've seen plenty of system accounts, but the credentials are always loaded at runtime (either from a file or the command line).
Is this really common? I'm pretty sure I've worked with my fair share of chimps over the years, but not anyone that stupid. Have I been dodging dumb bullets?
Stop-Prism.org: Opt Out of Surveillance
Look, let me bring some flippin reality to this whole security thing..
The only thing that stands between you and total compromise is a brick and a person with the willpower to put it through your window.
Are never-expiring passwords not so great? yeah. but what's the alternative? The friggin recomended password policies that are generated by the so called security experts are something along the lines of using a completely unique password for every situation, make each of those passwords not be any combination of numbers and letters that could be remotely construed as a real word in your native language, make sure it's nothing personally identifying, and change it once a month.
In other words have totally unrememberable passwords! And oh by the way don't write them down!
It's a completely unworkable system and if you enforce password policy systematically.. guess what? your users are forced to write the passwords down and then the people who instigate 85% of all unathorized accesses (your own employees) just need to look for the yellow postits near the keyboards.
-- Greg
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
Only member of the Simpsons family with a name long enough for most password schemes (at least 6 characters)?
Seems reasonable enough to me.
I know the head IT guy of a certain company that sets the root password on all his servers to be the same 6 letter word that he also uses for all the web apps and databases I develop for him. I tell him he should really REALLY not do that... but he keeps doing it. I am just a contract worker for him, so I don't have the power to change them. He's had various servers hacked about 3 times in the last 4 years, leading to much panic and re-installing and backup restorations... but yet he doesn't change his ways! And updating software and security patches on his servers?... forget about it, I think he's still using the same system as the first day it was setup.
Meh.
The first rule of evaluating security vulnerability should be this:
There are ate least three clear optimistic assumptions in the very first clause of the sentence I quoted partially. (1) That you can rely upon demarking "public" and "private" places. (2) That your organization can trust completely people inside the security perimeter (e.g. you just published a rather nice guide to cracking passwords at your employer). (3) That the users in your organization should trust the organization and employees inside the security perimeter. An example of the first would be a sql injection attack that causes the password table to be dumped.
You should secure secret information as early in the process as humanly possible. This means that passwords should never be stored in a database. If I could convince people it was worth the effort, I'd avoid sending plaintext passwords at all over the wire, and I would avoid sending unencrypted password equivalent hashes as well.
Since most places need to be able to do a password recovery, it has to be in something more open than md5.
I disagree. There's seldom a reason to do password recovery, especially in a system that can tolerate a "super user" administrator who can assign privileges to any object or reset passwords to whatever he likes. In systems that can't tolerate this, then users can reasonably be required not to lose their passwords, biometrics and security access tokens.
People get all pissy when they can't get their password back when they forget it.
Well, I don't see why: "OK, I just set your password to 19651001 -- your birthday. After you log in, you should change it to something you'll remember." What they should get pissy over when you can amass a file on how they choose their passwords.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
On the other hand, on systems I administer, I don't have expiring passwords. I pick passwords that are 20 characters long and look like line noise. Sure, it's harder to memorize them, but I have more _time_ to memorize them because I never have to change them.
Nathan's blog
I think the key thing here is the importance of security for you and for them. Why should they care if their porn site access is compromised? It doesn't affect them at all if someone else views pictures under their user name. From their point of view, you're the ones obstructing access by changing their password on them. Of course, from your point of view, the compromised accounts are lost revenue. It's all relative, you see. Especially on those incest sites...
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.