Mac OS 10.1.x uses crypt passwords and these passwords are subject to being read by simple dump scripts
Mac OS 10.2.x uses crypt passwords and these passwords are subject to being read by simple dump scripts
Mac OS 10.3 creates new accounts with shadow password, these passwords are not subject to simple script download - only root processes can read the hashes.
Legacy/existing user accounts created before 10.3 retain the crypt password.
With 10.3 Simply resetting the password in System Preferences/Accounts migrates the password to the new shadowhash style (or for the CLI crowd you can use passwd).
the maximum length of shadowhash passwords in Mac OS 10.3 is virtually unlimited (it's a hashed digest of the password string). However for pratical purposes the GUI and most command line tools have limits between 128-200 characters.
10.3 with updated accounts or newly created accounts is no longer exposed to simple password dumping attacks, and supports more than 8 characters.
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
Slashdot Mirror
Mac OS 10.1.x uses crypt passwords and these passwords are subject to being read by simple dump scripts
Mac OS 10.2.x uses crypt passwords and these passwords are subject to being read by simple dump scripts
Mac OS 10.3 creates new accounts with shadow password, these passwords are not subject to simple script download - only root processes can read the hashes.
Legacy/existing user accounts created before 10.3 retain the crypt password.
With 10.3 Simply resetting the password in System Preferences/Accounts migrates the password to the new shadowhash style (or for the CLI crowd you can use passwd).
the maximum length of shadowhash passwords in Mac OS 10.3 is virtually unlimited (it's a hashed digest of the password string). However for pratical purposes the GUI and most command line tools have limits between 128-200 characters.
10.3 with updated accounts or newly created accounts is no longer exposed to simple password dumping attacks, and supports more than 8 characters.
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