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 ...
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.
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.
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.
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
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...
Yeah and on OS X you only need to remember this part:
d41d8cd9
A fool throws a stone into a well and a thousand sages can not remove it.
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
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.
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
Most of the people I talk to in the "art" community don't know you can get Photoshop for Windows.
Photoshop for Windows is kind of flaky (at least it wasn't that stable on my NT box), uses that godawful MDI, and at least the last time I looked, still didn't have a bunch of the major plugins that were sold on the Mac.
And I'm not a pro artist producing output for print -- I rarely do more than retouch things for onscreen viewing. Last time I looked, the MacOS had a complete, widely supported color management architecture (ColorSync) that Windows lacked an answer to. It may not seem like a big deal if you're the sort of person that doesn't have a $10k Radius monitor with a color probe and doesn't work with color profiles from all your output and input devices. But for the people putting out stuff for offset presses, this is a very major issue.
Macs had multimonitor support years before Windows. The current version of Windows has multimonitor support (and a few driver writers had hacked up pseudo-multimonitor support), but it's a pain to use -- dialogs pop up halfway across the screen and drivers fight with each other. That doesn't mean that there aren't Mac apps that aren't multimonitor-friendly, but years of people using multiple monitors has ironed out all the kinks that Windows needs another seven years or so to get rid of.
And why would someone want to migrate to Windows? I can rattle off the number of issues I have with Windows for ages. Now, Apple is hardly perfect either, but I'm not sure I'd call WinXP a better environment than OS X. There are fewer big commercial games on OS X, but if it's your work computer (or you aren't a hardcore gamer), it's not nearly as much of an issue. I'd call the Mac a reasonable choice. If you're comfortable with the Mac and you've been using it for years, then there isn't even an argument for Windows. The only Mac weakness is Apple's love for a sizeable profit margin on each computer they put out. But if you can afford to pay your way, you're looking at some good hardware and software.
Of course, if I had a G4, I'd probably just put Linux on it, but to every man his own OS.
May we never see th
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
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
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 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.
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
That's nice. How long can my TCP/IP password be?