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.
I guess paranoia sell product, 'In every one of your applications'. Not everyone uses closed source, and any administrator that hardcodes in passwords should be fired. No new bit of technology is going to help you, if all you use it crap.
I think I just cashed out all my cool points.
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. -
What area of Tokyo is this in? Quite honestly, I've never really worried about "safety" in Tokyo. (Then again, I work on the south side of Chicago and don't think a whole lot about "safety" ;)
My other car is first.
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.
ALL applications DO NOT have built in unchangeable passwords, some may, but most dont. Stating ALL apps have a certain feature is plain crazy - unless you have written every app that exists on the planet.
Free Blog submission, find blogs, tools and more at LS Blogs
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.
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
Disclaimer:I work for Configuresoft
Configuresoft http://www.configuresoft.com/ has some great software called ECM for managing continuous compliance standards like SOX, PCI DSS, HIPAA, etc. ECM is in use in 9 of the 25 biggest companies in the world. We even have clients on RedHat and Solaris.
That said, we see companies with the blank password problem all the time. We do compliance assessments (pre-sales) where we ask the CIO and IT management a question like, "How many of your servers have admin-level accounts with blank passwords?" They, of course, say they have none, unless they are honest, in which case, they admit that they do not know. We do our assessment and give the CIO a report that shows 1-2% of the servers have accounts with blank passwords and maybe 50-75% have accounts with passwords older than a year.
Going through an audit sucks, but it sucks less when you can hand some canned reports to the auditors for at least a portion of the audit.
Ummm, Jon, aren't you supposed to be dead...? - Otter(3800)
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.
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
Now that the haughty quote has been delivered, I have the attorney's attention. Aside from everybody writing down their login password somewhere and subverting your agressive security, there's probably some other vulnerability in your network that could prove to make a daily password rotation useless.
And it's very stressful for people to change their passwords every day, especially if you're using advanced rules (mandating at least X of the 4 character categories, minimum length, not the same as previously used, etc.). My suggestion is to have everybody install apg so they don't have to waste 30 minutes every day thinking of a password that your Novell eDirectory will allow for usage. Biweekly or weekly is more than frequent enough. Daily is insane.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
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
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.
s. 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?
Did you RTFA? It isn't about passwords "folks" use to access applications. It is about the passwords that applications use to access other applications, and the fact that changing these passwords risks downtimes but not changing them means that anyone with access to the source code or configuration has access to your data collections.
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.
Trojan horses -- the definitive answer
My favorite quote from Dennis Ritchie:
"I promise that no such thing has ever been included in any distributed version of Unix. However, this took place about the time that NSA was first acquiring the system, and there was considerable temptation."
Yes, that one had definite potential for abuse. How's your favorite closed source C compiler doing these days? :)
The best way to predict the future is to create it. - Peter Drucker.
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
"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.
My favorite is the one Dell forces onto corporate customers so they can support them:
Username: admindell
Password: delladmin
All applications have got pre-defined passwords that never change.
All is a pretty strong word. It kinda makes that sentence complete horse shit.
I've actually heard that in Japan garbage disposals are illegal because it takes too much water and additional wastewater processing to handle the food (as opposed to trash...which is also a problem for Japan, they incinerate almost everything because there isn't space for landfills). I also seem to recall that disposals are not permitted in NYC because the sewer system is old and couldn't handle the additional solid waste there.
for a company which handled a LOT of oil industry data. They had a windoze domain admin account for sophos to do it's stuff to all the pcs. The password was 'antivirus' an audit team got it on their third guess.
This is really a bunch of total crap. I have worked in many different areas, and in any real business, people are not hard-coding backend-system-passwords into their code. They are specified in configuration files. The article is probably written by some consultant trying to sell that "digital vaulting technology". Whatever that is.
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
As you read the article, the first thing you note is really that this "trusted" person may still be able to authenticate after he leaves his job. The problem is not that the password never expires, but that his account never expires or there is just one shared account.
Any system that requires authentication should also require identification, and each account should expire at some time. It should be posible to lock individuals out without imposing change of password on all other authorized users.
In fact never expiring passwords may increase security in everyday systems: When people are regularly required to change their passwords chances are that they will choose even worse passwords, simply because it takes time to find and learn a good password.
Repeated change of password gives no protection against brute force attack simply because you have no idea wether the hacker will go sequentially through all posibilities or if the new password has already been tried and hence has low probability of being tried again.
Instead, system administrators should make sure that chosen passwords has sufficiently high entropy before they are accepted in the first place and continuously try to crack user passwords - if a password is cracked, it is weak and must be changed.
Its been said previously on /. that the best thing to do is make your password the same as your cats name. Mine is 25@jDWQ0! and I change her name every thirty days.
"Flags are bits of colored cloth that governments use first to shrink-wrap people's brains..."
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!
an ordinary md5 gives you more than enough for now.
No. First of all, why use an insecure hash function when a more secure one is just as convenient? MD5 should no longer be recommended for any use. Second, you have to salt before hashing. Thirdly, it's a good idea to iterate the hash function at least a few thousand times - this makes a dictionary attack computationally more expensive. This is all "key stretching" as described in Schneier et al's paper on low-entropy keys.
Where passwords are used for network authentication, you should ideally combine these measures with a protocol like SRP.
Xenu loves you!
In the city I live, I did some warwalking to test kismac and for at least 70% of the networks, you could just enter the IP address of the router and the user/pass would be the default ones, allowing you to remotely control it from any browser. How comes people do not realize? I thought of dropping a note in the mailboxes of companies with badly configured wireless networks saying something like:
"hello, did you know that the user/pass of your router is ***** / *****? Yeah, so do I. You should considering changing it".
"Words of wisdom: drop that zero and get with the hero" -- Vanilla Ice
If you can retrieve the password how can you tell a user their information is secure?
The first rule of password security for me is that there is no way to retrieve the password from the system. If that cannot be done then you have no security at all.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
Only member of the Simpsons family with a name long enough for most password schemes (at least 6 characters)?
Seems reasonable enough to me.
How about the security of the password management in browsers? I mean, if you share your computer IE, AFAIK, doesn't even allow you to password protect your passwords. Firefox lets you do this, but just exactly how safe is it??
I work for a IT firm and, though we give the strong password speech regularly, some of our clients are so opposed to having to do something as difficult as remembering a password that we let them keep their insecurity rather than risk losing business. I wish it were possible to be hard line and just force people to use strong passwords; but, when they can fire us for doing so; it seems a little quixotic. Until end users are willing to accept that they, personally, need to take some responsibility for their data security, all of this will continue to be a joke. After all, Wells Fargo comes by their house and makes sure their doors are locked and the alarm is set everytime they leave home. Why shouldn't Symantec to the same for their PCs?
WARNING: Smoking this sig may cause lowered IQ, insanity or short term memory loss. It is also really bad for your monit
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.