Slashdot Mirror
Passwords May Be Weakest Link
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?"
Passwords May Be Weakest Link
And in other news, "The Earth May Not Be Flat".
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
If you know the methods of forced passwords you can write a program around them. All of a sudden not only do you have a ton of passwords that are unnacceptable, you can predict patterns of tricks people will use to fool the force password picker into letting them choose an easy to remember password.
...people will write them down.
Preferrably on post-it notes and stuck to the keyboard or the screen.
I have seen it all.
Did anybody think that passwords wouldn't be the weakest link in security? Remember that, in general, "easy-to-remember" and "secure" are mutually exclusive. And if we forgo "easy-to-remember" for "secure", we will have people writing their passwords on a piece of paper on their desk. There's security for you.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Sounds like they put a password cracking utility against the NT sam file. The thing is that if your security is done right, you should at least need the Administrator password to access that file, no?
...secure passwords are usually difficult to remember. Thus users tend to use the month (05 for may, etc) for the mandatory digits, and sometimes cusswords to vent their frustration at the secure password policy. Also, it's not too difficult to find sticky notes with obscure strings a la "h0tgr1tz99" stuck on people's monitors. Hmmmm, wonder what that could mean?
Sources: interviews and sticky notes on monitors
--
martin
Are especially vulnerable when bonehead admins let you remotely dump the registry. I've seen that one a couple of times. They don't let the users change the time or date on their machine, but the users can dump the registry on the servers. One company told me that "of course, we know that could be a problem, but the users are'nt going to know how to exploit it". One of the dumbest examples of security by obscurity that I've ever seen.
...every 39 days, and it remembers an ungodly number of old ones, so you can't recycle. I don't have enough kids to come up with that many passwords.
I am not your blowing wind, I am the lightning.
My company is a service based company. We're a group of professional sysadmins who contract to large customers to take over network and SysAdmin duties. We are also responsible for security of our systems.
The problem with password policy enforcement is that users want weak passwords. Ordinarily this is no problem, since security often trumps user needs.
However, since we're a service based organization, our salaries and bonuses are based on user satisfaction of our performance. Guess what our number one gripe is? You bet. Password enforcement. Our enforcement of the "Strong passwords only" policy has helped us be secure, but it's also eating into our employee bonuses because the users mark us off for it.
It seems like we're caught between a rock and a hard place here, but since our customers are all senior civil servants, what're we to do? The more we enforce strong passwords, the closer they'll get to looking for someone who won't be so picky.
Users are the weakest link. Always has been. The user chose the password.
-- Who is the bigger fool? The fool or the fool who follows him? --
After dealing with multiple incidents of hacking at my former work, we formed a security policy that included enforced, complex passwords. Luckily we did the same analysis on existing passwords to justify the change because it caused quite an uproar.
Our heuristic was simple (to me)- inlcude one character from each of the following subsets of characters; UPPERCASE, lowercase and Numbers, minimum of 8 digits.
I must have spent at least 10 minutes with most people helping them choose passwords that fit the criteria. The worst ones of course were the executives, one made me sit with them for over a half an hour while they figured it out.
Luckily it was a small company of 40 people or so, I might have gone crazy.
probably 60-75% were cracked within 8 hours.
People do not understand how computers work. If they do not understand how computers work they cannot understand how computer security works. If they do not understand how computer security works, they will likely never ever understand the gravity of a password no matter how much it's explained to them.
To users a password is an annoyance. And they are trained to not be secure with their identities. How many people just give out their SSN? Something that is a definative source of identity, and allows access to tons of things: bank accounts, medical info, home addy. People will just give this to pretty much any customer service Joe.
Why shouldn't they do the same with a password?
Sounds like enforced password formats and mandatory changing of passwords would help, but how many companies actually make them policy and enforce it
Mine did. Every 3 months our payroll server refused to let us in if we didn't send in a new Password, then and there. Same thing with the filesharing/print server. The cool thing is, they were staggered so that you've have to change one of your passwords every six weeks or so. Kept it regular, kept it part of routine.
Triv
In my experience, in a large corporation, there are hundreds of independently managed password domains, at least a dozen of which any one person will usually have to deal with on an ongoing basis. Differences in password change frequency, minimum lengths, differentials from prior passwords (sometimes from ANY password used by ANYONE on that system in the last year), and digit inclusion rules vary in a tower of Babel that make it difficult to even maintain passwords, let along ensure they are all maintained securely.
What do you mean they cut the power? How can they cut the power, man? They're animals!
In what way does changing a well-chosen password increase security on a non-compromised system?
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
This is so tech-elitist... "The users are the problem!"
- all-my-users-to-32-char-monthly-passwords bullshit attitude.
Give a look at any paper by Sasse, Brostoff and Adams, such as this one, 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.
Can we have some evidence as to how harmful weak passwords really are? I know people that would be a lot more trouble if they were forced to remember good passwords (They'd probably end up wrighting it on a piece of paper). I think it's a lot better to make sure that the compromise of the account could not do much damage by restricting priviledges.
THIS is what you get when you hire people with lots of experience and not fresh graduates. The more modern security measures that are taught in University in NetSecurity 101 such as using shadowed password files instead of using /etc/passwd for everything simply get "lost in the woodwork".
Therefore by hiring only EXPERIENCED people these old security threats remain until these EXPERIENCED people retire.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
The company I work for (large, national insurance company with over 50,000 users) has a "strong" password policy that is enforced by the system. A password for our domain must be a minimum of 8 characters with a mix of upper and lower case letters plus numbers. Password changes are forced every 2 months, and a previously used password is not able to be reused for the next dozen password changes. That being said, just yesterday I was working with a user whose password was their first name with a number one tacked onto the end of it. I imagine that she started with Firstname1 and then just incremented it on subsequent changes.
The problem isn't just forcing "strong passwords" onto the end users, but making sure that end users understand the reasoning behind it. Making someone use complex password formulas is useless when a large number of the users are going to use something that can still be easily guessed that conforms to the formula.
crack this with JTR:
K wa U3KprZ4oidOjSwu UAWW/X1NxdC1Dog2 ra/sUWmNYClJWC0 LOXSfpvL8HgEBMG4 eibA124QIVAMznc 3oJ/BAr7IMDyCBF1 Iidf0ou4PvaeBjm ZyUyMT7zrCZtQC2C 7ZUbow5vPlVSbrV Eb1Uko7F0Z/914Tc 4qx3/wW3eBheNmF RHt/fL/6qgLhInab nXiOn4N8egBuuNR 5p0icOY6L/zaBMqw iGn3gm3LgE9MkKy KAhM5hHU1GyoYUSe +OV6wCFCBN9faK
MIIBuwIBAAKBgQCvUCC9yWCa83yU3Ebjc5su9pFCoENwPEu
J9Q4Or2FqIK9zd/VDvTsbW875/pKe13BN
vHz4JGz6HRSNWyW0KweCNN6oNAiICks87
RJxmFVhZ5gF4/Pt1GHkFSAyHAoGBAJ/7p
VkcsSYMizrbP9O4Gwtt30MdWqUxY21NFA
7RWmzF4P+xN8zZABbHXlv01uDGZvnmK9W
elSArUMLAoGAO4cO0FqefRT6VshGt4T3v
7hBy56BNWMuP7Z/ixROhxv59gCJTsKEFt
Gk8LxtdRBPgpoK0BwmEQhZEAL5pfemW94
BQG08IhGGotd8mBIfO4s
no, of course that is not my private key. But it proves a point. Don't rely on false randomness to enforce security. Do it the right way.
While you're at it, read Schneier's book(s) and subscribe to Crypto-Gram. I force-feed it to my network users every time it comes out...
Remember that what's inside of you doesn't matter because nobody can see it.
Now "dictionary word" -> "easy to remember" -> "insecure" but that doesn't imply "insecure" -> "easy to remember". Far from it in my opinion.
EnkiduEOT
There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye
In my experience password expiration just forces you to pick memorable passwords. I have several passwords thatt haven't changed in years, but they are secure by most definitions, 8 chars, upper lowercase and numbers. They would be impossible to remember except that I have been using them for years. The only thing password expiration protects against is limiting the damage of a password which has already been compromised.
Spencer Ogden
- A great deal of passwords are simply PASSWORD. Try it, you'll be amazed
- If you know the names of the target's immediate family (and possibly pets), you've just gained 1-5 more possible passwords.
- Many people simply make their passwords 'qqqq' or some chain of identical letters. This is because they don't want to have to bother with remembering a password.
- On a similar note, try QWERTY, ASDFGH, ZXCVBN, etc. Look for strings of letters on the keyboard that fit the minimum password length (typically either 4 or 6.
- If you have access to the target's desk, you've hit pay dirt. The password is likely written down somewhere. It would be nice if most software didn't say write down your password, etc.
Good password creation tips...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
news, and in other news, Computer systems are 100% safe except for the users. Anyone who has been in any sort of IT environment can tell you this, and probably for a whole lot les money than the consulting firm charged. Unless your policy is enforced and dictionary used on passwords, (L)Users will compromise security for ease of use almost ALL the time.
errr....umm...*whooosh* *whoosh* Is this thing on ?
At my company, I initiated a policy requiring strong passwords (8+ chars, at least 1 uppercase, 1 lowercase, 1 digit, one punctuation, no dictionary words beyond two characters in length allowed). The policy also requires monthly password audits (using programs like John the Ripper).
I got the policy signed off on by the board, then I wrote a memo that explained the policy and showed how it is easy to come up with and remember good passwords (through the phrase --> password method, for example).
So far, it's worked out well. There was some grumbling at first, but once people came up with their first passwords, they realized how easy it was and it didn't bother them any more.
-Joe
Yup. Passwords need to be done away with, wherever possible, in lieu of things like smart cards, SecureID style schemes, and other such thingies. Otherwise, you get an email address from a company, divine from that, probably, the login name scheme, then start randomly trying names, using all the usual suspects for the password, and you'll get in eventually. Don't even need to try any more.
Vintage computer games and RPG books available. Email me if you're interested.
Tokenized fobs, or one-time passwords are the best answer, I think. Too bad an ACE server costs so much. :-(
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
Here at work, the DBAs are setting up strong-password checks on all of the Oracle databases. Passwords are restricted to more than seven characters, and must contain an upper-case alpha, lower-case alpha, a numeric, cannot be one of your last 10 passwords, and cannot have similar substring matches with your last password.
However, with Oracle versions 8.1+, there is a bug with the supplied verify function that rejects nearly ALL passwords supplied, even passwords that are completely random strings (such as g8kLK58sS). Anything used in the "ALTER USER [NAME] IDENTIFIED BY [PASS]" will fail, and we users are getting a bit angry that we've lost the ability to change our own passwords.
What this has resulted in is an abundance of ORA-28003: password verification for the specified password failed messages. This is the default error message when your password is not complex enough. Note that by default, Oracle passwords are NOT case sensitive.
You need to have a password policy that encourages better passwords without requiring a specific password makeup.
If I encounter a system where my password must include mixed case and digits and punctuation, I'm going to make up a random string, and then have to write it down.
Some Unices I've encountered had a passwd(1) that would NOT allow you to enter a "bad" password, while others would nag you gently depending on how "bad" it was, but would eventually relent and let you set your password to "flower" if that's what you REALLLY wanted.
The REAL answer is not "password" but "pass phrase" where the text can be lengthy and meaningful to none but the user.
Furthermore Opie is a neat project to avoid keyboard snooping.
How does the Slashdot Effect happen given that no slashdotters ever RTFA?
Phrases can have lots of entropy, and still be easier to remember than the equivalent entropy in 8 chars.
Enforcing policies that make people choose random passwords just leads to people writing them down on postits stuck to their monitor. Just make sure it has a couples spaces in it and has a decent length, like more than 10 chars. If your system is still enforcing an 8 char limit, trash it, it sucks.
When I was sysadmin (for a Windows network), I would just run l0pht. If A) the dictionary could hack it, or B) if they didn't have a number or special character, then I forced them to change their password on the next round. (Here is a detailed explanation of the Microsoft vulnerability.)If they didn't change it to something better, I'd give them a quick phone call and politely explain the security policty I was implementing. (Most people are very cooperative if you tell them politely and don't shave your security policy down their throat.)
There are other free programs out there (I forget the names) that generate nice reports based on l0pht findings. You can, for example, say that 80% of the users have passwords the same as their user names, 50% have passwords with one special character in it, etc.
Perhaps CxOs should visit sites like Astalavista.com. They'd then see how easy it is for a cracker to compromise your network!
All Microsoft would need to have done is buy out Verisign before the anti-trust actions and before Verisign became a monster.
Seastead this.
Lets face it: one of the weakest features of username/password authentication is the fact you must declare your ID and then your password. No matter how well you hide your password that fact you declare your ID into the system is probably just as bad as easily guessed passwords.
Think about the difficulty in authenticating hacking if the all usernames were completely unknown or never declared. I could tell you there are 4 users on "login.supervaluable.com" all of which the passwords are "easy12remember". Unfortunately if you never figure out what the names of those 4 accounts are the passwords are worthless. However if you have a list of the 4 account names but don't know the passwords you have at least a place to start your intrusion.
So just as much as easy to guess passwords are a problem I stipulate that easy to guess usernames are too. Does this mean the username/password scheme needs to be rethought? Anyone have alternative authentication schemes that requires minimal "declaring" of any information?
-
The algorithm used requires that the length of the password be
within configurable length limits, and that the password not
have triplet statistics similar to those associated with words
in the English language. This is an inversion of a technique
used to find spelling errors without a full dictionary. No
word in the UNIX spelling dictionary will pass this algorithm.
That's enough to defeat the usual attacks. And it's one page of code, plus a few pages of table.Users should be advised to pick a password composed of random letters and numbers. Eight randomly chosen letters will pass the algorithm over 95% of the time. A word prefaced by a digit will not pass the algorithm, although a word with a digit in the middle usually will. Two words run together will often pass.
Single sign-on is a joke. There is no standard for this. There is no single solution to authentication that spans across all platforms. Take, for instance, a vendor of a turn key product, say a web based materials management system. They would probably role their own authentication system because they need authentication but can't rely on their customers to have a particular system in place to interface to for authentication purposes. So in addition to the ten other papsswords I need to remember for all of the other systems with custom authentication, I will need to add one more to my list. Thee solution is the development of a authentication standard that can be applied to future systems and retrofitted in to legacy systems. Kerboros? Seemed good at the time, but why hasn't is caught on more? Tall order? You bet! But how else are you going to solve the problem of having to remember multiple passwords. Most people just go back to remember one or two and use them for all the systems they log in too. Not a good idea, but let's face the truth, almost everyone is doing this and this won't change until a real single sign-on solution is delivered.
-- Knuckle Blood : Official Lube of Team Rusty Nuts.
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
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
The story is rather obvious, everyone knows the human factor is always the weakest link, and that includes passwords people pick.
On a side note, password policies can sometimes do more harm than good. Our company enforces password changing and password strength rules for NT logins. We change passwords once a month, and the requirements read "At least 6 characters, must contain capitals, numerals, or punctuation, cannot be any of your previous five passwords, cannot be based on username"...
Well, someone goofed in the logic of the password ruleset. As it turns out, it requires the use of both capitals *and* numerals. They've actually managed to limit the number of possible passwords... as the majority of the passwords at this company now start with a capital letter and end with a numeral (most often "1"). Since they have to change passwords once a month, most employees erither write them down or pick very easy ones.
11*43+456^2
In my view, the real problem lies in the number of web sites which require (free) log in. Say you use 20 services and that they all require logins. Are the punters supposed to remember 20 different name/password combinations? No, they'll often reuse. And what is to stop billg/msft1234 who has logged in at both slashdot and the New York Times being compromised by CmdrTaco to read the NYT for even freer? I personally re-use passwords for sites where there is no risk involved, elsewhere I often create throw-away passwords which I'm happy to have in a cookie but forget before I'm ever asked to use them again (and thus create a new account).
Wouldn't access to the password file be the weakest link? Who doesn't run a shadowed password file anymore? ..
:-) Oh, wait, every system has root! Well, show me a system that lets you login as root and I'll show you a sysadmin who should be shot.
Without that - you're looking at brute force. So, start guessing at usernames, and start guessing at passwords for those users. At since the Unix login slows down the more you attempt to get in, well, it's pretty damn hard.
Windows - on the other hand - is no issue, they lock accounts after a couple failed logon attempts. Microsoft knows how to implement tight security controls.
My IT folks love to talk about the mandatory password change. I change my password once every 15 days. It has to include three of four character classes: numeric, uppercase, lowercase and symbols. And finally, it can't be any of your last five changes.
And yet, we've been hacked a few times. How's that possible, you ask? Well, the same IT folks have set up a network that uses plaintext passwords for everything, unless you know how to properly tunnel things.
The draconian password policy has created other difficulties. A few employees have a set list of five passwords that they rotate; one has his written on the calendar. Many of us have password lists under our keyboards, which in an open floor is about as secure as...well, it isn't secure. Finally, the majority of the passwords follow a simple theme: capitalize the first letter, add a numeral to the end. A dictionary attack for that would take what, five minutes?
Rapidly changing passwords are a hassle for everyone but the paranoid, and that makes them insecure based solely on inconvenience. Want a nice, secure password? Change it once every six months (with a reset any time you suspect network funny business) and generate it yourself. Anybody can memorize any password given enough time -- and forcing the change only results in easier to crack passwords.
Hey freaks: now you're ju
That way when (not if) an account is breached you can track what's been done, damage has been limited, and user privileges is where the buck stopped. Of course root needs to be locked up like a bull in a china shop. Make sure you're patched up. When you need high security like in the military you need to uhhh, not gonna finish this sentence I'm hungry gonna click submit and eat now
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
I once work at a research institute where they have very nice policy regarding the passwords.
They constantly run the best available password cracking program and when users password is cracked, he get either the warning or account lockout right away depending how long it takes to crack. No other restrictions were applied.
Microsoft knows how to implement tight security controls.
That <grin> didn't show up very well!!! Should have previewed my message. Hah.
A good method to create strong password I known is named "passphrase".
;-)
;-)))
People think a phrase (a statement) with 4-6 words and get the first (or latter, as you wish) chars off the words.
For example:
phrase: my linux box is equipped with an athlon 850
Using the first 1 char, you get:
mlbiewaa8
which is a "strong" password but easy to remember.
My 2 cents.
The net impact of requiring monthly password changes is the majority of the user-base will work the month/year into their password. This means that your typical password will be bobmay02, or at best bob8mylf5, where 5 is the month. Making people change the password frequently causes them to split the password into the root, and either a time identifier or a monotonically increasing integer. Thus, your 8-char passwords are now really 3-7 char passwords.
Has anyone written a cracking program to take advantage of this? Instead of having to decode the entire password, you merely look for transformations that result in the beginning or end of the password translating to a string resulting in a mnemonic for the current month/year.
Remain calm! All is well!
This has been true since passwords were first used. I've run password cracking programs against all of my systems and projects as part of a standard assessment. I would say that finding 30% of passwords in less than a day would be a fairly typical result.
The truth is that passwords are not a good security tool for all the reasons you would expect. The basic one is that memorable passwords are generally easily cracked passwords.
I use tricks like passphrases where I take the third letter of each word, mix case, and numbers for certain letters, etc. Even with those tricks, the password is still fairly easily attacked (the frequency of letters in the english language is hardly random).
IMHO the best solution is to combine authentication methods. Use a token system like SecureID combined with a password. Better yet, use password, token, and biometrics.
If you have to use passwords and only passwords, run the attacks yourself and lock accounts you can crack. If you don't run them, someone else will.
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.
People at work hate me for enforcing hard passwords. (And other assorted security measures)
Basically I am a BOFH so I don't care.
Unfortunately the common joe/jill user has no clue when it comes to computer security.
You just have to resign yourself to the fact that people are not going to like you. (i.e. Security Nazi)
A good way to help *push* them towards secure passwords is to crack your own systems passwords.
You can use John the Ripper for Unix passwords OR l0pht crack for Windows systems.
Nothing disturbs an end user more then when you email them their old password,
(You have changed it to something hideous now...) and warn them that you can read their email.
If you use Microsoft systems then use the password "Account Policies" options to increase password length/complexity values.
If you use Unix try npasswd to enforce difficult passwords.
The most important factor is to get Management buy in. Try cracking some VP's passwords during a "standard audit".
Help them come up with a creative password. (First letters of a phrase work good. Throw in some numbers/metachars..)
Once I had Management buy in it was smooth sailing. Just hold their hand for a while.
I strictly enforce "difficult" passwords on all of my clients - but I don't make them rotate them.Why? Because difficult passwords are by defenition hard to rememeber - and I don't want them to write their new-passwords-of-the-month on post-it notes.
In this day in age, it's usually easy to add SSH/IPSec gateways to everything, and filtering all unknown ip addresses helps as well - I use these to augment any system that brain-dead enough to transmit passwords in the clear.
Quite often, password rotation causes passwords to be transmitted in the clear - over help-desk phonelines, in un-secured palm devices and on sticky notes.
Food for thought - and yes, I do know it's against your MCSE training.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Everyone knows the first part of this. If a password is easy to remember, it is easy to crack. If a password is changed frequently, it is almost impossible to remember. Why are we still using passwords? Passwords rarely catch on in any of the other places we try to use them (car locks, electronic padlocks, electronic house locks, etc.) The few places they have caught on are typically a joke. I recently went to the side door of my sister in law's high security apartment. There were four keys on the entry pad with the numbers worn off. I didn't even bother to call up to her until I had the sequence figured out. Thirty years in trying to lock down systems seems to have taught us nothing. Why aren't we damanding something better, such as USB keys, fingerprint scanners, etc? Whenever I discuss this, there are quite a few who say it is the users fault, that they must be trained to use passwords that are secure, and then everything would be fine. Sure, and if everyone loved each other, there would be no more war. But let's deal with people as they really are, not in some theoretical alternate universe. I'll say it again - thirty years of experience has taught us that passwords do not work. At some point we need to stop trying to start that car and get a new one.
This implementation of S/KEY includes a scheme for making machine-generated passwords that are supposed to be memorable by humans. Does anyone have any experience with such a system, as used in real life?
Just because there's a tradeoff between ease of use and security, that doesn't mean that you can't sometimes improve both; most real-life systems are probably not optimal in either way.
To give an example of a really retarded password system that's completely nonoptimal, I teach at a school where the faculty turn in their grades on a computer. Security is obviously an issue. The password policy is that your password must consist only of digits, at least six of them. Now this certainly will stop people from choosing "password" or "rover" or "aaa" as their password, but they'll probably end up using their birthdays, or writing their passwords on a post-it, because they can't remember a string of digits. And of course the idea of restricting it to a character set of only 10 digits is pathetic -- it just reduces entropy. (The people who wrote the software are so clueless, they even set up the default configuration so that you have to type in your password twice in order to log in -- I guess that was meant to increase security! It took a few months for the school's admins to change that.)
Find free books.
Our company's business is shipping medical software on laptops for drug studies. We had to start complying with 21CFR Part 11 for all studies done in the US (has to do with electronic signatures and record-keeping). Fully half of the sites that we have visited for training or orientation on a study have post-it notes with user IDs and passwords either on their screens or on the underside of the laptops...and this is when they KNOW we're coming to train them on this and they KNOW we're gonna holler at them for the violation, because the FDA will do more than holler at them when they show up for an audit and the FDA doesn't have to announce their visit before they show up.
I would be less surprised at this if we forced strong passwords, but we don't. 21CFR Part 11 doesn't specify how strong passwords have to be, so we use fairly weak rules--four to ten characters, not case sensitive, symbols allowed, expire after a year. (And the only reason we went with four characters was because the user ID is three characters and we didn't want the password to match the user ID). Then we had one of our trainers going around suggesting to users that they use their year of birth as their password...nobody knows anyone else's year of birth, right? We actually had a user at one site write THAT one down on a post-it note, too...
We actually had to fight administration here on development of our next software package because the PHBs wanted passwords to be a minimum of one character. I finally convinced them by having the vice-president change his screen-saver password to a one character password and manually hacked it while he was sitting there, but then he just wanted to change it to two characters! We finally got them up to five characters, but it took some doing...and forget about trying to get them to approve case-sensitive or forcing numeric entries too...
Denver Isuzu Suzuki
with the coming of usb-size hard drives, passwords will not survive the next generation of communication systems. a public/private key system will take its way, with those USB small hard drives containing the keys to access the system. No need to change passwords either; it can be completely automated, and the keys will be long enough to be safely uncrackable.
also, a usb hard disk will become what a metal key is now: a fundamental piece of our daily job.
the other side of the medal is that those keys can be given easily, or even stolen. True, but how many times did you hear your users tell their passwords each other (can you check my e-mail while I'm away? thanks) for whatever obviously stupid reason?
and also - you can force users to use long, difficult passwords. but how long can you screw your CEO patience off?
cheers
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)
IMNSHO, the best policy is to allow the user to have a password that does not expire, and force it to be a good password. That way the user will have a virtually uncrackable password that they can also remember. Of course if compromise of the password, or a system the password is contained or used on is suspected, THEN you force the password change.
Of course, all bets are off if you are using insecure protocols and hire web programmers who cannot figure out how to handle/store session data securely.
I have my own policy when it comes to passwords and how difficult they are. It's all a matter of degree.
Our NT network uses a fairly weak password system to be honest (8 characters minimum, no uppercase or numbers required), which I find completely silly. I can use most dictionary words to log into my workstation in the morning, but I don't. Because I have admin access to my own machine, and access to a lot of other resources, I make sure my password is somewhat obscure by throwing in mixed-case and numbers where they wouldn't be expected.
Now, if you're talking about a silly login to the NYT website, and other assorted types of sites, I have a standard easy to remember password I use for it, completely seperate and apart from any of my other passwords. If anyone gets ahold of it or guesses it or whatever, the worst they can do is browse the NYT site on my login id. woo.
Then there's the big ones. Root access passwords to critical machines. Those are always completely obscure, meaningless, hard-to-remember strings (at least for anyone else... for me, they're associated with something I'm personally familiar with).
Moral indignation is jealousy with a halo - H. G. Wells
As for tunnelling, ssh with port forwarding suits my apps fine, I don't need any of this fancy new stuff like GED or JED thru IPSEC or whatever although I might look at it sometime. Should pre-empt those buffer overflows now.... Hmmmm....
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
I wonder if holding something like a "password cracker demo meeting" would help. Set up a test machine, let everyone enter a password of their choice, then run crack or similar on the password file.
:-)
Golly, yes, the users will be impressed by that: here, enter a password into our computer here and we'll tell you what you just typed
Matthew @ Bytemark Hosting
I had strongly considered posting a response similar to this one in the worm thread appended to Slashdot earlier today.
Nearly every member of the Slashdot community is an advocate of "secure programming," but the possibility exists that we may be overlooking some of the most trivial preventative measures that could be utilized to protect our applications from intrusion.
Don't assume that the individual installing your program is competent, proficient, or intelligent. Had MS SQL been programmed in this manner, it would have never accepted logins to usernames without (strong) passwords applied. SQLsnake would most likely not have propagated as easily beyond its author's machine.
Both programmers and administrators must act responsible for an application to be configured securely. I'm certainly not suggesting that administrators should be permitted to shirk becoming educated and competent. I'm merely recommending that programmers attempt to prevent incompetency from compromising an otherwise secure application by dedicating a small amount more of time and effort.
Appromimately fifteen minutes of the Microsoft programmer's time and ten lines of code may have prevented the loss of hundreds of manhours and perhaps gigabytes of bandwidth.
Do you like German cars?
As many others have pointed out, it's between a rock and a hard place. Allow weak passwords and you'll get them. Force strong ones and they'll be written down where anyone can find them (I used to work at a company whose Unix admin wrote down all the root passwords on the bottom of his keyboard wrist rest. Yes, he sucked.)
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.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
The article is needless to say stating the obvious, but it is nevertheless drawing attention to an increasing problem as more people use computers, more people use simple passwords.
I think this is particularly the case with novice users- speaking from experience my first use of a password was the school computer system. Firstly, in the first term we were not allowed to change our password from "password"! Then we were told to think up something a bit random that you wouldn't forget- well how was I meant to do that- something random _is_ hard to remember. So I use my middle name. This remained unchanged for a long long long time, until my hacking boyfriend decided to hack into my school network and easily worked it out. It was only then that I decided to change to the serial number on my mouse.
So really, novice computer users simply do not see the need to choose good passwords- who's going to go hacking into the system anyway? Paranoid about credit card usage perhaps, but average users like myself generally don't think too much about anything else. It is here that the problem lies.
I don't mind having to have a good, secure password. My gripe is having to change it every 30 days, when I'm logged into 3 different NT domains, and I have to figure out how to get my accounts passwords all synchronized when trust relationships are broken. NT and domain trust relationshipss fucking sucks. MS created Active Directory to kill Novell, and IT bought it hook line and sinker, and nobody is even fucking using directory services.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Login: Bob
Password: password
You are the weakest link! Good bye.
Logout
Outdoor digital photography, mostly in New Engl
The problem users are bonehead sysadmins who use their authority to bypass the password policy or just don't set secure passwords.
I'd be eating dinner and drinking expensive wine at a nice restaurant if I had a dollar for every time I've found an Oracle SYS password set to "change_on_install" or "oracle".
The only solution to the password problem is to eliminate passwords. At my organization, we are moving to a smartcard-based system that removes the password problem completely.
Conformity is the jailer of freedom and enemy of growth. -JFK
OK, one password for life might be a bit extreme, but if a user is on to a good thing, do not get them to change.
.. .. ok I have oversimplified things a bit but you get the point right?
I have never understood why people think that passwords suffer from wear and tear. I have never seen evidence to convince me that the longer one uses a password, the more vulnerable it becomes.
I remember in university, one of my courses had a module in something about maintenance/replacement of machinery, from a managerial perspective. One thing I recall is that with a lot of mechanical equipment, the older it got, the shorter the mean time between failure.
Digital equipment was almost the opposite. New equipment had a high chance of failure. If it survived the first couple of weeks, then it became almost impossible to predict failure rates. It was entirely random. Hence replacing aging mechanical equipment made absolutely no sense, whereas replacing digital equipment actually introduced a danger of failure
Well, passwords are like that. If you force users to change their passwords, and they change it from John, to Luke, to Mark to Peter, you have not really done much.
If you get really funky, and force them to change from adf0708 to 1433lkh to kh432lk to 23HGLY9 then you are beginning to get somewhere. The problem with these is that users then tend to write them down, because just as soon as they remember them off by heart, they are force to change them. As long as a password is written down somewhere, it is not secure!
A more thorough plan is to get users to choose one password, and set rules on numberics, caps, etc.. (or better yet issue passwords). At the same time, run a basic brute force dictionary cracker on the password file(s) and force *all* users with simple passwords to change them. Keep forcing them until they choose something sufficiently hard (or issue them with one that they can't change for the first 3 months or something).
Once users have a robust password, allow them to use it indefinitely!
Live today. Tomorrow will cost a lot more!
In practice, when people have to change their password every few weeks or months, they typically either have a standard modification of a base password, incrementing a number on the end or the like, to make it easy to remember the new password, or because they have to think if 'secure' passwords again and again, they have to record them somewhere to remember them.
The first action renders the new password only barely better than the last, and the second opens a physical attack, by finding the file or piece of paper where the passwords are recorded (ever see Wargames?)
If someone's conducting a brute-force attack on a password, it doesn't matter whether you change it often, as the chance of hitting it in any given time interval stays the same whether it's changed or not.
Expiring passwords only help to lock out people who already have access to your system because they guessed your current password. In most cases once someone has breached your system it's irrelevant to lock out the password they used, as they've either changed the password themselves, created a new account, installed another backdoor, or done the damage/thieving they set out to do.
To sum up: Making passwords expire incents users to make passwords that are easier to guess, or makes them write the passwords down to remember them. Both of these are bad.
Kevin Fox
then just use unshadow to combine the passwd and shadow files and run john on it. I just did it and one of the passwords on my system was cracked within 10 seconds.
Bah! It's time to tell the system to expire my gf's password... wonder if she'll be pissed :)
Oh yeah, on debian, you can have john run as a cron job which mails users with weak passwords to change them.
*I have a feeling gf will be complaining to me soon how she's getting spam from somone named john. heh.*
Liberty.
here.
[o]_O
all it takes is one mistake in WHERE you type that password, and suddenly there can be a plain text record of it. Look over your logins and there is a good chance that someone has typed their password there. Same with email and logins, people will enter the password that jumps to mind, even for the incorrect service.
And I just figured out the terminology for why: they're not a capability. And I'm not a raving capabilities geek like the erights folks, it's just that passwords are so "exposed" by virtue of the fact that they're entered, often in plain sight, and typically for other mechanisms, have to be stored in config files that now have to be kept nonreadable, because they contain database passwords. Every other security mechanism I'm comfortable with isn't really subject to the guessing attacks, to being written down, to being exposed. Everyone can look at an ACL or a PAM config file, know who has the access, but it's all quite pat, one has the access already by virtue of having some existing credentials, or they don't. Nothing that can be taken and duplicated, no piece of information that can get stale and has to be changed.
I guess that's just how it works, you have to initiate the chain of authentication/authorization somewhere, and lacking a physical token, you choose something that's easily replicated to whatever needs the security. A secret stored as a string fits that bill nicely.
About the only thing that feels "squishier" than passwords than passwords is the timeout aspects of kerberos auth... the whole notion of a timeout as a security feature just feels like a race condition to me.
I've finally had it: until slashdot gets article moderation, I am not coming back.
That deserves a much praise. I've seen 70% broken in 20 minutes at an unnamed company I used to work for. That was 12000 accounts (NT domain). And that was a few years ago on slower hardware.
Seriously - 30% isn't all that bad if the cracking software is configured well.
Evan - needs to hit preview before submitting
I'm not convinced that mandatory chaning of passwords helps. It would seem that having to change a password every 30 days or so would encourage weak, easy to remember passwords. Or, the infamous sticky note on the monitor with the pw on it. Does anyone know of any actual research into the value of forced password changes and/or the optimum cycle time? Or, is this just something security admins cooked up to look like they were doing something?
Geeky modern art T-shirts
A few years ago, I had an account at a local ISP that offered shell access. Amazingly, they were not using shadow passwords even though that option was available at the time. I grabbed the file, and using my trusty 486, I cracked 4000 out of 6000 accounts in 2 weeks. I didn't do anything with the passwords I found, but someone more evil than me obviously could have.
John the ripper is an excellent tool, and will also work on windows passwords also with an addon.
Need Free Juniper/NetScreen Support? JuniperForum
The security implications are horrifying.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
In all of the places I've worked, the biggest barrier to implementing password policies is the users. People want simple passwords because they are lazy, and they don't want to be forced to remember a new one every month. Management has an interest in not pissing off users as it makes them look bad, and if there was a breach of security, it would make the people under them look bad, not them.
I've found that the best way to convince management to allow password policies is to whack up some sort of brute force password cracker, and run it with them sitting right there. Scare them into it. Make lots of mention about all of the bad PR you'd receive if you were hacked and what your clients would think. This will usually sway them in the right direction. A much better system would be Secure Computing's Safeword product, one-time use passwords that are event based, not time based like RSA's product. This way users don't ever have to change their password, and if it gets sniffed over a silly telnet connection, the attacker can't use it for anything.
Need Free Juniper/NetScreen Support? JuniperForum
I did the same thing on our NT SAM database a while back. 75% of all passwords fell in about five seconds. ;-)
I did that once for a previous employer. Boy was my boss suprised when after a minute or so of cracking I called to ask him why he'd choose such a stupidly simple password as "miscio".
Hmm... reading through the comments, one thing that bothered me was the claim that users are the problem. I really don't agree with that. The biggest problem is that nobody has put all that much thought into really making anything secure. It seems reasonable to me that somebody could develop a security system that has some common sense to it.
Here is an example: Let's say that I am working on my highly secure workstation that only responds to my thumb print. This should trigger a set of rules that the computer should respond to. "The user is sitting here at the workstation, so whoever is trying to access data from this terminal from the Vancouver office cannot possibly be him."
I know that there are some security systems that use similar rules to verify access, but what Im describing is a computer that uses more intelligent deductive abilities to grant or deny access. If a computer were to be aware of what hours somebody works, and what key was used to open the door to the office, and was even smart enough to call the guy's cell phone and see if it can hear it ring, then it would be more discriminate about what is legit and what is a hack. *realizes that is one huge run-on sentence and apologizes*
The point Im making is that security is more than just passwords, it is about common sense. I believe this is possible. If a webserver, for example, knows that the word 'haxx0red' probably wouldn't show up on one of the pages, it could heal after somebody breaks in. Heck, the website could even be smart enough to know 'Hmm, it is 3 am, and the computer accessing me is 400 miles away from me. I seriously doubt this is somebody with legitimate access.'
Put more time into giving your systems common sense security, and they'll be harder to break into.
"Derp de derp."
For years I've been creating my passwords not based on words, but on easy to remember hand motions. to give a very simple example: Qwerty78 a simple rolling left to right motion, plus a few numbers. Very easy to remember, tough to crack if you try a brute force attempt.
That's hardly any good. "QWERTY" would probably be my 9th or 10th guess if I were trying to hack someone's password by guessing. I can guarantee you that simple strings like that are in most PW cracker dictionarys.
What you say is certainly true, but I want to put a big caveat on it:
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.
Why is it an accepted and often encouraged practice to force users to change their password after a certain number of days? Obviously most of the vulnerability is caused by users selecting simple and easy to remember passwords. However, changing passwords frequently causes the very behavior we are trying to avoid. In my experience, users who previously had very secure passwords switched to easy to remember passwords such as "lastname01, lastname02, lastname03..." when forced to change every 60 days.
The more obfuscated a password is, the more difficult of a time people have remembering it. thus is more likely it is that they will write it down and store it on a piece of paper near their workplace.
Try a combo of a reasonable but not insanely restrictive pass phrase plus a digital token (smart card, assuming you trust smart cards) to be safe. that way just writing the pass phrase down doesn't hurt and the pass phrase doesn't have to be so difficult to remember that it needs writing down.
Users are lazy.
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.
A long time ago a friend of mine was running an ISP. This was back in the days when ISPs usually had a user shell machine for people to log into. He ended up with a "non-authorised user" infestation. He had me run Crack against the user machine password file. I was shocked at how fast the first few passwords popped up... literally before my finger had left the "return" key. Of course, these were the ones where the password matched the username. :-( After about a week of running, fully one-third of the user passwords had been cracked. By that time Crack was getting into the "weirder" rules, and I stopped it.
I gave the list of usernames to the support folks so that they could force the users to change their passwords. I don't think I'll ever forget the shock of seeing those passwords pop up the instant I hit "return"!
Milalwi
I work for a large confectionary manufacture who have one of the best password policies I've come across in the 7 years of my IT career.
8x90. It's simple. Eight characters with forced policies on every system to change them every 90 days. Splash screens at startup give advice on choosing stronger passwords. We advise choosing a six letter word, breaking it in half and inserting a two digit number.
e.g. let01ter
Simple and effective.
Of course, without running a cracker over the password lists I guess we'll never know if the policy actually works!
If you like getting a nice secure password, try a password generator.
We used to store our root passwords on printouts that the sysadmins kept in their top drawer - obviously not secure.
The solution I came up with was to build a dedicated Linux password server. Each user has a login and is a member of certain UNIX groups. Their "shell" is a custom C program that when the user logs in, prompts for a machine and username combination. This input is only displayed as asterisks (so people looking over the shoulder won't know what machine the user is looking up). The program then tries to read a text file for that machine and user. If the permissions are such that the logged in user is a member of the right group, then the contents are displayed for 5 seconds and then the screen is blanked.
This allows us to restrict who has access to what machines. The password server is pretty secure with no unnecessary daemon processes running, root cannot login through telnet (you need to login using a second account to get a prompt to su), there is a bios password and lilo password and the box is physically secure in the server room.
In the case of fatality, a paper backup is stored in a secured envelope and kept locked away with human resources who have permission to give it to a select few only (managing director, director of operations and IT managers).
It's working well for us and has been live for about three months now.
Every company/ISP/system should enforce password changes/passwd restrictions I'm all in favour of it. However, it IS possible to go the other way, and provide less security. My company is a multi-national and we have a huge network. Forced password changes were implemented around a year ago, because of a hacker wandering around. That's fine to do that, but then we have around 5-9 accounts, (depending on what you're doing), and that's INDIVIDUAL accounts. That's INDIVIDUAL passwords. It's made slightly easier, by not having passwd restrictions. I can tell you that the passwords that are going to be used by users will be something along the lines of 'abcdefgh', then 'bcdefghi'. The forced passwd changes is a monthly grief for everyone. Everyone HATES it. And so they should.
-- main(s){printf(s="main(s){printf(s=%c%s%c,34,s,34
Having just implemented a linux box here at work, my boss asked me about this. I tested it, and just using the first 8 chars did *not* work. This is on the latest version of Slackware (7?)...
jred
I'm not a mechanic but I play one in my garage...
"Your password is the weakest link. Goodbye."
The National Highway Safety Institute released a report today that strongly suggests motorists are the cause of most traffic accidents. I know, hard to believe, but there you have it.
Edith Keeler Must Die
Why not write a shell script, with say the most common 1,000 or 10,000 (or even greater) passwords and just have it look at the password when the user changes it, and spit out a printf("that is a common password, for security reasons, please change it something that is harder to crack") or whatever and prompt them again.
At my last firm I was amazed to see everyone using the SAME password on hundreds of machines. I'm a bit nosey so I used to look over the shoulders of my collegues as they typed and almost without exception all of the passwords were a string of asterisks!!!! I changed mine to a string of asterisks too, because I like to fit in.
Code, Hardware, stuff like that.
One of the key techniques is velocity checking (only able to enter 3 bad PINs), but this really works best with centralized systems (alternative if only local velocity checking is used, find 2500 ATM's and try two trial PINS at each ATM). That is one of the main differences between this system and a UNIX like password (where you can get a password file and perform offline attacks).
There are additional safety measures. For example, a key principle of PIN input/verification is that you should not be able to create PIN-trails purely electronically. The cryptographic weakness of 5000 trails (average to attack a randomly chosen 4-digit number) is not too bad if each trail requires a user punching a PIN into a keypad. So long as the attacker has to punch each trial into a keypad (average of 5000 trials for a randomly chosen 4-digit number). Obviously 5000 is a very weak number from a cryptographic standpoint. For this reason the PIN verification products don't usually accept clear PINs, they only accept PINs that have been encrypted (with something like a key used for the ATM or POS terminal that generated it). One of the classic design issues for a PIN validation system is to make sure PIN trails are O-2^56 (single DES) instead of O-10000.
Throw in physical security like cameras at ATMs and the like, and you get a system that is basically acceptable. Of course there is a whole number of issues in the industry today. The move from single-DES to 3DES is pretty complicated (there are a lot of ways to implement 3DES systems that only have single-DES strength). You also need to worry about internet and phone banking, where the system that generates PINs (or their equivalent) are not trusted hardware devices like an ATM. I've seen naïve internet PIN systems that turn out to be great PIN crackers (i.e. they provide a method of doing O-10000 trials to an adversary).
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
Once these policies are enforced, the weakest link will be the PDAs and paper pads where people write down all the damned passwords they have to keep up with. I don't know what else we can do but this password stuff is getting out of hand.
Wansu, th' chinese sailor
These cracking programs...how many languages do they tend to have dictionaries for? How many foreign pop cultural references might one find?
I have a tendency to use non-english words for passwords (my current fave is a combination, forming a nonsense word, so it ought to be safe)...how safe is this practice?
These hackers are unlikely to be able to compromise root, I've got a > 25 characters in length password of upper+lowercase+alphanumeric+numbers
Troll,
You don't have to figure out your root password once they're in.
They just have to bend/break one of your daemons running as root, or a higher privelige than what they've got, and they are out of that users account, and installing their own backdoor somewhere as root. That's why rootkits are called rootkits
Anyone,
Who was that person that saw a intruder get in, install rootkit in 7 seconds and then get in through his newly installed backdoor later?
Luckily he had a modified a few system programs to log all data to a file, otherwise he would have been screwed, as the intruder tidied up the system logs and all on his way out.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
Anything you don't agree with mod it down - /. used to be a nice place now it's just a lockstep groupthink prison.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
It should be coupled with a physical key of some kind like a smartcard or iButton. In some cases the physical key may be enough; it's not easy for a hacker to simulate, at least not remotely. And in cases which warrant extra security a key combined with a password would be even better. That way you're not depending entirely on the password for security. This is the method used at ATMs - you bring your card and remember your PIN.
And for the ultimate security you would need 3 things - 1.) bring something (the key) 2.) remember something (the password) 3.) prove something about who you are (biometrics)
Cheap USB or serial iButton readers could be a quick and easy fix for many corporate environments. I heard there is an implementation for Windows to permit logon only by this method.