Hi,

I was hoping someone could help me with this. The password to my wireless network is saved in my keychain and I can use it to access the internet. Unfortunately, I have forgotten my password and now I'm trying to set my girlfriend up on our network with her new mac, and I need to my mac to tell me what the password is. (Reseting the router's password would be endlessly complicated.)

When I go to Keychain I can enter my password and it will tell me any of those passwords, but when I enter my password for any of the system keychains it tells me my password is invalid. Is there anyway around this, or any reason my password (the only password I've ever used) will not work? I am using OS 10.3.9. Any help on this would be appreciated.

Thanks,
Jim

See if you can find anything helpful in this MacFixIt tutorial.

I have never been able to access stored wireless passwords. They are in the System keychain. I am allowed with my administrator login/password to unlock that keychain, but if I select to view the password, it only asks me for my password. (it does NOT ask for a username, this is very unusual!) I assume it is NOT asking me for MY password, but is asking for something else. I have tried root's password as well as the master password and none of them will alllow me to view that keychain. I suspect that I am not the one that is unlocking the System keychain because it never asks me for a password when I unlock it. I assume the system itself is somehow unlocking it or handling it for me. (because I am logged in as an admin maybe?)

I can only assume that the system is asking for one of those internal passwords that is generated by the system during installation and is only used internally. Then when you need it for a wireless connection, the OS provides itself with this special passkey to access the keychain for read purposes. Now this means we are dealing with 'security through obscurity', and that there is certainly some way to either determine this password or to get around it. (otherwise how would we connect to our wepped APs?)

I have looked around and been unable to find any information on how to access stored wireless passwords.

I do find it irritating that the system is capable of hiding something from me as root, but so far I have not found a way around it. Thinking more on this, that it is not asking me for my login name but only password, it may be that it assumes a username, such as root or my directory admin, so I will try logging in as root and as the directory admin and see if their password is then accepted. Though I suspect this will not work, I'll let you know if it does.

Not sure why the system keychain unlocked earlier for me, maybe because I had used sudo recently. Anyway, logging in as directory admin or as root, and using their password, I am still unable to view passwords in the system keychain. I can unlock it, just not view the passwords. Again, it does NOT ask for a login name to unlock the keychain.

Looking at how the keychains work, there IS no login for them, only a password. So the system must have the key to the system keychain stored somewhere crafty. Anyone have any leads on this? (going to have to go look in /etc and soforth for files marked root:root 400...

What mystifies me is why System.keychain offers users the option to examine the passwords it protects when the requisite password is apparently unknown and undiscoverable; same as the passwords stored in login.keychain those in System.keychain sometimes (Hah!) get forgotten and need to be reclaimed.

Its like somebody at Apple has a really rotten sense of humor.

Any chance that the answer is as simple as changing permissions? (Don't have the beast in my zoo...can't experiment on it myself.)

The way the keychains are designed, it's always possible to see what's IN the keychain by name, but you require the key to actually access the protected portion of the information. So it will tell you that yes, we have the password to your email account at gmail, but no you cannot get the password without typing in your passphrase.

The padalock beside a key means if it is unlocked then the system has access to the private contents of the key, it does not mean you can simply "open" the chain and see what keys are available, nor does it mean you can retrieve values from it. You also cannot change a keychain unless it is unlocked.

For most keychains, you have to type your pasphrase to unlock a keychain, and at that point any app that you own that needs the key can have it. If you want to view a key though, it requests you type in your passphrase. Each key is provided to apps on a one by one basis though. Having your keychain unlocked only allows automatic retrieval if you have said "always allow" when the app has asked you for your passphrase. That is the purpose of the padalock.

Now speculating. The system keychain appears to be a little bit special. It too requires a passphrase to unlock, but it's not your admin or master password. It is most likely a randomly generated password created when OS X is installed. It also has a list of "always allow" applications. Wireless passwords for example, are always added to the system keychain with "always allow" checked for the wireless software. The system will let any administrator unlock the system keychain, and I presume it is "entering" the password for you without asking because it knows you do not know the password. This is ONLY because the system wants admins to be able to modify this keychain, by adding WEP passwords and soforth to it, and you must unlock it to change it. The "always allow" appears to be transparent even when the keychain is locked, so if say you want wireless access to an AP, the wireless requests the password from system keychain. Being always allowed, it automatically unlocks and retrieves the password. The system automatically provides the password to unlock it.

This would mean that the security of the system keychain is not solid. Someone with sufficient patience and time could figure out where the system keychain's passphrase is stored and how, and find a way to either decode it or to use it to decode the entire system keychain with passwords. I have googled around for this information, and it appears that no one has managed to figure out how Apple has hidden this password. They probably hide it very very well. This is "security through obscurity" for the system keychain. No other keychains can be unlocked automatically by the system so the rest of the keychain items on the computer are more secure.

The only items I see in my system keychain are
- WEP passwords
- a 1024 bit private/public key pair (not sure what this is for? signing maybe?)
- dial-up internet account passwords

These are all things that anyone on the computer might need to use, though does not need to know what they are. That is where the "security through obscurity" comes into play. It's not rock solid, but it appears to be fairly well defended.

It's too bad the system does not make everyone a private/public key pair. I checked and my keychain does not contain one.

Oh there it is, Certificate Assistant in keychain access lets you create a pair for yourself. Good, I needed to sign something today actually, bout time I learned how.

OK this is HIGHLY frustrating. Don't you hate it when they give you juuuust enough information to aaaaalmost do what you want to, and tell you how wonderful and easy it is to do, and then they tell you something like "all you need to do is abc and then you can do everything you want." And then nowhere in the world can you find out how to do abc like it's just something everyone in the world knows how to do.

I am trying to digitally sign an email. Just click the button it says. That button is NOT in my new email window as the help file promises. (how helpful!) So I dig more and find a vague indication that I willl be picking a digital certificate that is "assigned" to the particular email account. So I assume the button is not there because I don't have any certs that will work. (would be nice if it would TELL me why it's refusing to work) OK so in keychain access I make a certificate. (and a key pair also) Nowhere there is a way to select which email account it is assigned to. I used the same email address though as I was creating the key. Doesn't seem to matter. There seems to be no way to associate a certificate with an email account, in keychain access or in Mail. Normally the way the gui works I would expect to be able to drag the certificate into a list of available certs, but although I can drag them, there is nowhere in mail to drop them.

Apple's help files receive a D- today.

Has anyone successfully guessed the correct way to make this work?

This thread having now been hijacked to Cupertino, let's get back to its roots...

I'll buy into your "security through obscurity" line of thought, but there's a logical element missing...OS X asks for a password, (may I say) obviously expecting that someone somewhere knows it, but that seems to not be the case, i.e. nobody even knows where to look for it let alone what it might be. ALL passwords sometimes (Hah!) get forgotten and need to be recovered, and it's incomprehensible (to me, at least) that the password request in question is merely smoke.

Either we're all missing something or somebody at Apple has a rotten sense of humor.

I believe the reason it asks for the passphrase is because it is treating the system keychain like any other keychain for that purpose. It knows there exists a valid passphrase and that it should not allow us to view the keychain values without supplying the password, so it asks for it. The user is guaranteed to not know what it is, so the security of say, the wep keys, is maintained. If the system itself wants the key, it is in the "always allow" list for that key entry, so the system surrenders it to itself without requiring the passphrase.

So there are only three ways to get the wep key from the system keychain that I can see:

1) determine the location of the system keychain's passphrase. good luck, I am betting it's very well obscured and absolutely undocumented.

