Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Fix password security in 10.3.x for upgraded accounts System
I was not aware of this, but pre-10.3 versions of OS X silently ignored any characters beyond character eight in login passwords. That is, the passwords '12345678hello' and '12345678goodbye' were equivalent. The unwitting user could have ended up with a much less secure password than they thought they had.

OS X 10.3 fixed this, however, anyone who did an upgrade install (and possibly an archive and install) from an earlier version of OS X will find that pre-existing accounts retain the weakness -- passwords characters past the eighth position are ignored. It is possible to check the status of the password using NetInfo Manager (in Applications -> Utilities). Launch the application, click on Users, then click on your username. Users with old-style, weak passwords will have the property (in the lower portion of the window) authentication_authority set to ;Basic;. Strong full-length passwords will have the value ;ShadowHash; for this property.

To fix this, it is necessary to change each account's login password in the Accounts System Preferences pane. The new password can be the same as the old password, but the practical upshot is that now all the characters will count. I'm indebted to Michael Conniff and Rafe H. on the Apple discussion boards for helping me sort this out.

[robg adds: The eight-character-limit was discussed in this really old hint, and we've also covered techniques for creating strong passwords, as well as a way to test your passwords' strength using a built-in Apple utility.]
  • Currently 2.50 / 5
  You rated: 4 / 5 (2 votes cast)

Fix password security in 10.3.x for upgraded accounts | 11 comments | Create New Account
Click here to return to the 'Fix password security in 10.3.x for upgraded accounts' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Fix password security in 10.3.x for upgraded accounts
Authored by: Numbski on Dec 07, '04 10:21:18AM

Speaking of password security...

I've been lucky thus far. I haven't had to migrate a 10.3 account to another box, be it to another Mac, FreeBSD, whatever.

Under 10.2 and previous, this was pretty simple:

nidump passwd . > passwd

That would create a file named passwd (probably better named master.passwd or 'shadow'), complete with encryped passwd hashes.

I could then easily migrate this to a FreeBSD box by using the command vipw, and paste in the hash. Manually manipulate the location of the home directory, copy files and fix permissions. Done.

Likewise, you could use the niload command to load in these users on another mac.

Doing this on 10.3 yields you the 'safe' passwd file, with an asterisk in the password field. This does me no good for migration. When I change versions of OSX, I always do a clean load, since my drive is partitioned and my home directories are safe. I don't know how I'm going to manage to do this moving to 10.4.

Anyone know how to get the full passwd file?

