If you execute "security dump-keychain -d login.keychain":
1. If the keychain is unlocked (the keychain is unlocked by default after logging in, and you can check that by opening the Keychain Access app) a SecurityAgent window opens, and you must click the Allow button to dump the keychain. That cannot be scripted in an installation of a recent version of OS X which is not misconfigured.
2. If the keychain is locked (for example, by clicking the padlock in the Keychain Access app to lock it), it asks you for your user password, just like the Keychain Access app does.
Also, this ability to parse all the passwords unencrypted isn't a flaw and it isn't new. I ran this very command maybe 5 or 6 years also. Granted I was shocked to see all my passwords dump unhashed but you have to enter the users password and it makes sense that is the computer needs the passwords unhashed, there should be a secure command to gain access to them.
Hashing keychain passwords would make no sense. You hash passwords when you want to check against them. When you actually need to retrieve them at some point, however, you encrypt them.
We tested this on four machines and had no prompts for password authentication. Two of them are VERY close to clean installs with only Adobe CC and two or three other production software components installed, highest security settings for everything in preferences.
We haven't been able to figure out why some users are prompted and others are not.
That only allows exporting the passwords of the currently logged-in user.
If you let someone untrusted (!) log in remotely to your computer with your user account or you give it to someone while your user is logged in it's your own fault if your keys get stolen. You should use a guest account with restricted privileges or a separate machine.
It's not much different on Linux, if you use Gnome-Keyring (used by default in Ubuntu and others) you can also get the passwords easily, in plain text [1].
Not sure about Windows, but you can most likely get to the passwords without installing anything as well if you're already logged in as the current user. If you're allowed to run executables, there are quite a few already [2].
The only way this should be possible on the Mac is if a logged in user physically at the computer selects "Allow" or "Always allow" for each security dialog that appears. Remote sessions are not permitted to do this.
Security dialogs cannot be scripted under normal circumstances (the AppleScript given in the article simply doesn't work). I suspect it might be possible to do highly dangerous things like blessing the "System Events" tool as an Accessibility tool in the Security System Prefs Pane (which would allow it to send events to security dialogs) but I'm not totally sure that's possible and in any case, I don't think that's happening here. I think the author is simply mistaken or has clicked "Always allow" in the past and doesn't realize that this setting is still active.
I was actually the author of this article, and am about to update it to address some of the criticisms. We have two machines locked down to only certain functions, down to only certain IP addresses even being allowed to communicate with the machines, and still managed to execute this - it did prompt Allow/Deny windows, but I find that intellectually different than a lack of password prompt.
I have dug through security preferences extensively and can't see what setting could be changed or updated to disallow this function.
I've updated the article to address and respond to some of the criticisms and feedback.
As others have alluded to, this is the "Login" keychain--a keychain of usernames and passwords that are unlocked upon a user's login. This is by design, not a security flaw.
When I tested, I saw banking creds in the ask list. If I want those creds from keychain I have to type my master password. But for some reason if I want all the passwords using this method I just have to click 'Always Allow'. Jacked up.
So there's gonna be arguments both ways whether or not this console command should ask for a password or not since the user is already logged in.
The main concern I have is the inconsistency that this command does not request a password while the keychain access app, as far as I know, does request one.
Apple has been aware about their security behavior here at any rate.
Just tried this on my mac. And yes, It did output something. But the passwords aren't in plain text. It outputs, what looks like at first glance, encrypted passwords.
Maybe there is an easy way to decrypt them using some other information in the output, but I haven't looked further.
Did you run the AppleScript? I got the expected error:
> error "System Events got an error: Can’t get group 1 of window 1 of process \"SecurityAgent\". Invalid index." number -1719 from group 1 of window 1 of process "SecurityAgent"
You're not supposed to be able to script SecurityAgent – and it doesn't work on my computer. Specifically, security windows should appear empty when read by other processes.
>dump-keychain [-adhir]
Dump the contents of one or more keychains.
-a Dump access control list of items
-d Dump (decrypted) data of items
-i Interactive access control list editing mode
-r Dump raw (encrypted) data of items
I'm not at my Mac so can't test what it means by "dump decrypted", but I don't think it dumps all data in plain-text as the article suggested. I am curious if the keychain was unlocked when they did it for whatever reason.
I still question why such an ability exists through terminal without more control, but it's not quite as described.
edit: was very unclear I was posting a snippet of the actual command. fixed
I can confirm that at least on mine the passwords are definitely plain text (also includes some private keys) but the Apple script doesn't work for me so there doesn't seem to be a way to suppress the Allow/Deny box.
I am a little surprised it doesn't ask foe the keychain password.
On 10.8, the command certainly does output unencrypted passwords. There is a lot of cruft in the XML-like file that I haven't figured out (I deleted the text file as fast as I could...) but the passwords were clearly visible.
Wonder if it got bumped on accident on a recent update. My system has been modified to allow system access, so its less surprising (although still a flaw). But we did it on machines by people that are probably TOTALLY unaware of those 10.11 changes and wouldn't have the know how to modify something like that, and it still worked on their machines.
They might have turned it down or off because it was buggy.
Trying to get a password out of my keychain using Screen Sharing completely hosed it (10.11 initial release). Even opening Keychain Access resulted in an instant freeze and spinning wheel. I ended up having to completely recreate my keychain and reset a lot of passwords.
I can confirm this works on 10.11.5 ( El Capitan ). To confirm, you can "cat keychain.txt | grep -i SECTION_OF_YOUR_PASSWORD". However, you must click Allow on each dialog, or Always Allow.
What I don't understand is if I want to access a particular password from keychain I have to enter my master password. But if I let someone use my machine for a few moments all they have to do is hit "Always Allow" and they can have all my passwords? That is jacked up, Apple.
I tried with locked keychain and it requires to enter your password (still something but not everything). This is something that Apple needs to address soon I think.
It's a huge difference to use system specific passwords on that specific system or to trust a properitary buggy system with passwords to other, potentially critical, services and infrastructure.
Whenever you click any "Save my password" option offered by any application on any OS, that password will need to be stored in some reversible encryption somehwere - there is just no way around it.
And unless you want to type in a password every time you need to access any of these stored passwords (which would nearly defeat the purpose), then the application or OS needs to keep that password and/or key in memory somewhere.
At that point, I would trust an application that runs with privileges that not even root can get (thanks to 10.11's rootless mode) much more than any other application, even given the eventual security flaw.
This severely reduces the attack surface to only the keychain application itself and to the component that enforces the privileges, whereas in other cases any root-exploit will cause you to lose your passwords.
In the year of 10.11's existence, no security flaw has been found in either system integrity protection (= rootless mode) nor in keychain (the bug listed here isn't a bug. if you ask keychain to give you the password, it will have to give you the password or there would be zero point in even storing it in the first place)
i dont even know which version i run, so no idea if i have to be scared or not. updates are way to painful to do regulary on a working dev machine. (lazy linux user here)
anyway i never saved a password, thats exactly my point. There is not a single reason to believe that the apple keychain can be fully trusted, its that simple.
Yeah, there's no great answer here other than its an area that requires innovation. Apple is usually pretty good in this area, and I'd love to see them bring something to the table. My hope in writing the article was to spur enough debate and attention around the subject that it might foster that innovation conversation.
I think by digging through the comments on the multiple portals this was posted since I went to bed last night that at the least, people have strong opinions on both sides. It's either security or convenience, but it's certainly presented on the surface that its both. The point of the article was it is not.
> There is not a single reason to believe that the apple keychain can be fully trusted, its that simple.
How do you believe that differs from any other cloud manager, local or cloud-hosted? What reason(s) do you have to believe they can be fully trusted? Or do you not use password managers at all? I assume you don't re-use passwords from site to site (because there's also no single reason to believe any particular site you log into can be fully trusted with a password you've used accross sites), I assume you use secure passwords (because you clearly prioritize security)... how do you remember them all?
I dont use any of these but use the gnome keyring at home. Its OS, based on industrie standards and afaik never had serious issues. (It sure helps that linux has more restrictive user rights)
On other places i use a password sheme, and if possible 2fa. A sheme is not perfect ether, but would require to attacker to fetch multiple of my passwords until he can recreate it.
Is there reason to believe that's significantly more secure than just re-using the same (strong) password everywhere?
Personally, I'd feel safer with a unique strong password for every site, even though it effectively requires a password manager (and trusting that password manager). So far, i think most attacks don't usually involve your local computer, people aren't attacking your laptop trying to crack your password manager (I think? Any known attacks of such? I guess I'd assume the NSA probably _is_, but anyway, regardless, I'd rather have unique strong passwords).
yeah :) not my native language. thanks for the correction.
I am on my phone and lazy so excuse missing sources. But afaik a lot of malware targets password managers. Dont forget that some of these also are really really bad and easy targets. some bigger ones may be good, but still tend to fail from time to time.
a unique password for every site is defintly better, but not if these passwords are saved anywhere.
My sheme, which only exists in my head, imo provides therefore more safety.
honestly i am just paranoid, but the way some users use password managers scares me.
i use a password sheme, and if possible 2fa. A sheme is not perfect ether, but would require to attacker to fetch multiple of my passwords until he can recreate it.
If you execute "security dump-keychain -d login.keychain":
1. If the keychain is unlocked (the keychain is unlocked by default after logging in, and you can check that by opening the Keychain Access app) a SecurityAgent window opens, and you must click the Allow button to dump the keychain. That cannot be scripted in an installation of a recent version of OS X which is not misconfigured.
2. If the keychain is locked (for example, by clicking the padlock in the Keychain Access app to lock it), it asks you for your user password, just like the Keychain Access app does.