Slashdot Mirror
Eight-Character Password Limit in Mac OS X
Qwerpafw writes "While there have been the usual small announcements about Mac OS X security problems, there has been nothing so major as to make me worry about the security of my own box. However, I recently learned that for some reason, Mac OS X only understands passwords of up to 8 characters. Any other characters typed in are discarded as 'garbage.' Well, this worried me, as 8 characters is generally regarded as a rather small keysize, with only 256^8 maximum possibilities (or about 1.845 * 10^19). This is a very real hole in Mac OS X. To make things worse, I was able to find no mention of this at Apple's website, and you are never alerted of this when trying to enter password greater than eight characters." This is generally not regarded a security "hole", and has existed in BSD for many years (though most current BSDs have moved beyond the limitation). It is something to be aware of, and it would be nice if there were a workaround ...
Here in Kansas City it's not so tough being a Mac user-- there are plenty of major chains that sell Macs or peripherals for them (Microcenter and until recently, Circuit City), a large, healthy MUG (featured on Apple's site, no less) and many third-party suppliers and repair facilities (dumpster-diving has been fun since I moved out here). There's only one real drawback of living in Kansas City and being a Mac user: the rampant art faggotry, pseudo-creativity, and nerdario emo fags associated with Macintosh computing!
Yes, sadly, Kansas City is a hotbed for the so-called "art" and "emo" communities. You know the kind. Thick, silly glasses, mussed, tussled hair, ill-fitting cardigans, sweaters, dirty jeans and corduroys, and faded T-shirts purposefully purchased for the obscure entity it advertises on it. They're everywhere, these emo idiots, and they've infiltrated the Macintosh community through their affiliation with art.
Talking to one of these jerks is as exciting as digging up your dead grandmother and trying to get her to converse with you (though as hard as it would be staring at the fetid, rotting corpse of a loved one, I'd probably rather do that than spend any time with one of these whining, pierced, star-tattooed morons). They are usually brain-dead to begin with and share a common brain with each other. If art and emo fags sharing a brain is anything like allowing multiple log-ins on a Linux server, you know the drag-and-lag I'm talking about: roughly as fast as a 4-way amputee quadriplegic fat man in a marathon, and about as sharp as a beach ball.
As easy as the Mac is to use, hardware- and software-wise, these people make it look like Apple has asked them to interface with the thing using assembler. With their eyes shut and using only their tongues to type on the keyboard. Inquiring as to what version of Mac OS they're running usually results in only being able to tell if it's either Mac OS X or not: "the old one," or "the new one," is about all you'll get. Hoping one of these sub-human poseurs knows anything about their Macs is hoping for too much. I swear to God these people bought their Macs to be different and not because they actually needed a computer that worked right.
Yeah, maybe Macs are computers for people who don't use computers. But dammit, man, if you're going to own a tool, be able to use it and maintain it. I've seen some of these idiots on high-speed connections that are 4 or 5 OS updates behind. My favorite are the clueless slags who run 9.0 on their Mac and refuse to upgrade to X for whatever reason and haven't even touched 9.1 or 9.2. I mean, if you refuse to move up to X, at least be running the latest Mac OS 9 update that you can.
Kansas City's a great place, don't get me wrong. But the "art" community here, as well as the emo scene, make being a Mac user a little embarrassing. Maybe it's just me, since I moved from an area that wasn't so saturated with subculture shittiness and gayness, but I am having a harder and harder time being the proud underdog Mac user with these vegan indy-rock retards standing in my corner.
Will I abandon the Mac because of them? No. The Mac experience is finally growing my leaps and bounds again after half a decade of holding pattern. But I will start kicking ass and taking names the next time I see some slobbering, giggling emo retardo talking about his new iBook or Power Mac G4 louder than necessary, letting people know how "different" he is.
And that's a promise.
What is exactly the point here?
As long as people are careful in the way they make passwords.
Don't use words from the dictionary. Don't use personal information. Do mix up alpha-numerica and uppercase/lowercase. Throw in some punctuation if allowed.
In other words: make it as randon as possible. This will make it more difficult to brute force crack.
..except that i believe this is defined in standard unix (system v, i think). Various Sun OS's have the same problem -- passwds can be longer than 8, except that the extras are ignored.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
It could still be worse. Windows for example stores passwords of any size in seven-character hashes. You could use the strongest password you want, but it will be no stronger than the best group of seven charcters stored. For example, suppose you use the password h9QY*(f9v3h4. Windows would store one hash of h9QY*(f and one hash of 9v3h4. By the time a password cracker cracks h9QY*(f it would have already cracked the 9v3h4. With so much reliance on passwords, why aren't stronger passwords/passphrases properly supported? I wouldn't think it'd be that difficult.
If I'm forced to limit a new password to eight letters, I generally pick up the nearest book, flip it open randomly. I then spot the first four-letter word I see, flip to another page, repeat, then combine them and change any letters that look like numbers (such as o -> 0, s -> 5, or l -> 1). Certainly works better than "password" written on a Post-It hidden under the keyboard ;-).
Sorry to nitpick, but there are really only about 94^8 combinations (26 upper case, 26 lower case, 10 numerals, and ~32 symbols), which equals 6.095x10^15
The reason is that on most systems you can't simply enter those extended characters.
Jaguar is supposed to be more in sync with the current state of BSD. Maybe this "problem" goes away in september...
blog
Jaguar is supposed to be based off of a much newer version of BSD (something like 4.4 or 4.5) that should have this problem fixed. This only applies if the fault is in the unix underpinning alone and not in the MacOS.
4 Alpha-Numeric 2 Numeric 2 Extended ASCII (like +, >, ~, *)
I think the odds are better of someone getting a remote root shell then cracking my password.
I'd even wager that most people use nearly the same passwords for multiple accounts rather than random strings.
I like big butts and I cannot lie.
Let's say we could use any of approximately 96 printable ASCII characters (in actuality, the password may allow non-printable, or international characters)
Also, let's assume passwords must be at LEAST 4 characters (I don't know what restrictions, if any, are applicable to MacOS X).
Then we have 96^8 + 96^7 + 96^6 + 96^5 + 96^4 = 7289831534100480 passwords.
So, assuming about 10% of those are "guessable" by standard dictionary cracking methods (a ridiculously high amount), you have 728983153410048 non-guessable passwords (about 2^52).
That is A LOT to brute force. That doesn't even take into account the use of 'salts' to help discourage dictionary attacks.
So, true, allowing longer passwords would be nice. But it isn't even close to a troubling limitation.
If you need more protection for your data, use mcrypt.
A bigger concern would be if Mac OS X didn't use a shadow password file (anyone?), and if it doesn't at least to a rudimentary check to disallow easily guessable passwords. I assume Mac OS X can be configured to be insecure (boot up into desktop without a password), or more secure (passords required, easy passwords disallowed, etc.)
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
The reason is because a long time ago this was an inherent security hole at least the idea. In the good old days you could specify a password of unlimited chars, the first 8 characters were the only ones used and this has been buried deeply inside of *unix for quite sometime now. It's really not a security hole and maybe someday someone will sit down and change it.
Seemingly this exact question is asked every year around Jun/Jul/Aug. Weird, are people changing passwords around this time or what?
This has nothing to do with apple's darwin or any of that. It's really just the way things have been for quite sometime. If you feel like switching the code then go ahead. Just be prepared to break compatibility with alot of programs. Whats the big deal anyway?? Key size doesn't really have jack to do with this if you choose a proper password; numbers, letters, etc extended chars combined in one password would take sometime to crack and thats assuming the person can get your passwd file. Blah lemme not even start this debate =)
In linux I will touch filename and then md5sum filename, then use the md5sum for the password, very secure and very easy to remember because "filename" could be as easy as your own name.
keanmarine.com
I'm not completely positive, but I don't believe that OS X supports shadow passwords currently.
/etc/passwd file, any user can get a clean passwd database by running "nidump passwd ."
In fact, even if you somehow lock down the
That's scary to me.
But what do I know...
I note all my solaris boxen only recognize the first 8 characters of the password, as do my five *gasp* --> LINUX And of course, what post would be complete without mentioning that Windows 9x has a 0 character limit.
Maybe it's not using md5, but just crypt. i remember old versions of BSD and linux (as recently as 3-4 years ago, before MD5 passwords where introduced) using this form of password storage.
I have yet to be convinced that Apple is "serious about security" as I hear the pundits say. Here at LLNL, we've had any number of Apple representatives give OS X talks. They all mention how important security is to Apple. But things like "nidump passwd ." and the fact that Classic runs as setuid root tell me otherwise.
/System/Library/CoreServices/Classic Startup.app/Contents/Resources/TruBlueEnvironment" .
(For verification of that last one, do "ls -l
> That is A LOT to brute force. That doesn't even take into account the use of 'salts' to help discourage dictionary attacks.
Forgive the newbie question...
How do you implement 'salts' to identify dictionary attacks?
In Jaguar the BSD subsystem is supposed to be synchronized with the features of FreeBSD 4.4, which has MD5 passwords among other choices. I wonder if this means Jaguar will include that as well? Pure speculation, but it sure would be nice, both for security reasons and for more interoperability with other Unixes. I've got a few remote FreeBSD users that I'd like to add to my OS X machine, but I haven't found a good way to move the passwords over without resetting them completely.
Say hello to zMac.
Has anybody actually tried to brute force this? Boy, the signal to noise ratio on /. has gone to hell. Does anybody even know where the password files are kept on OS X? I mean really!
... you do the math. Even if your data is still around by then, you sure won't be. Even a dictionary attack would take weeks.
What kind of attack are you guys talking about? In order for someone to get the password file, they've already gotten root access to your box, so that's a moot point.
By default there's no open access to the box, if you turn something on it's likely going to be something that you at least kind of monitor, so someone using all of your bandwidth for a couple of days trying to brute force your passwords as fast as possible would probably get your attention, and leave them WIDE OPEN for being found out. But even that scenario is outside reasonable plausibility...
even if you do turn on something like ssh, it pauses before letting you try a password, and only gives you 3 strikes before you have to wait again. Telnet is similar if you edit the config to even allow naked telnet. So at best lets say 3 tries per second
Posix specifies that passwords be limited to 8 bytes. The newest draft (to be released in Q4 of 2002?) will allow longer passwords.
Well, it's a unshadowed passwd database. It's exactly what you need to run a password cracking program.
The first line of defense, making the encrypted passwords unavailable to ordinary users, is already breached by the system itself.
A "salt" is a little bit of randomness to increase entropy (information content). Say you have a simple password ("apple"), without a 'salt' added. Then someone just needs to encrypt the entire dictionary, which has the word "apple" in it, and compare the encrypted result to your encrypted password. They will easily be able to see that "apple" is your password (because the encryptions match). Note that they only had to encrypt the dictionary ONCE, to detect any simple dictionary password.
Now, suppose that your password "apple" had 12 random bits added to it BEFORE it was encrypted. Those 12 random bits are not-secret (they are published along with the encrypted password+salt). The person who wants to use a dictionary attack on your password has to first look at your salt, and add it to all the words in their dictionary before encrypting and comparing them. Thus, they either have to generate (and store) encrypted dictionaries with all possible salts, or wait until they know your salt to start encrypting. Either way, you given them more work (possibly a LOT more work).
Finally, if they get a thousand encrypted passwords, each with a different salt, they have to do 1000 dictionary searches (one per each unique salt), rather than just one.
So, 'salts' are just small bit of randomness that are added to a lot of cryptographic protocols (and are crucial to certain more advanced protocols), do basically eliminate certain simple cracking methods, without adding much complexity or work for the legitimate users of the protocol.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
Suppose I have a password like this:
That is an extremely strong password that somebody might actually be able to remember. A flawed OS that truncates it to eight characters will use this: Which turns an NSA-class password into a Gomer Pyle-class password.-- ;-)
Kuro5hin.org: where the good times never end.
Isn't this a "problem" for all unices? Yes I know some have moved on to a larger size... none the less this is far from new in the mac world... it was widely reported when OS X PB, 10.0 and 10.1 came out.
.4yd93bn still 8 chars but very hard to crack... shit i now need a new password :(
However the real hole is if you use worlds... like Apples and not some more complex password like
The manpage for passwd(1) in Mac OS X 10.1.5 claims that password hashes can be in one of three formats, including MD5. An md5 password can be up to 255 characters, so where do we get this 8 character limit?
This story could be true, but it doesn't seem likely on the face of it.
Please followup with a verifiable citation or some sort. Otherwise this is a silly rumour.
Thank you
Unfortunately, Mac OS X uses netinfo to store most of its information and all of the information, including passwords, are available to anyone who can execute nidump. i.e. nidump passwd .
This is such a limited mind geek mentality and it really pisses me off that a parrot would be the first on the scene...
LET PEOPLE USE THEIR COMPUTERS AS THEY SEE FIT!!!
There is absolutely no excuse for the "oh this is good enough" mentality. A password like "I don't like people who limit my choices!" is obviously more secure if you're just going to cite the numbers for brute force, is not going to get shoulder surfed, and is not going to need to be written down...
wtf? let people use long passwords
and as for the availability of md5 per comments below, yeah it's there and NO the login app/possibly netinfo don't support it...all you have to do to see this is make a md5 has of a simple password and paste it into netinfo where it says passwd under users/whoever, it doesn't work, so it's functionally useless currently
If you use the user management tool provided in the system preferences (where most people create a user), only the first 8 characters are used. The others are dropped. There is probably a way to use more, but I don't really feel its an issue.
Where it may have an impact though is the password keychain feature. My preferences are set so that when I login, the keychain is unlocked, saving me a lot of hassle. If those passwords need to be much stronger, I'd be in trouble. A brief description of the keychain from apple's site is here.
There was a comment earlier about whether osx does password shadowing; it does.
yeah it's there and NO the login app/possibly netinfo don't support it...all you have to do to see this is make a md5 has of a simple password and paste it into netinfo where it says passwd under users/whoever, it doesn't work, so it's functionally useless currently
Well yeah, but I think here we are addressing a different group of users. as for myself I use nicl in commandline. or passwd whatever it takes. for System Preferences Panel, I think Apple may have a point to simplify things for average joe user.
well.... osX doesnt use a shadow password file. it uses its NetInfo database (sort of like a grown up/mutated version of YP/NIS) to store the actual password information.
Okay listen up if you don't know enough about Unix to know that a lot of Unices use DES ecnryption to do passwords(which allows for only 8 chars), then you shouldn't be fucking with CLI, or at least don't expect things from it that aren't stated. Most Unices still use (or provided compatibility for) DES hashes as opposed to MD5. Apple is not that far behind the curve give it up, it's a stupid topic. The people who should know about security will already know all this and the people who dont really don't need to worry this much about security.
The GUI for all of this seems to make it clear tat it's only worrying about the first 8 chars.
Patrik
----------
Just your ordinary BOFH
http://killertux.org
I agree that this isn't exactly a new issue. I could easily be wrong, but it seems to me that with a GUI Apple could more easily provide an alert to the user.
Maybe not. I think OSX does seem to handle a brute force entry decently.
But is "decently" enough given the lack of warning, given the lack of documentation?
This issue keeps being raised over and over. I can't find anything new in the thread (so far) that comes up with an adequate solution.
If I missed it or you know something recent kindly clue me in if not everyone else as well.
Many thanks.
To bring this from the theoretical to implementation details:
If you look at a standard crypted password in a UNIX password file, you will see something like this:
f6HXOu/NErmqM
The first two characters are always the salt ("f6" in the above example. The password is xyzzy. What this means is that there are 4096 different ways to encrypt the word "xyzzy" (because salts are two characters from [A-Za-z0-9/.]). Other ways to encrypt xyzzy with different salts:
q.XRwCdLMrhAI
9M7WQHXYLACb6
So if you wanted to generate a dictionary of passwords and their crypted equivalents, you'd have to actually generate 4096 of those dictionaries in order to be able to find any potential password you'd come up against.
But for the legitimate user, salts provide no real additional work. If we want to verify that the password the user typed in is correct, we look at the salt on the crypted password ("f6") and call crypt with that password and salt:
crypt("xyzzy", "f6")
If the result matches what's in the password file, we know we've got a valid password.
Old NeXT hands know this because that same weakness existed (and was complained about yet never adequately addressed) back when NeXT existed and NeXTSTEP was actively being developed. NetInfo didn't scale up very well and it never had shadow passwords, two qualities that made it not seem so attractive for local administrators I knew back then. But I'd say this is really just another example of why you should care about your software freedom. After a while NeXT stopped caring about the underlying Unix layer (in NeXTSTEP and OPENSTEP this was 4.3 BSD) and the tools they shipped (an antiquated sendmail that had plenty of holes, for instance) and cared more about things like WebObjects and various high-level "kits" (some of which died before being developed very far).
It was this experience that helped lead me to caring about Free Software operating systems and running only Free Software on top of those systems. Because there I know if there's a hole I can choose to wait for someone to fix it for me, or learn to fix it myself, or hire someone to fix it for me. How much delay I impose on myself has more to do with my willingness to learn about and/or pay for.
Digital Citizen
I'm hoping that Apple will learn from some of the mistakes of NeXT. Since Darwin is now "open source", maybe there's a chance that the major holes in this legacy security system will finally get patched.
While this is true, the keychain is somewhat more secure.
By default, the keychain takes the login password, but it uses the full length, not just the first 8 characters. If you have a 15 character login and make a mistake in the 10th character, you will be logged in. However, you will have to reinter your password (all 15 characters) to access the keychain.
This is good b/c the keychain protects a lot of stuff but it still would be nice to know that your login password is only 8 characthers long.
Article ID: 106765
Created: 2/26/02
"The effective password length for Mac OS X and Mac OS X Server is eight characters. You may type more characters, but they are ignored."
The keychain for storing passwords in a encrypted AES package can take up to 34-charachters.
Unfortunatly , it is the BSD layer that limits things to 8.
I think it's Appletalk related. In OS 9 an appletalk password can only be 8 characters long....
Yes, in will accept a 9 character password, but it only looks at the first 8. Try entering only the first 8 characters next time.
as others have said, this is neither news nor specific to OSX. Solaris 2.6, Solaris 8, and AIX 3.4 all exhibit the same behavior.
Maybe this is a security issue, maybe it isn't. MacOS X comes with sshd and telnetd disabled. Unless you turn these on I'll need physical access to your box to even begin a brute force attack. Of course, if I have physical access to your machine I'm already done and don't give a hoot what your precious 8 character password was.
kevin
I tried this on some different platforms and found that Solaris 8, AIX 5 and Tru64 4.0F only use 8 chars.
HP-UX 11 uses more than 8.
I could have done a few more, but our SGI IRIX, Dynix PTX, Sinix and DG-UX boxes are offline.
Now, is it just me or does this article seem like a troll? Both from speaking to other users and from personal experience, loads of good articles get rejected then crap like this get's posted...
Anyway...
By default, Unix systems have typically had an 8 char password limit for decades. An 8 char limit for usernames, groupnames and passwords is part of the Unix standard.
"Why?" I hear you ask...
Well, deviating from this standard causes things like servers that often make use of authentication (e.g. FTP, Gopher, SSH, etc), NIS/NIS+ and various other local command line utilities to break. That's why you shouldn't deviate from the standard.
Mac OS X, Darwin, AIX, Sco, Solaris, Irix, HP-UX, FreeBSD, OpenBSD, HURD and Linux all have this limit with DES passwords. Additionaly, all of these Operating Systems support alternative authentication mechanisims though (but you should *still* never have a user or group name longer than 8 chars).
If you don't like it, you have the option to configure NetInfo to authenticate against another source, like say an OpenLDAP database, a Novell client or a Microsoft Active Directory server. If the system you are concerned about is a desktop system an 8 char passwd limit is your last problem, if it's a sever SSH can be configured to require an authentication certificate and so again, is a moot point.
This is not even a remotely serious problem given the context. Anyone that thinks so is (a) so paranoid as to be mentally ill or (b) doesn't know enough about the topic to comment.
This can't be stressed strongly enough: If you have data that's important (that is to say 'sensitive'), you should encrypt it, which is trivial to do by making a an encrypted disk image in Mac OS X (using Apple's included GUI utility: Disk Copy) then making it a login item and mounting it at login using scripts.
Crap Pudge...quit being such a chicken little for God's sake.
- this is not a mac issue
- this is not a new issue
- this is not an issue
your imaturity is showing.
Seventh Edition password encryption is long past its use by date. Apple need to do better.
I think this was a decision to use the crypt (that might not be the name) algorithm over the more modern MD5 (again im not sure those are the right algorithms but its not relavent to the argument) while the first is limited to 8 characters ( you can have longer passwords, but you only need the first 8 to log in) it takes significantly more cycles to use therefor brute force attacks on short passwords take longer time, since most users dont have passwords longer than 8 characters anyway it makes sense for a consumer OS to use the former rather than the later seeing as 95% of passwords will be more secure with the more expensive algorithm because they dont take advantage of the extra length the more modern one provides.
at least i remember this being hte official explanation from apple, ill draw my own conclusion after a couple more semesters of algorithm lectures....
if it's true i take my hat off to apple for going for real security over the bigger numbers are better public theory.
--aiee
Now, one year later, that your computer is 3 times as fast, how long would it take?
Now, with distributed computing (I have 4 computers in my house), how long would it take?
Just a thought.
For example the 'passwd' data is readable by everybody via netinfo. netinfo has no read/write per user/group privileges.
I don't think the 8 character password limitation will go away any time soon. The problem is so many protocols use the 8 character limit like AppleShare.
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Mac OS 10.1 & 10.0 stores passwords using the crypt hash. the implementation of this hash only uses the 1st 8 characters, others are disgarded. 8 characters is enough for a good password 700 characters is too short for a "bad" password changing Mac OS 10.X?? to not use crypt would cause many compatibility problems changing future versions of the OS to not use crypt causes compatibility problems with Mac OS 10.0 & 10.1 - if you want to run a mixed network and move away from crypt. NetInfo has no read access controls - and is the default storage for all user/password data NetInfo itself is dependant on the crypt passwords... NetInfo is a replicated and distributed system... to move NetInfo off of crypt, requires that all NetInfo servers be upgraded at once - since non-crypt servers would confuse crypt based servers.. all passwords hashes are visible from NetInfo via ni_dump if you think about it long enough (I have) you can't do shadow_passwords with NetInfo. having access to any form of a user's password (hashed, encrypted or otherwise) opens you up to brute force offline attacks. The password hashes/crypto-data must not be visible at all - making this information "hidden" breaks much software. A 1 ghz G4 is an excellent brute force processor that can to many, many things very fast. changing all of this requires changes in the GUI and all command line tools to no longer assume a readable crypt password - the question is what does Apple adopt as an API to verify a password - and how much work is it for them to release a full OS that has this problem completely addressed? this can be done, but needs to be carefully organized since Apple provides a consumer grade OS where people just expect things to work. if you want to support network based user accounts (i.e. same user name/password on multiple machines via LDAP or NetInfo) this is slightly more tricky... if you want to share this user name/password with LAN server protocols that have legacy authentication requirements (CRAM-MD5 or APOP for example) it gets even harder.. if you want all of this to be secure - then you have to pay people to do all of this, and you have to think very carefully about all compatibility issues, rather that a couple of local user accounts in a /etc/password file
you have to provide administration tools that let Apple's customers do all this fancy stuff, and not require them to subscribe to slashdot to understand what it is they are doing.
you then have to document, migrate, and upgrade your installed based, and do so in a manner that customers don't even realize you've done it
customers will expect 10.1 & 10.x to co-exist on their network and not realize that changing the password storage will break 10.1
authentication is hard - ask anyone who has had to design a distributed, shared, replicated, and secure authentication system, that also supports legacy protocols such as FTP, SMB, NFS, AFP, POP, IMAP, LDAP, ssh, telnet, etc....
crypt/md5 can't support most "secure" challenge/response authentication methods required by many LAN protocols.
I'd guess Apple is working on the problem - but I doubt they have the ability to only fix part of this problem - their customers require a complete solution...
it will be interesting to see what options they support in the future...
stay tuned
The default password encryption algorithm on UNIX is "crypt", not DES. DES may eventually have made it into some commercial versions.
Furthermore, neither DES nor crypt impose intrinsic limitations on password length; it's easy to devise ways of using them with passwords of arbitrary length.
The people who should know about security will already know all this and the people who dont really don't need to worry this much about security.
Spoken like a true Apple zealot. Well, it's good if people with data to protect worry about how to protect their data. And a limited space of passwords is definitely something to worry about. Apple should go to MD5 and long passwords ASAP.
See apples article 106765
See apples article 106765 it layes it all out. Good golly many get your head out of the sand.
I have a FreeBSD fileserver at home and I use ssh to log into it with keys automatically. No password is necessary. This is very secure.
I also have a remote FreeBSD server also set up with a public ssh key so that I can log in without typing a password. So if someone is really concerned about security, they can just use ssh to tunnel communcations (shell, cvs, scp).
But most systems, especially my iBook at home, does not need very long passwords because it does not run very many network services and does not hold critical information anyway, like a database of credit cards. And if I do run remote services (ssh, ftp) on the iBook, I can always use the ipfw firewall to deny traffic to these ports except from specific locations. In fact, I run the MySQL database server and block port 3306 for remote connections so it cannot be accessed remotely.
So for me the password issue is moot. If someone is really serious about security, they should know enough to take care of it without seeing the 8 character password as a security hole.
Brennan Stehling - http://brennan.offwhite.net/blog/
It's still insecure. Any user can "nidump passwd ." and get the entire password file.
there != their
your != you're