Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Businesses Apple

Eight-Character Password Limit in Mac OS X 124

Posted by pudge from the welcome-to-bsd dept.
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 ...
This discussion has been archived. No new comments can be posted.

Eight-Character Password Limit in Mac OS X More

Eight-Character Password Limit in Mac OS X

Comments Filter:

  • 8 characters should be more than enough (Score:4, Informative)

    by Tim_F ( 12524 ) on Wednesday June 12, 2002 @06:09PM (#3690179)
    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.
    • This will make it more difficult to brute force crack.

      No it won't. It will make it more difficult because brute force will be required to crack, after dictionary attacks are exhausted.

      BTW, are we sure that the characters after 8 are simply ignored? They aren't hashed with the rest of the password? ie...

      eightcharacter becoming a hash of...
      eightcha
      racter
      --------
      ????????

      Which would still effectively be a password of 256^8 strength (assuming all 8 bit characters can be used), but would render a simple dictionary attack useless for passwords over 8 chars. Of course, if this were the case, a dictionary cracker could be written to take this into consideration, allowing quick cracking of dictionary passwords even over 8 chars, falling back to brute force failing that.

      However, my girlfriends 550MHz Celeron Thinkpad brute force cracks with L0phtcrack at 800,000 keys/second. If this were a yardstick, her notebook would take 731 thousand years at most to brute force crack a 256^8 password! So I'm not too worried yet. The NSA or a distributed attack no doubt could probably do it in no time though. ; ) But I doubt the NSA or a large group of people want to crack my passwords, though something larger than 8 chars would still be nice.

      • There's a flaw in that logic. Not all 256 possible values for a character represent printable or typable characters. A more realistic value would be alpha (2*26) + nums 10 + shiftnums 10 + syms 11 + shiftsyms 11 or 94^8. Yes, it may be possible to use certain control characters and stuff to insert arbitrary high ascii values or an acute e or whatever, but if you do, you will run into compatibility problems when you move from machine to machine.

        That makes it only 241 years. :-)

  • ..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.

  • Could be worse (Score:3, Informative)

    by silicon_synapse ( 145470 ) on Wednesday June 12, 2002 @06:15PM (#3690212)
    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.
    • About a year back I had reason to indulge in cracking Windows .pwl files....

      A few of the script kiddie tools I acquired would calculate how fast it would take you to crack passwords of X length...

      If I remember right, 7 character passwords took approximately for-fucking-ever (months), and even longer if you expanded the brute force to include special characters as well as A-Z and 0-9...

      Good thing the password I was trying to get was only 4 characters which takes about 10 minutes.

      Not that anyone should be using Windows Password to protect anything important anyway...

      Tim

      • Times Change (Score:1, Insightful)

        by Anonymous Coward
        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.
    • Don't forget that the LanMan hash you're talking about converts everything to upper case and doesn't use a salt. I have no idea which idiot at MicroSoft came up with that scheme after the UNIX crypt password scheme had been out for a long time. LanMan is obviously based on crypt (itteratively encrypting a known string with DES, using the password as the encryption key), but it's much worse (except that it can use extended ASCII characters, but this doesn't help much at all since 99.99% of people don't go outside ASCII for thier passwords). There's a newer NT hash based on md4 (yes, md4, the precursor to md5) that also does not use salts. When will MS learn?
      • Bruce Schneier states that "I am wary of using MD5", due to a "weakness in the compression function". "one of the basic design principals of MD5 - to design a collision-resistant compression function - has been violated", though "this has no practical impact on the security of the hash function".

        However, the full MD4 algorithm could not be attacked.

        So I wonder how much better MD5 is over MD4? More complex might not mean better at the end of the day.

        SHA1 seems to be better and has not [terra.com.br] had any successful cryptanalysis attacks yet. But the original SHA spec had a flaw that the NSA refused to elaborate on, which has most likely been fixed in SHA1.

  • 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 ;-).

    • Re:Methodology (Score:2, Interesting)

      by brunson ( 91995 )
      I bet you John the Ripper [openwall.com] would crack your password in a matter of hours. They've built rules into it to do those letter to number conversions.
      • One way to foul them up to use non-typcial number substitutions (like using "15" for "b", because b is the 15th number of the alphabet after you ROT13.)

        While you are at it, use a number as a number instead of a letter substitution. If your random words are "book" and "the", then throw your lucky number into the middle of it: "book42the" then when you do the letter-for-number subs, some typical some not, and mix the case just a smidge, you get "15o0K427h3", which your friend John the Ripper would not get to very quickly (even on a BSD system, which only looks at the first 8 digits: "15o0K427").

    • My twist on this method is to use letter to number translations based on Japanese colloquial pronounciation of numbers. Of course, the original sequence is derived from initials or not-quite initials of nonsensical phrases. e.g.
      Rip TO sHreds Eat 9 Funny Monsters 2 Day.

      Once I have a phrase or subsets thereof,
      any "yo" syllable can be converted 4 because "Yonn" = four, and "ro" or "lo" syllable can be converted to 6 because "roku" = six. etc. etc. And sometimes the reverse translation can be performed.
      Works for me, and I can remember them.

      I hope it's not easy to crack.

  • Not 256^8 (Score:4, Insightful)

    by mfos.org ( 471768 ) on Wednesday June 12, 2002 @06:16PM (#3690222)
    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.
    • Hmm, I screwed up as well, it really should be 94^8+94^7+94^6+94^5 (Assuming passwords smaller than 5 are not allowed)

      This doesn't really change the bottom line that much, instead of 6.095x10^15, its now 6.161x10^15
  • Jaguar is supposed to be more in sync with the current state of BSD. Maybe this "problem" goes away in september...

  • Should be fixed in Jaguar (Score:2, Informative)

    by Anonymous Coward
    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.

  • lapprox 96^8 = 7213895789838336 possible passwords (Score:5, Insightful)

    by ChadN ( 21033 ) on Wednesday June 12, 2002 @06:30PM (#3690319)
    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.)

    • shadow (Score:3, Informative)

      by SeanAhern ( 25764 )
      I'm not completely positive, but I don't believe that OS X supports shadow passwords currently.

      In fact, even if you somehow lock down the /etc/passwd file, any user can get a clean passwd database by running "nidump passwd ."

      That's scary to me.

      But what do I know...
      • Eeee... youch! I have just confirmed this: typing in the command "nidump passwd ." will give a passwd-like database, for ANY USER. This is a serious problem!
        • 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.

          (For verification of that last one, do "ls -l /System/Library/CoreServices/Classic Startup.app/Contents/Resources/TruBlueEnvironment" .
          • The nidump command is definatly a real concern. There was much talk about it on the Darwin Developer list awhile back. In short, they are aware of the problem and want to fix it, however it is not a trivial problem to fix for various reasons.

            The fact that classic runs setuid as root I can't blame them for. Classic is to run programs that haven't been ported to OS X, so they operate on the assumption that their is no such thing as permissions in their environment. It would probably cause problems for many programs if this changed.

            If you are serious about security, don't run classic. If you have to run a classic app, than OS X is still at least as secure as OS 9, you're only other option.
      • What can you do with it? I'd like to know.

        So if a random user on a network of OS X machines with multiple accounts per machine (school lab or such) this makes it really easy to assume another identity?

        I'm curious, someone fill the details.

        • 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.

      • No shadow passwords in NetInfo (Score:4, Informative)

        by jbn-o ( 555068 ) <mail@digitalcitizen.info> on Wednesday June 12, 2002 @11:36PM (#3691719) Homepage
        In fact, even if you somehow lock down the /etc/passwd file, any user can get a clean passwd database by running "nidump passwd ."

        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.

      • In fact, even if you somehow lock down the /etc/passwd file, any user can get a clean passwd database by running "nidump passwd ." That's scary to me.
        Then, just do a:

        sudo chmod 500 /usr/bin/nicl /usr/bin/nidump /usr/bin/nifind / usr/bin/nigrep /usr/bin/niload /usr/bin/nireport / usr/bin/niutil

        Now, all of the NetInfo commands can only be run by root.
        (You could just execute "sudo chmod 500 /usr/bin/ni*", but that would also restrict nibtool and nice to root)
        • Why bother? If you already have access there is not much stoping you from copying these programs from elsewhere. As far as I can see these program does not need to be suid root to work.

      • Re:shadow (Score:2, Informative)

        by Taliban Lecher ( 539524 )
        /etc/master.passwd is *NOT* readable by users. /etc/passwd is only for single user boot.

        But: nidump isn't even suid or sgid, but netinfod is running as root and suspect to spill the beans.

        chmod go-rwx `which nidump` therefor would not help either, as any user can grab a binary from elsewhere.
    • 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 .
    • But it isn't even close to a troubling limitation.
      Wrong. In their 1989 paper, UNIX Password Security - Ten Years Later [nec.com], David Feldmeier and Philip Karn wrote the following.
      ...rapid improvements in computer price/performance ratios over the past decade call into question the adequacy of the present UNIX password algorithm.
      Given 20 machines and the numbers above, it is probably reasonable to do an exhaustive search of passwords of length 7-8 lower-case letters, 7 lower-case letters and numbers, 6 alpha-numeric characters, 5-6 printable characters, or 5 ASCII characters. The moral is keep your passwords 8 characters long or use lots of unusual characters, but in no circumstance use less than 6 characters. Of course, if the crypt/second/dollar ratio increases by another five orders of magnitude in the next decade, only eight-character passwords that utilize the entire ASCII character set will be immune from brute-force cracking!
      I don't know what software improvements have been made to crypt since 1989, but Moore's law alone should give us 2.5 orders of magnitude hardware improvements in 13 years.

      Seventh Edition password encryption is long past its use by date. Apple need to do better.

  • 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 =)

    • Key size doesn't really have jack to do with this if you choose a proper password; numbers, letters, etc

      What if I choose a key size of one bit? That might matter..

    • It's really not a security hole and maybe someday someone will sit down and change it.

      They have. Linux, at least, supports using MD5 rather than crypt for hashing passwords. I believe that the BSDs do something similar (of course, the BSDs only provide /etc/passwd as a compatibility measure for applications that process user information by hand - the crypted passwords themselves are only in /etc/master.passwd and the binary databases generated from there).

      Just be prepared to break compatibility with alot of programs.

      Eh? If you've got shadow passwords, any user apps won't be able to see the crypted password anyway. What applications are you thinking of, and why the hell are they trying to do anything with my passwords?
      • Hrmm lets see, basically all those small programs that did something with the password to begin with. IE: encrypt them, or just use the system for user AUTH..ie NIS setup.. all sorts of tiny little things can break compatibility, I mean.. it would work but it wouldn't really be working. For instance take one of the hundreds of utils to encrypt the password. They are only grabbing the first 8 chars, everything else is thrown out. If you switch the system to lets say 16 chars, it's still only grabbing the first 8 so 8 of your chars are not encrypted, if it encrypts the stuff at all. You could defeat this if the program uses the crypt library but what if said programmer was following standard and wrote his own library. There are so many if's; not that it's a big problem but people are gonna bitch as usual. The only systems that really don't have this problem are C2 systems and I think they have to have an unlimited (nitpickers ie: very large not really unlimited or infinite) number to be certified c2 systems.. but they also log damn near every keystroke (nitpickers ie: you get it) which obviously takes alot of space unless you redirect to a printer.. but then thats alot of dead trees.. ok I'm rambling.
        • For instance take one of the hundreds of utils to encrypt the password.

          You mean passwd? This is generally done with something like PAM nowadays. People want to be able to authenticate from things like RADIUS, Kerberos and LDAP, so applications which fuck about with /etc/passwd directly are already dead in the water.

          You could defeat this if the program uses the crypt library but what if said programmer was following standard and wrote his own library.

          Applications should not be encrypting passwords themselves and writing them to /etc/passwd. It wouldn't even work with shadow passwords. It certainly wouldn't work on *BSD (On the BSDs, /etc/passwd is generated from /etc/master.passwd. /etc/master.passwd is a different format to /etc/passwd. Oops. Your "hundreds of utilities" don't work on several OSs already).
          • Ok.. I'll give you the short, do you wanna migrate all these machines over at MEPS for me?? The way it was and the way it is are two different things. Your assumptions are based on the "is" way and not the "was" way. Sure the whole thing could be revamped but there is alot of redtape you gotta go through. The world isn't as black and white in some areas especially the military.

            Several Os's?? Really? Name some if you don't mind. Seems to be working for some old machines my unit has and all those machines are digital unix. The ones that are of any concerning value are the military processing station ones.. but since you seem to have the answer I'd surely love to hear it.

            If you'd like to see the end of this debate ahead of time feel free to join any unix newsgroup and post this conversation. Holding it on slashdot is a bit stupid and I've gotten into this type of convo every year for the last couple of years.. this year I'm doing somethign different.
    • I've been using passwords longer than 8 characters for quite a while now (Slackware). Strange that the SuSE setup that I've got now also has the 8-character limitation.
  • 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.
  • 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.
    • crypt() is defined to be the standard to encrypt passwords. What crypt() actually does is dependant on your system. If you want to use MD5 passwords, then crypt will generate MD5 passwords, otherwise, it'll just produce the default encrypt routine that every *nix has used for just about forever.

  • Jaguar? (Score:3, Interesting)

    by Van Halen ( 31671 ) on Wednesday June 12, 2002 @07:23PM (#3690639) Journal
    In Jaguar [apple.com] 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.

  • It is a hole (Score:2, Insightful)

    by sigwinch ( 115375 )
    This is generally not regarded a security "hole"...
    <megaphone>Sir, step away from the keyboard.</megaphone> Silently truncating passwords is a security hole of the first magnitude.

    Suppose I have a password like this:

    password weasel frycook barn tasteless thames gargoyle mascot
    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:
    password
    Which turns an NSA-class password into a Gomer Pyle-class password.
    • HI JOKER.....
    • Silently truncating passwords is a security hole of the first magnitude.

      I understand your point, but, in practice, your example is very rare. It is pretty much human nature to compose short passwords of one or two words, and it is wise to put non-alpha characters in there just to mix things up. Even a properly chosen 6 or 8-character password is hard to crack, and to do so properly would require obtaining a shadow password file (I hope this isn't trivial, either).

      When I saw the article, I didn't think much of it, because even Solaris 8 uses 8-character passwords by default (I believe it can be configured otherwise). Keep in mind that neither Mac OS X nor Solaris 8 are being sold as end-all be-all secure operating systems. There are other systems, such as OpenBSD or a highly-tuned Solaris configuration, for example, that are more appropriate for secure uses.

      Also, short passwords are usually usurped by bad organizational password policies as a security issue. Every time I hear of someone cracking a passwd file for fun, they tend to get a suprising number of passwords with little effort.
      • I understand your point, but, in practice, your example is very rare. It is pretty much human nature to compose short passwords of one or two words, and it is wise to put non-alpha characters in there just to mix things up. Even a properly chosen 6 or 8-character password is hard to crack, and to do so properly would require obtaining a shadow password file (I hope this isn't trivial, either).
        As many have pointed out, "nidump passwd ." does that. Any user at all can do that. Which is why I was pissed about the 8 digit limit.
      • It is pretty much human nature to compose short passwords of one or two words, and it is wise to put non-alpha characters in there just to mix things up.

        Yes, you should mix e.g. digits and a few totally random letters or so. The following is a common type of password, and a good one too (not easy to guess or crack):

        jennifer7Q3gG

        Now, what really happens if the OS without ever letting you know truncates that down to eight characters (and if the user happens to be a fan of Jennifer Lopez)?

    • Yeah, now lets see if you 10x a day
  • 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
    • its rather nice that you doubt this. actually, I said "bull shit" directly to the face of the person who told me about this.

      The problem is that the problem is very real, and quite substantiated. Here is how to prove it:
      Step 1: Get a box with Mac OS X (okay, so this might not be possible for you, you'll just have to trust someone who does)

      Step 2: Make a new user. call him "bullshit" or whatever you want (actually, it was "root" in my case, which kind of makes this more upsetting).
      Step 3: Make this user's password something bigger than eight characters.
      Step 4: go to log in as this user. A quick way would be to go to the terminal, and type in "ssh user@localhost"
      Step 5: try typing in only the first eight digits of the users password. It will log in.
      Step 6: try typing in only the first eight digits of the user's password, followed by an entire dictionary full of garbage... again, it will log in.
      Step 7: Get pissed off at apple.
      Now, you can believe me or not. Its up to you. But ask anyone with a mac box to try this, and you will see...

      However, as an aside, I hear that apple may be fixing this in Mac OS X 10.2, aka Jaguar. This is because jaguar is supposed to unfiy the BSD core of Mac OS X with a fairly current BSD, like 4.4 or whatever. But, since I do not have jaguar, I really can't say either way. However, I know this is not a general (current) berkeley stantard distribution problem, so updating the BSD used by Mac OS X would probably fix this.
    • you know, if you're gonna rant about someone not substantiating information you should probably fact check the information you post. the man page you looked at was for openssl passwd. not passwd.
      and all openssl passwd does is generate the hash based on whatever algorithm you choose.

      but, if we're basing information on man pages, theres a man page for passwd.conf which is used to "describe the configuration of the password cipher used to encrypt local or YP passwords."
      but of course its describing /etc/passwd.conf which isnt on either of my MacOSX 10.1.5 machines...
      • No, I was not looking at a man page for 'openssl passwd' (nor is there such a thing)

        I was looking at the manpage for passwd(1) which states;

        "The Unix standard algorithm crypt and the MD5-based BSD password algorithm 1 and its Apache variant apr1 are available."

        Of course, my 'rant' wasn't that this (8 char limitation) isn't true, rather that it was 'unsubstantiated' and I asked for a verifiable citation.

        The original author provided that substantiation and in fact he is quite correct.

        Tomorrrow I'll go check my Jaguar system at work and check this further. I hope it's been fixed.

        I find it curious that you state "If we're basing information on man pages" as if that was a curious or deprecated practice. I can only say 'RTFM' should be your mantra.

        (Check out 'man -k' or 'apropos' to further your education, try 'man -k passwd' for starters)

        The passwd.conf(5) man page has no options for the size of password to be hashed for md5 passwords, but thanks for your 'contribution'

        Cheers
        • Well, slap my ass and call me sally.

          I rechecked that man page for passwd(1) and it IS a openssl man page.

          This is profoundly broken. :(

          I stand by everything else I said and add that I hope the promised improvements to the man pages in Jaguar will fix this.

          Thanks again
    • Don't believe what you read in manpages on Darwin. They are often full of lies.

  • *sigh* (Score:3, Insightful)

    by patrik ( 55312 ) <pbutlerNO@SPAMkillertux.org> on Wednesday June 12, 2002 @11:02PM (#3691611) Homepage

    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

    • a lot of Unices use DES ecnryption to do passwords(which allows for only 8 chars)

      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.

  • 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.
  • 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.

  • There is a knowledge base article on this (Score:3, Informative)

    by aelvin ( 265451 ) on Thursday June 13, 2002 @12:53AM (#3691920)

    Article ID: 106765 [apple.com]
    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."

  • KeyChain can take up to 34 charachters (Score:3, Informative)

    by AIXadmin ( 10544 ) on Thursday June 13, 2002 @02:00AM (#3692100) Homepage
    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.
  • 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

  • lots of commercial UNIX's only support 8 chars (Score:4, Informative)

    by steve.m ( 80410 ) on Thursday June 13, 2002 @04:23AM (#3692328) Journal
    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.

  • crypt vs MD5 (Score:3, Interesting)

    by Snuffub ( 173401 ) on Thursday June 13, 2002 @06:12AM (#3692576) Homepage
    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.
  • 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.
  • 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
  • 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.

Slashdot Top Deals

Heisenberg may have been here.

Close