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."
but I feel the need to expose the world's most sophisticated software. The password....is "password"
how many of us computer-savvy are guilty of doing this for our login accounts, web banking, Email, etc? I know i am.
This sig contains repetition and redundancy.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
The locksmith just changed my locks! Did he keep a copy? Is he trustworthy? I don't know... Shit! All applications have passwords? Could someone tell me how to hack notepad? I forgot I needed a password. Someone must have left it unlocked on my rig. Probably a hacker.
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."
!seineew era sreenigne epacsteN
After IT enforced monthly changing passwords requiring so many letters with numbers in between, now I write it on a post-it note and stick it on the monitor.
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.
http://www.governmentsecurity.org/articles/Default LoginsandPasswordsforNetworkedDevices.php
Get your Windows Malicious Software Removal Tool Here for FREE! - http://fedora.redhat.com
"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.
"Huh? What applications have these?"
Solitare, Minesweeper, Frogger.
What those who want activist courts fear is rule by the people.
"...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. -
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...
If the new way is so good, how come the world wasn't going to hell before? Did Enron and Worldcom go bust because the passwords wern't changed? Or did they go bust because our government coddles corporate criminals - in the cases suits stealing money is even illegal in the first place.
I can understand mandating a security protocol for systems that protect information subject to privacy. But if I have a company, and the only thing on my computers is my company's design information, my company should be able to choose the appropriate level of security for our business.
Why is a password that a user has committed to memory that never changes worse than a password that changes every three months that a user has to write down?
paintball
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 remember first using Apple Network Assistant to administer a network of Macs. The default password was 'XYZZY' which is, of course, the 'password' for Zork. Fortunately, even back when said network was a mix of OS 7.6.1 and 8.1 Macs, the Zork reference was too far in the past for the middle school students to even have a clue about....
End of Line
No link? I call BS. I live in Tokyo, and the idea of a building not being marketable for this reason is silly. They would have just installed a new security system and that would have been the end of it - the cost of redoing the security system compared with the potential losses of unoccupied apartments is negligible. Developers here aren't that dumb.
With property prices the way they are here, if it was really 'bargain basement' prices, they would have sold regardless of the problem.
"
Many years ago I was acting as the system administrator for a test system in a large publicly held company. Periodically I would receive a call from someone who had not accessed the system recently, forgot their password and locked themselves out trying to logon. I would look up their password and unlock the system for them and they would go on their merry way.
One day I received a call from a young lady who was in just such a predicament. I looked up her password and informed her that it was 'DOME' and, just to be playful, told her the price for me being gracious enough to unlock her sign-on was an explanation of the meaning of her password. She became very embarrassed over the phone and pleaded that she could never reveal her secret. I of course replied that I would not give her system access until she did. After negotiating for several minutes she finally acquiesced but made me promise to never reveal her password meaning to any of her colleagues to which I gladly agreed.
"Well, what does it mean?", I asked.
She hesitated and then replied, "It's two words."
There was pregnant pause. I unlocked her system and simply said, "Have a nice day".
"
http://www.TheGamerNation.com/Forums
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.
Any Web site offering you an account of some kind requires authentication, invariably in the form of username and password. Many users will just reuse the same username and password. Those that don't must use a password manager, whether it's the Web browser's autofill or a real, live, dead-tree notepad.
Most of these sites require you to transmit your password in the clear. So not only does the Web site operator have your password (which could be used to compromise your account on other sites if it's the same), but so does anybody sniffing your network.
Both of these problems would disappear if we used public keys to authenticate. You generate a key pair, and supply the same public key everywhere when creating an account. Your browser acts as the key agent (or connects to one like ssh-agent) and uses the private key to respond to an authentication challenge. No password is sent to the server, ever.
HTTP Digest authentication also neither transmits nor stores cleartext passwords, but the Web site operator does have to have it to set the password in the first place. HTTP authentication in general currently suffers from the problem that there's no specified way to log out. A solution to this problem was proposed through the W3C about six years ago, but it hasn't been implemented that I'm aware of.
In general, it is safe and legal to kill your children. -- POSIX Programmer's Guide
In general, it is safe and legal to kill your children. -- POSIX Programmer's Guide
Couldn't they just intall locks?
No, of course not. That would ruin the story.
I've notice many people here are misunderstanding the article. While the article does incorrectly state that 'all applications have hard coded passwords', I think what he meant was that 'nearly all applications that access secure resources over a network have hard coded passwords', and this is quite likely true.
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. When was the last time that password was updated? And that, in theory, is easy to do because the web app isn't compiled and it's stored in a single location.
Another common scenario is a compiled Intranet app to, say, access Inventory information from a central database. It's common to have hardcoded logins to the database or web servers in apps like this. In fact, almost any app that does not require a user login, but does access secure resources, probably has a hardcoded login stored inside somewhere. Legions of these apps were coded by programmers who may be very competant, but are not security aware... they could well be stored plaintext right in the binary.
So the article may have been overgeneralizing, but it was quite accurate when it comes to business software.
The Raven
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
As long as you rename your cat frequently.
I just wish z8gderfgh wouldn't claw the furniture all the time.
it's a blue bright blue Saturday hey hey
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