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."
Somewhere in Tokyo there was a brand new apartment building put up with state of the art everything. Video screen doorbells, plush elevators, garbage disposals, efficient kitchens, the works.
But when it was found out that someone had already broken in using the non-reprogrammable security password, the price floor fell right out from under the developer. Now there is a relatively vacant apartment building in Tokyo with all the trimmings for bargain basement prices because there is no safety available if you live there.
Jesus saved me from my past. He can save you as well.
This is case on specialised hardware & software where there is no ubiquitous access. You can disable the alarm but you have to be there at the moment and it's most likely "ringing" already. I believe the weekly-changing-password-taped-under-the-keyboard IS ubiquitous (in Certain ranks) and yet it requires the same level of physical access as the first scenario. At my school, the CS dept, "rebeled" against the School's IT policy of 90 day changing password, we are now given never-expiring passwords. No one forgets them, no one writes them down and it stays that way.
Rule 2: Writing a spec is like writing code for a brain to execute.
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.
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.
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.
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)
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
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
They were the obvious - password, 12345, qwerty, sex. I can't remember any more (it was 5 years ago). I think password and 12345 were 1 and 2.
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
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 hard-code it into a file. It's better, but not really much better. There really isn't a good way around this problem.
Think about it... how else would you handle something as simple as a PHP or Perl script accessing the local database? The user supplies data to log in to access the script, not the database. There really isn't any other way.
> 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.
Serious? Seriousness is well above my pay grade.
When I took my current position, I implemented a new password policy (changed every 120 days, among other rules). There was the usual resistance, and somebody pointed out that this would just lead to people putting post-it notes on their monitor, and anybody with a key to the building could get that password.
My response was that somebody trusts these people well enough to give them a *key to the building*. I think I can trust them better than I can trust the people on the internet.
We've had zero successful break-ins since the new policy was implemented a few years ago. Before that, I'm told that we were hacked at least once every 6 months, always because of a cracked password. I can't say that the password policy was the sole reason for the change in that trend, because I implemented a number of other security measures as well (like using ssh instead of telnet), but I'm sure it helped!
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 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 number.
Next, I usually had the ID of the person I cut the keys for. I mean, we'd call them to tell them their new keys were ready, but the theory was that we kept this for law purposes (not sure if that was true, but that's what the corporation told us). All I had to do was cut one extra key, and hope that your address is the one the key goes to. After all, I'd know when you were out: I'd call you to come pick the keys up, tell my full timer I'd be right back...
Not that anyone I know at my store ever did that. But it seemed too easy. We didn't do background checks, either.
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.
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.
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
The locksmith just changed my locks! Did he keep a copy?
Much of the security of doors is in the exposure you face while trying to break in. In comparison, the Internet gives almost total safety to a break-in attempt.
It sure doesn't have to be all that insecure.
/., actually -- perhaps I should do something about it).
I could even tell you my never expiring password, and it wouldn't make any difference - you wouldn't be able to use it.
I use the same password on almost every site, with a few distinct exceptions (like
Why?
The keyword of the day is 'seeding'.
I've compiled my own cryptoalghorithm to obscure my standard passord into unique passwords for every site I register at. I use a seedword related to each site in conjunction with my standardized password, and thus gets an unique password for each site.
So say I register at a site which is comprimised. Now the attacker has my obscured password. The attacker would still need my algorithm to be able to figure out what my password is on all the other sites I'm registered at (or have a large quantity of the passwords and start the good ol nuclear powered password cracker). Say someone gets a hold of my algorithm and is smart enough to figure out that 'ebay.com' is the logical seed for ebay.com, now they would still need my original password.
1. Obscurity
2. Security
3. ???
4. Profit!
> Raise your hand if your slashdot password would flunk any "best practice" ever invented
My slashdot password is weak, but that's an indication of the value of my slashdot account. If it is compromised, the perpetrator gets the use of a slashdot account (something he also could get just by, uhm, signing up), and I lose... what, maybe some of my reputation on slashdot? I think I'd live through it. Worst case scenario, the perpetrator changes the password *and* changes the email address for the account, so I permanently lose the ability to use my preferred username on the site in question; he could also try to impersonate me, but if the email address changes, who's he going to fool that knows me -- and what does it matter if he "fools" someone who doesn't know me into thinking he's the "real jonadab"? He gets the username, but beyond that... ? It's really a complete non-issue.
I reserve strong passwords for situations wherein they're actually warranted. I've got *enough* twenty-character mixed-case passwords with punctuation in them in my head as it is, some of which actually *matter* (well, relatively speaking; they're not for nuclear missile systems or anything). The last thing I need is to add a bunch more for protecting minor stuff like my slashdot account.
What scares me, in terms of weak passwords, is a scenario like what we have at work, wherein there are weak passwords hardcoded into the application for full access to our database, which contains the personal data for every single one of our patrons; the password in question is *extremely* weak (i.e., weak in at least three distinct ways (non-complex, identical to its corresponding username, and based on a word closely associated with the product)) inherently, and additionally is known to at *least* the IT staff (and probably more than that) of not just our software vendor but also every single one of their customers (who, incidentally, also have access to the complete customer list on the customer extranet). This is a PR disaster of epic proportions waiting to happen for us, not to mention a legal nightmare in the making, and there is nothing we can do about it, short of switching vendors. We didn't find out any of this until after we'd signed a multi-year contract for tens of thousands of dollars that we absolutely cannot afford, financially, to back out of. We can't change the password, because then the application won't work, since it's hardcoded there. Worse, we can't firewall the server off from the rest of our network, because the application requires that everything (and, in particular, the ports on which the database listens) be open from every staff workstation to the server, or the application won't work. We do have the whole network firewalled off from the outside world, but there's no defense in depth at all, and there's a big fat hole in the firewall through port 80, which the application needs to expose to the outside world for important parts of its functionality. The service listening on 80 is, you guessed it, IIS.
Additionally, there is a clause in our contract with the vendor that absolves them of *all* responsibility for our systems' security and specifies that if anything goes wrong, we have to pay *them* x number of dollars per hour to fix it. I am not making this up. I highlighted that and went to our director and said, point blank, "Don't sign the contract with this clause in it." So naturally she asked them about it, and they explained (verbally) that it's not a problem, the clause is only in there because some sites refuse to run antivirus software, and if we keep our antivirus up to date we won't have a problem, and no site has ever had a problem if they had antivirus protection. She *believed* them and signed the contract, because she's a director, not a paranoid systems administrator.
It's not mainly us that I'm worried about. We're a small-time outfit in a small city, not a target for anyone beyond the level of bored students fooling around. What scares me is that I know, deep down inside, that our vendor isn't the only vendor that pulls this sort of [language fails me; no word is foul enough].
Cut that out, or I will ship you to Norilsk in a box.
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 work for a large company (200k+ employees) and we have what can only be described as anal retentive security and administration. These guys do absolutely everything exactly the way they are supposed to as far as adminstration staff is concerned, but several things have become apparant to me over the last few years.
First: Having a super strong IT department won't prevent virus outbreaks. We got hit with a SoBig variant and it damn near put us out of commission for a day. The reason wasn't because the virus caused serious harm to our infrastructure (it didn't, we were almost unaffected by it), it was because our global IT folks, in their infinite wisdom, decided to lock down all the routers everywhere to prevent the worm from spreading. The result was that we were incapable of doing any of our normal business activities for one day. Using the facility I work at as typical, and extrapolating accross the entire company, this cost us about $2,000,000. The key to remember, was that it wasn't the worm that caused the loss, it was the IT reaction to it. They did "nothing wrong". Everything was done by the book, but from my experience the textbook reactions to these things need to be re-examined.
Second: Virtually every department in my company uses back door passwords just like the ones refered to in the article. We use them to a huge extent simply because we have a massive data infrastructure that is decades old and needs to interoperate seemlessly. There isn't anyone within the company who has any real grasp on how the whole system works together. For anyone who says that security through obscurity isn't the answer, I call bullshit. Security through obscurity is the single *most effective* method out there, and when coupled with other more active measures produces a system which is stronger than any system which does not include security through obscurity. The people who wrote pieces of the systems we use, don't understand the system well enough to make effective work arounds, much less exploit the system. The result is that we leave many "generic" accounts open using a standard pattern so that anyone in any department will know how to access business critical data in any other department. This keeps the employees productive even when moved to a new department, which happens quite frequently.
Third: Passwords and account tracking at my company are not so much intended to prevent outsiders from gaining access to our data, but are geared more towards knowing who did access what data, in the event that anyone ever wanted to know. That is not how the IT department wants it to work, but with hundreds of thousands of employees and a centralized standardized IT department, there is no way they can effectively administrate all these computer system, so they settle for being able to track what happened after the fact.
last, it should be noted that our systems have proved remarkably resillient to attack, and penetration. Critical systems such as our web site (which takes in excess of 100M hits / day), and a very few others are more closely guarded than most, but generally speaking no one pays any attention to security inside the company, becuase no one has the time, and despite that we have not had any real problems that couldn't have been simply ignored.
-=Geoskd
www.geoskd.com
I wish I had a good sig, but all the good ones are copyrighted