[ Reply to This | # ]
Fix password security in 10.3.x for upgraded accounts
Authored by: mikerose on Dec 07, '04 11:17:47AM

This is deliberate... since you used to be able to get the password hashes, someone could try to crack them. 10.3 and after (as long as you change your password at least once), they are stored as shadow passwords and cannot be exported.

Best way to handle the migration would be to change all your passwords pre-move, then change them back to secure passwords after you upgrade.

[ Reply to This | # ]
Fix password security in 10.3.x for upgraded accounts
Authored by: webbix on Dec 07, '04 11:37:54AM

I do not have the answer but I am certain there is some option to do this as Apple includes this in the startup on new machines. I do not know if the tool to migrate is available outside what is packaged on new systems.

I suppose you could dig into a system and find the migration tool. Must be on drive of new machines or maybe someone has more info. I am probably not geared up to find it but if I do I will certainly pass along.

[ Reply to This | # ]
don't bother; it's easy to crack your password no matter how long it is
Authored by: zojas on Dec 07, '04 02:10:05PM

it doesn't matter how long your password is, it's trivial for an attacker to recover it, using at least two different methods. make no mistake, OS X's password security is a total joke right now.

method 1: run the program 'strings' on your swap file, search for your full user name, you'll find the complete text of your password in plain text for all the world to see.

method 2: your login password is also stored as a windows/samba hash, which can be cracked by programs such as john the ripper in a few hours.

details for both attacks can be found on the web pretty easily, I'm to lazy to put in links right now.

[ Reply to This | # ]
don't bother; it's easy to crack your password no matter how long it is
Authored by: iRideSnow on Dec 07, '04 04:18:13PM

I don't know about method 2, but I tried method 1 on /private/var/vm/swapfile0, searching for my full login name, my short login name and even my password itself. Only the short name was found. This is with 10.3.6.

So, if this is a hole, it's either been fixed, or it's not consistent, or only comes into play if you don't have a lot of memory (I have 1G). Besides, you need admin privs to view/manipulate the swapfile anyway. So I don't really see how it's much of a hole seeing as how you have to either know the root/admin password anyway or go through some other contortions in order to somehow gain access to the swap file without knowing the admin password. And if you can do that, you probably already have pretty good access to the system and don't really need the admin password. No computer is 100% secure, especially when you have physical access to it. I mean, why not just remove the disk drive and dump the contents to a giant file! You're sure to find lots of cool stuff then!


[ Reply to This | # ]
don't bother; it's easy to crack your password no matter how long it is
Authored by: zojas on Dec 07, '04 04:58:34PM

your login password can be written to the swapfile after you run sudo or are asked to authenticate by the gui. I have 640mb of ram on my system, and have seen my passphrase in the swap file.

if your login password can be recovered, it can be used to unlock your keychain, which depending on how you use it, can then be used to unlock your filevault volumes.

[ Reply to This | # ]
don't bother; it's easy to crack your password no matter how long it is
Authored by: Anonymous on Dec 09, '04 10:51:14PM

It's good practice to have the keychain password different from the login password, for this reason.

Even if you have my login password, you would not be (easily) able to inspect my mail, ssh info or gpg keys (which are symlinked to an encrypted disk image) unless you provide the passphrase for my keychain.

[ Reply to This | # ]

don't bother; it's easy to crack your password no matter how long it is
Authored by: derrickbass on Dec 07, '04 08:21:17PM

It is an exaggeration to say that Mac OS X password security is a complete joke and even if it were, it is highly irresponsible to recommend that people not bother with password security.

It is true that Mac OS X unfortunately stores the Samba hash of your password, even if you don't actually use Samba or allow login from windows. Microsoft was stupid (what else is new) and made it so that you can break the hash in 7-character stages, rather than having to do it all at once, changing an exponential problem into a linear one.

HOWEVER, in order to access the hash, you need root access to the machine (or equivalently, physical access). (And, as has already been pointed out, the same goes for the trick of grabbing the password from the VM swap file.) This significantly narrows the scope of the vulnerability.

Now these are certainly problems, and Apple should fix them. (Why? A hacker with root or physical access can access all of your files, which is bad, but with your password they can do worse. Without the password, they cannot decrypt your keychain (which may contain passwords to financial sites or e-commerce sites that store your credit card number). Also, since many people use the same password for various accounts, once they have one password, they likely have them all. Finally, if you don't detect the break-in, then they can continue to access your system, even if the original security flaw that allowed access is repaired.)

A good password is still important. First, it helps keep people who don't have physical access from breaking in. Second, even if someone tries to break your samba hash, it will take them longer if you have a stronger password (but a longer password won't help much).

[ Reply to This | # ]
don't bother; it's easy to crack your password no matter how long it is
Authored by: sjk on Dec 07, '04 09:21:23PM

Nice followup, Derrick.

[ Reply to This | # ]
Fix password security in 10.3.x for upgraded accounts
Authored by: vykor on Dec 08, '04 09:23:02AM

I don't see this method as a major problem.

If viewing a file requires root access, and if the malicious user has that root access, then he can do a lot better than combing through the VM swapfile. If you leave a shell open with a valid sudo time stamp, that's a user-level issue and not a system level one.

I agree with you in principle. Leaving passwords in plaintext in the swapfile is pretty stupid, but not as big a deal as one might think.

[ Reply to This | # ]
Doesn't help OF password, correct?
Authored by: outer on Dec 09, '04 06:47:07PM

The OF password, however, is still limited to eight (not including 'U'), right?

[ Reply to This | # ]