2) subvert the system kexts that perform the wep key interaction so that they pass you a copy of the passphrase when they access it. This may be tricky because we have all seen things after a software update like "Mail.app has changed, allow it to access login.keychain?" so the system is clearly watching for this activity and may defend against it.

3) find a way to add to or modify the "always allow" list or access the keychain directly as an always-allow agent, so that you can ask the keychain system for the key value (probably not through keychain access, more likely as a normal keychain system call) and get the value that way.

But make no mistake, this is "security through obscurity". Never forget that the system can use that wep key anytime it wants to and it never asks YOU for a key, so one way or another it IS possible to access that wep key without keys that are not already available to you (one way or another) on your hard drive.

In a way I am kind of surprised that someone has not already figured out where the system keychain password is stored. If I knew more about the OS I might go hunting for it, but I suspect it would require a lot more system knowledge than I posess to actually find. Surely someone out there has or can take on the challenge?


Somewhat off topic, OS X is a lot less secure than Apple would have you believe. There are other "security through obscurity" issues with OS X that few know about. As an example, "try this one at home, kids:" Given an average macintosh that has only one account on it, an administrator, with an unknown password and is set to auto-login, please login to the computer, download and install applications, run software updates, and make changes to locked system preferences. You are not given access to any storage media - no access to firewire ports, usb ports, or the optical drive. You most certainly cannot run the password reset. Use of hacking programs is also not permitted, all you get access to is the keyboard and mouse. In fact, you are not permitted as part of the test to reset the admin's password at any point even if you could. (and you can)

I have to do this on a regular basis at work because customers are always checking in machines and claiming there is no password. (they enter it and forget they did) Resetting their password is disruptive and should be avoided if at all possible because not only does it change their password, but it kills their keychain. Stuff like this is possible, it's just that few people know about it.

> [...] customers are always checking in machines and claiming there is no password.

Didn't you once post that their password is always "bunnyrabbit?"

Seriously, though, thanks for your fascinating, in-depth analysis of this peculiar keychain issue; next time the question comes up I can answer it with an authoritative "V1 says there's no f'ing way."

One last question, though: What is so all-fired important about the wep keys and other passwords stored in System.keychain that Apple has made it virtually impossible to recover them in a pinch (say, for instance, like our poster is in)? Are they actually that critical that it is preferable to lose them than to put them at even minimal risk?

I believe the reason they do it is similar to the reason passwords are hashed... because they don't want them to be recoverable, ever, even by an admin.

With your login password, when you create it, the system "hashes" it, mangles it in a fxed way such that it turns into garbage, but in a very special way such that no two passwords will produce the same garbage. Hash functions are also very "one way", such that if I give you the garbage you cannot determine what the original password was.

So what they do is store the hash instead of the password. Then when you login, it hashes whatever you typed in, and then compares the two resulting garbages. If they are identical, you can be reasonably assured the original password used to create them was the same, and the password is verified. Without knowning the password, and without being able to determine what the original password was. Since the password is always hashed before being compared, you cannot simply supply the hash at the login prompt, so even knowing exactly how the system verifies the password does not allow you to login.

WEP passwords cannot work this way because whoever made the wep standard didn't think of hashes. So to access a WAP that has WEP on it you have to send the password. It's not in cleartext, it's encrypted along with everything else to the WAP, but THAT is in cleartext. So to login to the WAP you have to know the cleartext of the password. So you cannot just store a hash of the wep key, you have to store the actual key.

Since this would allow anyone with physical access to your computer or HD to recover the passkey, they protect it heavily to make it as difficult as possible to recover. But this protection is not bulletproof, and it can be recovered if you know what you are doing. Though to my knowledge, no one outside of Apple has figured this trick out yet. But as with all 'security through obscurity', it's only a matter of time.

I'm kind of surprised that in all the time that WEP has been around, that the standard has not been updated to include key hashing.