Passwords May Be Weakest Link 529
blankmange writes "ZDNet is carrying a piece on network security and employee passwords: "When a regional health care company called in network protection firm Neohapsis to find the vulnerabilities in its systems, the Chicago-based security company knew a sure place to look. Retrieving the password file from one of the health care company's servers, the consulting firm put "John the Ripper," a well-known cracking program, on the case. While well-chosen passwords could take years--if not decades--of computer time to crack, it took the program only an hour to decipher 30 percent of the passwords for the nearly 10,000 accounts listed in the file." Sounds like enforced password formats and mandatory changing of passwords would help, but how many companies actually make them policy and enforce it?"
The problem with forced passwords: (Score:2, Insightful)
The problem with strong passwords... (Score:3, Insightful)
Preferrably on post-it notes and stuck to the keyboard or the screen.
I have seen it all.
I've heard this before... (Score:3, Insightful)
Password are not the weakest link (Score:3, Insightful)
Expiring Passwords (Score:2, Insightful)
Yah! Stick it to the users! (Score:4, Insightful)
Give a look at any paper by Sasse, Brostoff and Adams, such as this one [mdx.ac.uk], and then re-think your sysadmin I-never-change-my-dictionary-password-but-I-force
The answer is not to forget the human aspect. Find a better way to help users generate better passwords, through education and assistance, not automated password rules, and forced password expiry.
Not neccessarily (Score:3, Insightful)
Now "dictionary word" -> "easy to remember" -> "insecure" but that doesn't imply "insecure" -> "easy to remember". Far from it in my opinion.
EnkiduEOT
That's no surprise (Score:3, Insightful)
Mother's maiden name is too obvious. But what about just any random name, or maybe a confirmation name (if you're Catholic)? For example, my confirmation name is Anthony. Here's what we do. We reverse the characters, and it becomes ynohtna. Let's remove the vowels. We get ynhtn. Screw around with case. Make it YnHtN. Then throw some easy to remember chain of numbers in there. For example, the last 4 digits of your phone number (0799 for me.) So it becomes Y0n7H9t9N - a password that would take weeks to bruteforce, and can be remembered fairly easily with a bit of practice.
Also consider biometrics. But the problem with biometric input devices is if your password is cracked, you can't really change it...
I've rigged up a
But hey, if you have your password set to PASSWORD, let me tell you, you're asking for it.
-Evan
Re:Very good analysis. (Score:3, Insightful)
Users are.
No matter how good a password is, it can be compromised *instantly* if someone can use social engineering to either get it from the owner (e.g., "Hey, I need your password to check if this works...") or get the Sysadmin to change it back (e.g., "I am thusandso and I forgot my password, could you reset it for me please? I need to get some work done this evening but cannot log on..."
It's like with home security and a lock on a door. A weak lock can be forced or may even be left unlocked, but even a set of high-quality dead-bolts can fail if someone on the inside opens the door to let the intruder in or decides to leave a set of keys under the mat.
Humans are the weakest link, not passwords.
Single sign-on : the big lie! (Score:2, Insightful)
NT scores here (Score:3, Insightful)
But this is definitely one of the few areas where NT/2K still scores over (most) Unices (as far as I know, please cluestick me if I'm wrong...) , namely it's trivially easy to enforce finely grained password policies. On NT, it's a case of find the dialog, check the options you want to apply , enter some numbers (length to time to remember old passwords and reject them, how often to force changes), minimum length, whether to force uppercase/ digits / alpha-numericals etc. I've been using Linux, BSD and Solaris for three years professionally, and tinkering at home for several years before that, and I frankly wouldn't know where to start to enforce password policies. (Well, OK, I'd use Google, the LDP, how-tos etc, but you see my point.)
That said, I just installed Mandrkae 8.3 out of curiousity to see what a Windows-friendly distro looks like, and I'm VERY impressed. Bob Young is wrong - IMHO - I think Linux
Re:Here's the problem with that: (Score:2, Insightful)
Security (for your users, or at least me) is one aspect of an overall goal: getting our jobs done. If someone hacks into my system and trashes all of my files, that will time and energy away from other work. If I have to unlock the safe under my desk, pull out the notebook containing 16-character one-time passwords and punch one in every time I want to check my e-mail, that also will take time and energy from other work.
Remember always to balance the security you use with the value of the secured valuables. For a health-services company the value of the information is (perhaps) much higher than for your average "senior civil servant".
Also, don't put 15 deadbolts on the (virtual) front door while leaving the (virtual) window next to it wide open. I would guess that a lot of organizations have lost more proprietary information by viruses attaching documents to outgoing e-mails than by crackers breaking in.
Re:Shadow passwords (Score:2, Insightful)
Actually, truth be told they are over dramatising somewhat : Whilst (tribute to the other reply
Re:Here's the problem with that: (Score:3, Insightful)
Is your firm being paid any less due to customer dissatisfaction?
If the answer is no, then you are being abused by your management. They should throw out strong password complaints when evaluating customer satisfaction.
Surely the civil service organization has a policy about the use of strong passwords. I believe all Federal organizations have such a policy, if this is state or local, maybe not, I guess. Not insisting on implementation of policy would possibly be a cause of legal action against your company should there be problems.
I suspect this is a convenient way for your company to hold on to your bonuses.
Necessary Strength is Relative (Score:5, Insightful)
Depending on who you are, and what context you're in, the answers could be totally different. And depending on that context, the strength of your password may matter a lot, or not at all.
If you're just some schmoe in marketing, with no access to change anything on your personal system, no access to anything on the company network except to alter files in a personal directory on one server, your company's network does not allow remote access, and your building requires a card to get inside and another one to get up the elevator, then the importance of you choosing a strong password is relatively small.
Making people choose strong passwords is a computer based version of a tradition risk-reward scenario. Users are going to hate keeping track of multiple passwords, with mixed case, numbers, special characters, and then throwing it all away and remembering a new one every 60 days. The reward of doing it has to outweigh that risk. Unfortunately I haven't gotten the feeling that either in this article or on many of the people here take into account the relative nature of computer security.
One of the key questions that need to be asked before a password policy is defined and implemented is what are we securing and how valuable is it? How devestating would it be if people got access to it, and how would one go about getting that access? In most of the cases that people have mentioned, the items being secured are potentially not that critical/confidential/valuable and therefore the importance of a strong password is significantly diminished.
Similarly, writing down passwords is more or less of a problem depending on where your threats are coming from, and what that password secures. I am not worried that the root password to my linux box at home is written down and taped to the box itself. Or even that it says "Root Password" right above it. It's securely formatted and difficult to guess, there's not a whole lot of important/critical info on the machine, and my main threat is coming from a random person on the network outside, not from someone specifically targeting me and breaking into my room to read the paper taped to my machine.
Memorizing multiple truly secure passwords on a rotating basis are a pain in the ass. Before you force everyone on your network to do it, sit down for a second, think about how your systems and permissions are set up, and make sure that that pain is truly necessary. If it is, you will have a solid, business based reason why, and will be easily able to explain and convince others of your position. But implementing it because it's what someone told you is the "right" way to secure a system is lazy, and because people won't see the value, they'll shortcut it anyway.
zzzzzzzz (Score:5, Insightful)
Easy to remember passwords -> crackable.
Heard it all before. Only thing that really works is SecurID, imho.
Passwords cannot work. Why do we still use them? (Score:3, Insightful)
Re:The problem with strong passwords... (Score:5, Insightful)
Forcing "strong" passwords (Score:3, Insightful)
The forced password changes really piss me off though, especially when combined with long memories of "previous passwords". I use secure, uncrackable passwords for most things, and particularly for work. But when I'm forced to change them every 30 days you can bet I'll run out of things that I can easily remember, especially since I have passwords for work, for home, for email, for websites, my ATM card(s), the company's alarm system, and so forth. Eventually I end up relying on wonderful passwords like "abcdef1" which may as well be an invitation to use my UID.
It really is a catch-22 situation. I suppose SecureID and the like are the "best" solution, but they're nearly as unwieldy for the user as strong passwords. But at least they can't just be written down -- just lost or stolen.
Re:The problem with forced passwords: (Score:2, Insightful)
I think if passwords didn't frequently expire, we would be more likely to use a good one that would be ingrained in our brains after a week or so, rather than easily guessable ones or ones we have to write down somewhere. After all, if a someone with bad intentions gets hold of my password, he's going to use it immediately, not wait around for a couple of months to give it a chance to expire. Whether it expires or not, the damage has been done.
I know you can use acronyms as passwords, including some mixed case and numeric digits, which makes them a little easier to remember, but I'm tired of thinking up witty lines to use for the acronym.
B.T.W., my current network login password is 'Pissoff'. The three before that were 'pissoff', 'pissoff1', and 'pissoff2'. If you forget, just look on the side of my monitor.
Re:Obvious (Score:3, Insightful)
Re:Here's the problem with that: (Score:3, Insightful)
Re:Microsoft password files... (Score:2, Insightful)
That attitude makes me sick to no end.
I wish I had a penny for every admin that assumed the users knew less than he did, I'd literally melt them all down into a club and bash their skull in.
One thing I learned a long time ago is that there is always someone out there who knows more. Sometimes, it's that quiet kid that doesn't seem to know anything.
Indirectly important access (Score:3, Insightful)
It's very difficult to answer the question " what are we securing and how valuable is it?" for a number of reasons. To do that, you need to define what it is you're afraid of losing and how much of it you might lose from a particular attack. Both are very difficult questions, and are often gotten wrong.
Looking at the first, people often underestimate the risk from a security compromise because they're only thinking about the confidentiality (secrecy) of their data. At least as important to consider are integrity and availability, that is whether the system and data remain correct and usable. There are lots of things don't really need to be confidential, but do need to be right. Picture building design specs, for example. They're not secret at all - most of them will become matters of public record - so it doesn't really matter if they get stolen. God help you, though, if they get altered and you don't find out until halfway through construction.
Supposing you can somehow estimate the total VAR (Value At Risk) of your information systems, it's still nigh impossible to figure out what portion of that would be endangered by any particular attack. An apparently minor attack can easily be a stepping stone to a much more serious one. Parlaying limited access - whether aquired legitimately or otherwiss - into greater power is generally called privilege escalation, and it's a common component of attacks. The "root kit" is a classic examples of this. A root kit won't get you onto a system, but if you can get unprivilleged access some other way, the kit will then get you root. You can't assume that the security of a given account is unimportant just because that person hasn't been granted access to anything sensitive. There's always the possibility that a user has, or could get, access to things way beyond what was intended. Consider your marketing schmoe whose password security you claim is relatively unimportant. It's entirely possible (even likely) that the network which "does not allow remote access" does indeed have a gap somewhere. And if it does, someone could telnet in, log in as Mr. (or Ms.) Schmoe, and escalate to root on their one server. At this point, the attacker can probably compromise the username and password of any other user on that server, one of whom may have access to something that does realy matter. This is just a hypothetical story, but it illustrates a very important point about computer security: A series of weaknesses, any one of which would be unimportant as long as everything else worked as intended, can often be strung together into a succesfull attack.
As you said, security policies should be based on a rational economic evaluation of what's at risk and how much it would cost to mitigate that risk. The problem is that it can be difficult indeed to assess how much risk hinges on a given decision, so it's usually wise to be more conservative than you think you need to be.
Just a quick heads-up... (Score:3, Insightful)
If you have a small company with, say, fifty people, and you educate and assist all fifty of those people, a significant fraction will still say "there's no way my account would be cracked" and use set their password to "PASSWORD" or somesuch.
The fact is, you do need to force users to enter cryptic passwords, or there will always be lazy, irresponsible types who just don't do it.
Re:Here's the problem with that: (Score:2, Insightful)
The thing that is kind of silly about these is that they attack your encrypted password even though the system has access to your plaintext password whenever you enter it. On top of that, you have had the bad password on the system already and you get to deal with people who have disabled accounts because they were away when they got the warning, etc.
It's a lot more effective to just check the password when the user is actually setting it. You take the plaintext password and apply it against the plaintext that your password guessing algorithms would produce. If you are at least somewhat efficient about it the whole thing will take a second or so and you'll be able to apply much more extensive tests than you would bother to use if you were going to spend the system time encrypting each guess (Just don't apply the "up to 1000 8-bit-characters exhaustion" test. Sure, it's fast since you just automatically fail them, but it kind of defeats the purpose). The first time I did this I had to write my own and fiddle the passwd program to use it, but nowadays you can just stick in an off-the-shelf pam module to do it with little muss or fuss. If they fail, they have to come up with one that passes, so the system never has the bad one on it.
Re:Obvious (Score:4, Insightful)
So start with a random cvccvc (c=consonant v=vowel) combination. Yes, I know it's not quite as good as a fully random alpha combination (by a factor of 275625), but it's a lot easier to remember. Then add a punctuation character (especially a shifted one like !@#$%^&*() ) and you will get something like "kez#tul". That's a pretty decent password right there.
If you have a truly fascist password policy to satisfy, change a letter to a l33t5p33k digit, and maybe make one letter uppercase. In this case, the result could be "k3z#t00L".
If you come up with three or four cvccvc pseudo-words, you can even use them for various security levels. One for r00t passwords, one for "normal" passwords, and one for web passwords (like slashdot, etc.).
Going the other way. (Score:2, Insightful)