Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Security Encryption

The Unspoken Taboo - The Never Expiring Password 537

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."
This discussion has been archived. No new comments can be posted.

The Unspoken Taboo - The Never Expiring Password

Comments Filter:
  • by Strokke ( 772031 ) on Friday December 09, 2005 @12:56AM (#14216682)
    but I feel the need to expose the world's most sophisticated software. The password....is "password"
  • guilty (Score:5, Informative)

    by LiquidMind ( 150126 ) on Friday December 09, 2005 @01:00AM (#14216707)
    how many of us computer-savvy are guilty of doing this for our login accounts, web banking, Email, etc? I know i am.
    • Re:guilty (Score:5, Interesting)

      by ATeamMrT ( 935933 ) on Friday December 09, 2005 @01:09AM (#14216771)
      how many of us computer-savvy are guilty of doing this for our login accounts, web banking, Email, etc? I know i am.

      I am not a cracker or hacker. But I know a guy who uses password trading websites for porn. According to him, once you get a password for one porn website, that same password will work for others. According to him, these porn members use the same password for all sites they subscribe to.

      Once companies start losing money to crackers/hackers, then they will start issuing more complex security.

      • Re:guilty (Score:5, Interesting)

        by Anonymous Crowhead ( 577505 ) on Friday December 09, 2005 @01:16AM (#14216812)
        I used to work for a free adult hosting site. We stored the passwords in plain text in a database. One day, just for the hell of it, I pulled out the top ten passwords. They accounted for something like 40-45% of the passwords for more than 250,000 accounts.
        • Re:guilty (Score:4, Funny)

          by Anne_Nonymous ( 313852 ) on Friday December 09, 2005 @01:34AM (#14216898) Homepage Journal
          >> adult hosting site. One day, just for the hell of it, I pulled out the top ten passwords.

          Drum roll please, Anton...

          10. Wank
          9. Jerk
          8. Milk
          7. Yank
          6. Spank
          5. Rub
          4. Beat
          3. Whack
          2. Jack
           
          ...and the number one porno password...

          1. Off
        • Re:guilty (Score:5, Informative)

          by JWSmythe ( 446288 ) * <`moc.ehtymswj' `ta' `ehtymswj'> on Friday December 09, 2005 @02:02AM (#14216999) Homepage Journal
            This is always a fun game.  I won't say what site it's for, but it is adult.  This is the top 20 from 600,000 expired accounts.  Checking the top 1000 common passwords, I don't see a single strong one.  I know, it shouldn't, since I'm grouping by count.  I suspect this list will apply almost everywhere in very similar ratio's.

          SELECT COUNT(pass) AS count, pass
          FROM `users`
          WHERE expired = 1
          GROUP BY pass
          ORDER BY count DESC

          | count | PASSWORD    |
          |  1322 |    password |
          |   994 |      123456 |
          |   824 |       12345 |
          |   569 |      harley |
          |   536 |      696969 |
          |   434 |     mustang |
          |   385 |      qwerty |
          |   355 |    baseball |
          |   307 |    football |
          |   305 |      hunter |
          |   305 |     letmein |
          |   296 |      shadow |
          |   294 |       pussy |
          |   279 |      maggie |
          |   276 |      monkey |
          |   265 |      golfer |
          |   260 |      buster |
          |   260 |    12345678 |
          |   255 |      bandit |
          |   241 |      nascar |

          When a site password is compromised, the system automagically sets a strong password, and notifies the user.  They get rather upset about that.  I tell them, "You should have used a good password to start with."  We will let them change it back to something else, but we won't let them use anything easy.

          • Re:guilty (Score:5, Insightful)

            by moro_666 ( 414422 ) <kulminaator&gmail,com> on Friday December 09, 2005 @03:17AM (#14217283) Homepage
            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 ....)
            • Storing passwords (Score:3, Interesting)

              by Paul Crowley ( 837 )
              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 n
          • 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.
          • 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...
      • Re:guilty (Score:4, Informative)

        by JWSmythe ( 446288 ) * <`moc.ehtymswj' `ta' `ehtymswj'> on Friday December 09, 2005 @02:17AM (#14217071) Homepage Journal
        Your friend was full of shit. Well, mostly.

            Some sites allow users to select their username, some don't. Some set arbitrary passwords, some don't.

            If you're real lucky, you may find a combination like "user:pass". But why should anyone think someone who has the username of "bullshit" has the password of "my_password", and everyone who's chosen the username of "bullshit" would select the same one.

            We've had many users complain that their username was taken. It's always funny too, on common first names, or something simple like that. How many username "bob" can there be? ;)

            More than likely, he's finding multiple sites in the same 'family' of sites. I've seen that happen before. Buying a membership at one site will allow access to many, usually because they use the same password file on the same server. :) In those cases, obviously it will work.

            The password sites do work though.

            I've become very familar with passwordz sites over the years. We were hit pretty hard when we started doing one of the largest on the Internet. We have a bot who builds pretty interesting reports for us, and I had included the sites which we were linked on.

            Most people are using something like 'AccessDiver'. Many sites now set firewall rules against IP's using those tools, start showing them a bogus valid login page, or any of a number of tricks to mess with them. I know some of the 'hackers' were using multiple proxies after a while, but really, when you have to do tens of thousands of attempts to even think you're getting one password, how many proxies could you possibly have at your disposal.

            When we see x number of attempts come in from an IP, it gets blocked. If we see that a valid password was acquired in the attempes from that IP, we automatically change that password, and notify the user. We have a few other tricks too. I very rarely see our sites showing up any more, simply because by the time they get a password posted, it's no longer any good. It does the same thing to the casual 'hacker', so if you start scanning through multiple proxies and leave for a while, when you get back, you still won't have a good password. :)

            I use hacker in quotes above, because they're not real hackers. They're barely crackers. I classify them with script kiddies. They found a tool, run it, and now they've accomplished something with no work. They don't know how it happened, they just know it did.

    • I know i am.

      That's good to know. Thanks.
    • Re:guilty (Score:4, Insightful)

      by patio11 ( 857072 ) on Friday December 09, 2005 @02:02AM (#14217002)
      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.
      • Re:guilty (Score:4, Interesting)

        by AdamWill ( 604569 ) on Friday December 09, 2005 @03:57AM (#14217418) Homepage
        Mine's a completely random 12-character string. My passwords for every other website (and other password-protected things) I use are also (different) random 12-character strings. They're all stored in my password storage app (gpass), which is protected by one extremely strong password I spent five minutes memorising (and will change next month). This whole thing only took about two hours to set up, and it's certainly worth it in terms of peace of mind.
        • Re:guilty (Score:5, Funny)

          by thebiggs ( 625489 ) on Friday December 09, 2005 @11:41AM (#14219853)
          My password is a 256 character random string intialized by digitizing the braying of six donkeys on a semi-daily rotating basis. Once the braying is digitized, and the seven-factor hash table is used to generate the string, it is transfered via secured lasercable to the memory unit of a Sony Aibo. The Aibo has been specially modified with a woodburning unit, and the password is then burned onto a piece of burnished cherry wood, which I am then allowed to view for exactly twelve seconds before it is ground into a very fine sawdust.

          All of this takes place behind a triple-secure double-blind firewall, inside a bunker which is encased in twenty-three feet of reinforced concrete and surrounded by a moat with biometrically activated piranhas.
  • The most dangerous? (Score:5, Informative)

    by JabberWokky ( 19442 ) <slashdot.com@timewarp.org> on Friday December 09, 2005 @01:00AM (#14216709) Homepage Journal
    I'd say the most dangerous is an unchanged [phenoelit.de] default password [cirt.net].

    --
    Evan

    • Potential Trump (Score:3, Interesting)

      by btarval ( 874919 )
      That's truly a worthy contender. But I'm surprised there's been no mention of Ken Thompson's original hack of the C preprocessor. Here's an link:

      Trojan horses -- the definitive answer [google.com]

      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 favorit

  • Oh no! (Score:5, Funny)

    by Anonymous Coward on Friday December 09, 2005 @01:02AM (#14216715)
    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.
    • Re:Oh no! (Score:4, Interesting)

      by JWSmythe ( 446288 ) * <`moc.ehtymswj' `ta' `ehtymswj'> on Friday December 09, 2005 @02:39AM (#14217145) Homepage Journal
      > The locksmith just changed my locks! Did he keep a copy? Is he trustworthy? I don't know... Shit!

          I always like this.. A good locksmith would know how to pick the lock. A smart locksmith would have noticed that you leave your downstairs window unlocked.

          My father used to tell me, locks are for honest people. I agree.

          Several times, in nicer office buildings, I've found myself locked out of offices where I should be allowed. They use a special 'security' key, which is one or two tumblers longer than a regular key. I've opened them in about 10 seconds with a car key and a credit card. Sometimes I've found it easier to just pop the drop ceiling out, and climb over the wall too, assuming there is no firewall between point A and point B. Usually inside offices don't have them.

          But, when it comes down to it, if I wanted to get into your house badly enough, I'd just kick in the door. I have yet to find anyone who uses a New York deadbolt other than me. :)

          I went to a "secure" facility a few weeks ago. I was inside a 'mantrap', waiting to be allowed through. I started laughing at the guard, after he took too long to let me through. The guard didn't understand why. Their "security" guard was behind 2 inch thick security glass. The frame around it was steel. The door had steel bars on it, and a pry guard. He pointed all of this out to me, and I laughed again.

          Someone had swung the door open too far a few times, and knocked a grapefruit size hole in the drywall. I knocked on the wall right under the bullet proof window. It was just more drywall. I then asked "What would happen if I shot through here? What would happen if I knocked a hole in the wall, and put 12v to the door latch solinoid? I would be in, and no one would find you until shift change."

          Ok, it could have been other voltages, I was just screwing with him. :)

          Ya.. There aren't too many places that are really 'secure'. It's simply a matter of how much risk a person is willing to accept in the entry to said facility. In the above case, it was easier to ask "will you please open the door now?" He stopped giving me grief every time I came through. He already knew I was authorized.
      • Re:Oh no! (Score:3, Interesting)

        by Punk Walrus ( 582794 )
        I always like this.. A good locksmith would know how to pick the lock. A smart locksmith would have noticed that you leave your downstairs window unlocked.

        As someone who used to cut keys for duplication, this is not really true. First, 90% of the door keys I cut were one of two blanks: sc1 (Schlage) or kw1 (Kwikset). While they were supposed to keep an eye on blank inventory (we sent back "bad cuts" for credit), that was unrealistic for the most common models; they ship you the keys by weight, not by nu

  • Security Guy (Score:4, Insightful)

    by superpulpsicle ( 533373 ) on Friday December 09, 2005 @01:02AM (#14216716)
    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.

  • All applications have got pre-defined passwords that never change

    Huh? What applications have these?

  • Huh? (Score:3, Insightful)

    by Anonymous Coward on Friday December 09, 2005 @01:02AM (#14216721)
    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 (Score:5, Funny)

    by Leebert ( 1694 ) on Friday December 09, 2005 @01:03AM (#14216727)
    !seineew era sreenigne epacsteN
  • by Anonymous Coward on Friday December 09, 2005 @01:03AM (#14216728)
    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.
  • by 1984 ( 56406 ) on Friday December 09, 2005 @01:03AM (#14216730)
    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.
    • by raehl ( 609729 ) <raehl311@noSpAm.yahoo.com> on Friday December 09, 2005 @01:37AM (#14216905) Homepage
      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?
    • by jpostel ( 114922 )
      Disclaimer:I work for Configuresoft

      Configuresoft http://www.configuresoft.com/ [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 acco
  • by ATeamMrT ( 935933 ) on Friday December 09, 2005 @01:03AM (#14216731)
    All applications have got pre-defined passwords that never change.

    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.

    • 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 m
    • ...that will give a cracker access...

      What makes you so sure he's white?
    • by Klaruz ( 734 ) on Friday December 09, 2005 @02:07AM (#14217025)
      I think you and the mods missed the point. So how does tomcat talk to mysql? Do you use a password? Trust the IP? Bind to 127.0.0.1 or Unix sockets only?

      The idea that instead of USERS having passwords, the APPLICATIONS do now. You can't just auto lock them out after a certain amount of time with no change, if somebody forgets to change the password, you're down. So you've got s3cr3t456 hard coded in the data source config of your app, who's gonna change that? You better have procedures in place, and you better keep that config file locked down since you have a powerful DB account password in plain text in your front end app server. Some vendors obtusify that password with what looks like encryption, but unless you've set it up right and enter a password each time you start the app server, it's still trivial to decrypt.

      Another sticky problem is access to the data is no longer controlled by the RDBMS, since that application account needs wide open access. One security hole in your in house written app can trash any part the application could need to write to. If you use the security/roles in an DB you can restricted access to the data to a much finer level. Principal of least access and all... Unfortunatly, that's how things used to be done and in the land of middleware aren't anymore.

      I wrote a custom data source for a servlet once that would auth each user using the account in the db and connect as them to the db. It really breaks how server side java is supposed to work though. One of the big ideas of J2EE is you're supposed to move almost all the logic that used to be data related in the DB up a layer into the middleware. It helps sun take customers from big DB vendors, but makes real world security much harder.

      It's a sticky set of problems in todays world, with no widely accepted solutions.

      • I think you and the mods missed the point. So how does tomcat talk to mysql? Do you use a password? Trust the IP? Bind to 127.0.0.1 or Unix sockets only?

        Umm.. all my web applications use a password that I set in an xml configuration file. If I needed to change the password I'd change it in the database, change it in the config file, and restart the app. Anyone that's hard coding passwords into the application is an idiot and should be fired.

        You better have procedures in place, and you better keep that con
      • So you've got s3cr3t456 hard coded in the data source config of your app, who's gonna change that?

        I've got to ask: what kind of muppet hard codes the passwords into the app, when grabbing them from a [configuration file / registry setting / whatever] is so trivially easy?

        The article talks about doing a recompile / QA / release cycle to update passwords. WTF?
  • by Chris Bradshaw ( 933608 ) on Friday December 09, 2005 @01:04AM (#14216733)
    And of course, this posting wouldn't be complete without a list well know default passwords and appliances...

    http://www.governmentsecurity.org/articles/Default LoginsandPasswordsforNetworkedDevices.php [governmentsecurity.org]

  • by Linegod ( 9952 ) <pasnakNO@SPAMwarpedsystems.sk.ca> on Friday December 09, 2005 @01:04AM (#14216736) Homepage Journal
    "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?
    • by s1ashd0twh0r3 ( 936321 ) on Friday December 09, 2005 @01:07AM (#14216755)
      What decade was this article written in? Who the hell 'hard codes' a user id and password into web based applications?

      It was written in 1972, back when all web-based applications were written in machine code. Don't you know anything about computer history?

      • I must have slept through the part where web apps where around in 1972 also :)

        Damn, this means I missed the part where the web, and all reference to it, was removed in 1976 in order to appease the new rulers of Earth - who then removed all reference to themselves in 1981.

    • It still happens. I know, because in the course of administering systems, I've seen a number of things that do this.

      One very simplistic and small example is a Perl CGI script that accesses the localhost MySQL server. Something that looked like this:
      $mysql_login = "foo";
      $mysql_passwd = "bar";

      Well, how was it going to handle the database login? If not in the script, then in a file? And if it's in a file, then is that file any bit more secure than the script--instead of hard-coding into the script, you'll
  • by ravenspear ( 756059 ) on Friday December 09, 2005 @01:05AM (#14216741)
    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.
    • Indeed... I've seen a real nightmare where people have been forced to change their password monthly. Over half of them used the current month, sometimes with a digit appended.

      One place I was at had enforced complex random passwords. Nobody could remember them so the admin password was on a sticky note by the admins desk, similarly for all the user passwords.

      Changing passwords is not a panacea.
  • 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.
  • abolish passwords.

    makes logging in much quicker, too.
  • by twitter ( 104583 ) on Friday December 09, 2005 @01:22AM (#14216834) Homepage Journal
    So where is this wide open back door? In every one of your applications.

    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.

  • This is just a result of poor coding practices. Good coding practices ensure that any authentication details (login/password) are not embedded in the application.
  • passwords (Score:2, Informative)

    by lsblogs ( 818271 )
    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.
  • by QuantGuy ( 654249 ) on Friday December 09, 2005 @01:27AM (#14216863)

    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...

    • 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

  • .. 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.
  • Missing the Point (Score:5, Insightful)

    by Baricom ( 763970 ) on Friday December 09, 2005 @01:40AM (#14216917)
    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.
  • XYZZY (Score:3, Interesting)

    by Senor Wences ( 242975 ) on Friday December 09, 2005 @01:43AM (#14216926)
    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....
  • by Ruff_ilb ( 769396 ) on Friday December 09, 2005 @01:45AM (#14216937) Homepage
    "
        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".

    "
  • No, we don't... (Score:4, Insightful)

    by bergeron76 ( 176351 ) on Friday December 09, 2005 @01:56AM (#14216979)
    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].

  • by Jaxoreth ( 208176 ) on Friday December 09, 2005 @02:04AM (#14217012)

    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 [w3.org] to this problem was proposed through the W3C about six years ago, but it hasn't been implemented that I'm aware of.

  • by zenst ( 558964 ) on Friday December 09, 2005 @02:20AM (#14217083) Homepage Journal
    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.
  • Misconceptions (Score:4, Interesting)

    by The Raven ( 30575 ) * on Friday December 09, 2005 @02:55AM (#14217212) Homepage
    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
    • Re:Misconceptions (Score:3, Insightful)

      by Vellmont ( 569020 )

      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.
  • Fluffy (Score:5, Funny)

    by quokkapox ( 847798 ) <quokkapox@gmail.com> on Friday December 09, 2005 @03:13AM (#14217273)
    The best security strategy is to simply use your cat's name as your password.

    As long as you rename your cat frequently.

    I just wish z8gderfgh wouldn't claw the furniture all the time.

  • Is He Serious? (Score:3, Insightful)

    by Bob9113 ( 14996 ) on Friday December 09, 2005 @04:31AM (#14217512) Homepage
    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?
  • by erik_norgaard ( 692400 ) on Friday December 09, 2005 @05:05AM (#14217615) Homepage
    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.
  • by Greg@RageNet ( 39860 ) on Friday December 09, 2005 @05:28AM (#14217686) Homepage
    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
  • by ylikone ( 589264 ) on Friday December 09, 2005 @09:59AM (#14218781) Homepage
    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.
  • I Call Bullshit (Score:5, Insightful)

    by npsimons ( 32752 ) on Friday December 09, 2005 @11:20AM (#14219606) Homepage Journal
    I am what I would consider a "security savvy professional", and I have to say that making people change passwords is the most time-wasting, useless, feel good security measure ever. You know why? Because people will pick easy to remember (and easier to crack) passwords rather than good passwords when they won't have time to memorize a good one. Or to look at it another way: why pick a good password when you are just going to be forced to change it? I know this is true, because I have experienced it from the other side; I am a user who is forced to change his password on a regular basis. On those accounts which force me to change my password (usually every 6 months), I won't even try to pick a good password. I'll pick one that meets the bare minimum requirements, because I'm just going to have to change it again in another six months. Why bother trying to create a good password?


    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.

We can predict everything, except the future.

Working...