OSX password script for everyone to know

http://blog.songz.me/print-out-all-your-saved-passwords-osx/

by songzme • 14 years ago

227 90 14 years ago

blog.songz.me

Admittedly I was a bit shocked to see my passwords start pumping out: all I needed to do was click "Allow" and away it went. Why would keychain remain unlocked? Why doesn't that command need sudo? This seems like a pretty decent security flaw to me...

robmil• 14 years ago

Is this sarcasm? You clicked "Allow"; what would you expect of an application to which you granted access to your keychain, other than for that application to thereby gain access to your keychain?

mcrider• 14 years ago

You don't need a password to press 'allow'. It is still very much a security concern.

geofft2• 14 years ago

Why would it need sudo? If that were the case, then every web browser and every IM client and everything else on your computer with a password would need sudo.

You're telling your computer to save your passwords and give them back to you later. You shouldn't be surprised when it gives them back to you later.

lambda• 14 years ago

So, generally each application needs to be authorized separately. I should have to type my password to allow this application to access my passwords. If I can just click "allow" with no password, then so can anyone else trivially with Terminal access.

If I go into Keychain access, and ask to see a password, it prompts for my master password before showing it to me. This should too.

corwinstephen• 14 years ago

I'm totally going to use this for way more bad than good.

brockrockman• 14 years ago

Hardly a security flaw. How do you expect Safari/Chrome autofill the same passwords? And after the password is auto-filled any JavaScript can access the input's value attribute.

I use this in my .emacs so Emacs can grab passwords from Keychain, but the same approach would work in bash too: (defun find-keychain-password (host) () (condition-case nil (let ((passstr (second (split-string (first (process-lines "/usr/bin/security" "find-internet-password" "-gs" host)) ": ")))) (substring passstr 1 (1- (length passstr)))) (error nil)))

jdechko• 14 years ago

I'm inclined to agree. It looks like this is the same "hack" detailed last week, though through a terminal command instead of an application. As we learned last week, by default, OS X is set to never lock the keychain once it is logged in. It's a conscious choice of default set by Apple. If you care about tighter security, just change the autolock time or use separate keychains.

Bakkot• 14 years ago

No, last week's was root only, operated by searching through RAM for various keys, and was notable for displaying passwords for every logged-in user, which this will not do.

sitharus4• 14 years ago

That's a handy function! Thanks for sharing :)

stuartd2• 14 years ago

I run as a non-admin user on Mountain Lion (stops the kids messing stuff up) and it sometimes has unexpected benefits - like in this case, when I run security dump-keychain -d ~/Library/Keychains/login.keychain in terminal the output is most definitely not plain text even after I press 'Allow' - see http://pastebin.com/TH63R9sM for a sample

geofft2• 14 years ago

Oh cool, is that your client certificate's private key?

stuartd2• 14 years ago

As I said, edited..

eblume2• 14 years ago

You should probably delete that, I'm thinking that that's a private key. It's not a 'password' but it's still a secret, and you just pastebin'ed it for everyone.

But I'm just guessing -- I don't know too well what a private key would look like in this format.

ninjac0der• 14 years ago

Apple doesn't introduce security flaws. They are far to big and awesome for that. This is a clear compromise between security and user experience....

kreek• 14 years ago

Locking the keychain works until you unlock it from another app. If you enter your keychain password for Mail app or for a web password it becomes unlocked for the terminal command. Which is unexpected behavior as from within keychain, even if it is unlocked, you must reenter your password if you want to see a saved password.

jtokoph• 14 years ago

You may want to setup autolocking:

1. Launch "Keychain Access".

2. Right click on "login" keychain.

3. Click "Change Settings for Keychain 'login'".

4. Check the "Lock after:" box.

5. Change the minutes of activity to whatever you want.

You have the option of auto-locking after zero minutes of inactivity.

eblume2• 14 years ago

I was about 5 minutes in to the docs to set up a quicksilver task to do this - thanks for helping me avoid re-inventing the wheel. Yours was the better 'hack'. ;)

mkmk• 14 years ago

Just in case anybody else doesn't see the 'login' keychain: the square button with a triangle in the bottom left corner shows and hides an additional list of keychains

ammmir• 14 years ago

or using command line (lock default keychain on sleep and after 30 min):

  $ security set-keychain-settings -lut 1800

tlrobinson3• 14 years ago

I tried this, and quickly got annoyed with having to enter my password every time iCal tried to sync.

It would be better if you could set it to require a password every time a previously unauthorized app requests access to a Keychain item.

draebek• 14 years ago

I think I had this same problem with Mail.app. I "solved" it by creating a separate keychain that just locks on sleep, but doesn't timeout, and moving my Mail passwords into that keychain. Presumably the same thing would work for iCal.

leejoramo• 14 years ago

I ran this command and for at least the first 10 items, I was prompted by a GUI dialog to allow the export of the keychain item. (I have close to 2,000 items in my keychain, so it is a small sample.)

I think that this is more of a lesson to:

1) Have reason able auto locking time outs setup via the Keychain and Screen Saver

2) when Keychain Access prompts you to access info that you should normally click "Allow" and not "Always Allow".

aidos2• 14 years ago

But if you click in allow you could actually see the protected info, right? No password required.

aidos2• 14 years ago

The reason this is strange behaviour is that when you try to access private info from within keychain you have to enter your user password each time. Using this command you just need to click on the allow button.

The keychain only allows applications that you authorize to access a given password, right? So for example, when I upgrade Transmit, it needs to ask for my permission to access the passwords again. Does that give it access to everything or just a specific password / set of passwords?

sitharus4• 14 years ago

An application can only read passwords you've specifically allowed it to. When you upgrade Transmit it only gets access to that subset.

If you're curious go to Keychain Access, double click an item and look at the Access Control tab. You can even force password entry there if you want extra security on certain items.

jasomill4• 14 years ago

Perhaps, but the Transmit developers could actually even use code signing to get Keychain to recognize multiple versions (new ones, but also alternative builds such as might be distributed by the Mac App Store) as the "same" application (Google "designated requirements"). Either way, though, barring security bugs (including unnecessarily permissive designated requirements being used by other apps), this should only give Transmit access to passwords you've specifically authorized for Transmit. Of course, if Transmit were malicious and one of these passwords happened to be your local login password...

dhruvtv• 14 years ago

How is this command line method any different/better than opening Keychain Access, clicking on each entry and checking 'Show Password'?

sitharus4• 14 years ago

Show Password prompts for the keychain password. This just prompts you to allow without password entry.

tlrobinson3• 14 years ago

Is 1Password more or less secure than Keychain? If my 1Password is unlocked can any application get passwords out of it?

sitharus4• 14 years ago

That's an interesting question. 1Password isn't as integrated as the Keychain, but in both cases you have to manually approve access.

1Password is more portable though - Keychain is only useful in MacOS X.

sil3ntmac3• 14 years ago

Keychain uses AES256 so it's about as reasonably secure of a single-password solution as you can get (given you use it correctly). I would assume 1Password is equivalently secure.

dkokelley2• 14 years ago

First of all, if someone has unauthorized physical access to your device, you're pretty hosed. Especially if they happen to have a current logged in session. Forget passwords, they have cookies and mail.app and bookmarks. Second, if you must lend your computer to an untrusted person, use the Guest session. I just tried this and confirmed that there is no immediately obvious way for a person logged in to a guest session to access my keychain.

Knowing this, I will rewrite the opening line to the article.

Original line: "Here’s a reason why you shouldn’t let anyone use your computer."

My revised line: "Here's a reason why you shouldn't let [untrusted persons] use [a non-guest session on] your computer."

FlukeATX• 14 years ago

What do you mean "Forget passwords, they have cookies..."? Since when is having a cookie better than having the password that can give you the cookie anyway?

shadowflit• 14 years ago

If you have two factor authentication but leave yourself signed in, a password alone will not get an intruder into your account, but a cookie will.

dkokelley2• 14 years ago

shadowflit made a good point about two-factor authentication. I would also add that by having cookies (and hence a presumed established session with you bank, email provider, or social network) you bypass one of the steps to get what you presumably want: access. I mean to point out that there is no reason to run this script if you already have physical access to a computer with the target's account logged on. You already have the extra access you need.

sil3ntmac3• 14 years ago

Ugh, the people I work with (I work for a security firm) consider this a "hack" as well. This is expected behavior! How do you expect your passwords to autofill across browsers? It is called the login keychain for a reason. If someone has access to your user account, and your user account has associated web passwords that can be summoned without re-entering your login password, then the logical conclusion is that your web passwords are not safe.

However, Keychain Access is perfectly secure as a dead-simple manual password manager. Just create a new keychain (I call mine "webpasses"), give it a password different than your login password, and manually save your web passwords in that. Yes you have to open Keychain Access every time you want to save (or copy the plaintext of) a password. Yes it's a bitch. But if you save your passwords in the correct format (description=website URL, username=website username) then Chrome and Safari will find it, ask for your "webpasses" keychain password, and autofill, no questions asked. Bonus points because you can save your new keychain in your dropbox and use it across multiple (osx) machines. I store all my credit card numbers in one keychain file, everything is AES encrypted IIRC so it's as good a solution as any as far as "one-password-auth" goes.

[/rant]

(note: I chose this solution because I am paranoid -- er, security conscious. The average user will NOT want to enter a password anytime he/she wants to autofill, and there's really no way to do this in a secure manner)

EDIT: grammar

ghayes• 14 years ago

I guess a bigger question is why don't we use challenge/response authentication for websites? This way, a program like keychain could answer challenges without ever exposing plain-text passwords.

dustingetz• 14 years ago

Am I the only one who read your post and said "huh"? Don't mean to have a naive reply, but this is new to me.

Tichy• 14 years ago

Still, somehow keychain would have to know the passwords, and presumably they would have to be encrypted with the login password of the current user. So it would still be possible for the current user to extract their own passwords. I don't think it is possible to hide passwords on the client side.

evoxed2• 14 years ago

On that note, it actually seems like a pretty good place for Apple to sweep in and take some thunder from 1Password et al, by sprucing up the Keychain app and making it something that everyone can sort of use without thinking about it. Just throw around talk of 'sandboxing' and 'secure access', turn it on by default, profit. Then if (by default) you needed an Apple device and iCloud account to login to all your shit... I think you see where this is going.

rapind• 14 years ago

Please God no. I've been waiting about a month now to re-access an iCloud account as Apple sorts out their security issues.

sedev• 14 years ago

I don't think Apple will do that: I think that Keychain is like the Reader mode and Reading List in Safari. It has some features that are like those of a third-party service, but because Apple isn't invested in the service for its own sake, the effect is that it raises the bar for third-party services, not that it replaces third-party services.

macchina• 14 years ago

I don't think it's obvious that Keychain isn't automatically secure within a logged-in user account. Apple makes a big deal about their products being intuitive, "it just works." They really ought to implement the system that Lastpass and other password managers use and allow the user to separately "unlock" Keychain before the passwords autofill.

*Edit: Actually it looks like you can set Keychain to lock automatically after X minutes of inactivity or when the computer sleeps.

klodolph5• 14 years ago

Better yet, open "Keychain Access", go to the preferences general tab, and click "Show keychain status in menu bar". Voilà, now you can lock and unlock keychains without switching applications. (This has been around for a long time, too.)

sil3ntmac3• 14 years ago

It's certainly not obvious to a normal user, and that's fine. But if you even somewhat understand security this should not come as a surprise.

induscreep• 14 years ago

ooh look I can access my .config folder on linux.

an0nym0usc0ward• 14 years ago

delinka• 14 years ago

Or maybe, just maybe, you should never let random people use your computer under your account. Create an account for randoms, switch users before loaning them the keyboard.

javajosh3• 14 years ago

While it is shocking to see your passwords scroll by in plaintext, a careful consideration of how to fix the problem, one realizes that the offered solution really isn't good enough. Many applications require your passwords in order to run, and the Keychain is the way OSX apps get those passwords.

After a little thought, there are two solutions. First, and best, is to log out, and let your guest use a guest account. Or second, watch over the persons shoulder (which is probably a good idea anyway for the security conscious.)

But, personally my biggest concern is that it highlights how trivial it is for locally installed software to access my other passwords! It means that all of my passwords are only as protected as my least-trusted local app. And I have to say, my least trusted app is pretty untrusted. The only saving grace is that OSX asks me if I want to allow an app to access that password.

zx2c44• 14 years ago

Alternatively, it might be worthwhile to switch from using Keychain to using pass, a far better and simpler alternative: http://zx2c4.com/projects/password-store

javajosh3• 14 years ago

it appears that this is self-promotion, but that's a nice-looking tool. it does look a little disruptive to my workflow (I suggest doing a screencast demonstrating some real world scenarios like periodically checking ical or gmail). and also, unique, not widely used (and not widely audited) security software seems like taking a pretty big risk. not really sure what you can do about that, since it's kind of a chicken and egg problem. but open sourcing it would help get the ball rolling.

thronemonkey2• 14 years ago

I'm a GPG noob, is there a way to configre pass + gpg so that my passwords are encrypted with AES rather than an asymmetric algorithm?

jasomill4• 14 years ago

Perhaps, but assuming you use the pasteboard feature, this appears to have the same weaknesses as Keychain, and then some. Two come immediately to mind:

I. OS X Screen Sharing, Microsoft's Remote Desktop Connection, and many other remote access clients enable pasteboard sharing with remote hosts by default.

II. Less importantly, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard gives local root users an easy way to obtain passwords upon use, with only public, documented APIs:

1. Set dtrace probes on syscall::exec*:entry to fire whenever pass runs.

2. For each such run, save the arguments to pass (obtained in dtrace with copyinstr) and the pasteboard's contents[1], then poll the pasteboard for the next few seconds, and if it changes, save the new contents as well. Depending on the timing, I assume one or the other will be the password for the account described by the arguments to pass.

Finally, I'm not sure what the problem with Keychain here is supposed to be in the first place: after clicking "deny" about 1,000 times, the only passwords the suggested command

  security dump-keychain -d ~/Library/Keychains/login.keychain

revealed on my systems were the blank ones, and my login keychain is not "locked". So I guess this means blank AFP and SMB passwords shouldn't be relied upon to provide meaningful security?

[1] To access the pasteboard server, your "snooping agent" must run in the target user session's Mach bootstrap namespace. Running as root, this is easy:

  launchctl bsexec PID /path/to/snooping-agent [snooping-agent-args]

should do the trick, where PID is the UNIX process ID of the appropriate loginwindow process (under normal circumstances this will be the only loginwindow with the target's EUID).

Schlaefer• 14 years ago

> The only saving grace is that OSX asks me if I want to allow an app to access that password.

What do you mean with "only". It's asking you exactly for that reason.

javajosh3• 14 years ago

I'm not entirely convinced that those dialogs can't be circumvented.

droithomme2• 14 years ago

Keychain Access and the general security model is poor.

There should be a way for web passwords that are saved from a browser to be restricted for use from a set of authorized browsers only, without also allowing any random program from just grabbing the plaintext.

From what I observe using this system, once you lock the entire keychain, then you have to unlock and relock it everytime you use a web password, or if you forget to relock, after authorizing one time access from the browser popup, it unlocks the whole keychain for the entire system. Unlocking my throwaway yahoo junk mail account in Safari should not also unlock the password to my banking account across the whole system.

This is not the best design and those who say "works as designed", in my opinion, are suffering from myopic tunnel vision where they assume a current design is the only possible design.

klodolph5• 14 years ago

1) Open Keychain access.

2) Select a keychain item (a password) and double-click it.

3) Click on the Access Control tab. You can choose which applications can access that particular password.

I think there's also a group system, and there's a group called "InternetAccounts", but most of the passwords I see have an access list (which I haven't modified) that only includes one application, usually Safari or Mail, but I also see "NetAuth" and "NetAuthSysAgent" for passwords I use for file sharing.

You can also make it so keychain access requires you to type the keychain password in every time a particular password is accessed, and you can also put passwords in separate keychains that use different passwords.

droithomme2• 14 years ago

I am aware of that. Let's look at Mail passwords - Mail is the App with designated access on that pane.

Now, if the entire Keychain is unlocked, Mail can access it when I check email. If the entire Keychain is locked, it asks for permission to use it. If I give permission, the entire Keychain is unlocked and left unlocked. It's not only access to Mail that is granted when Mail asks for validation. The entire keychain is unlocked.

Some claim to just keep their Keychain locked. People who say they keep theirs locked all the time, do they really give a password every single time they check their mail during the day, and then immediately afterwards open Keychain Access and relock it? That's the workflow required to keep the Keychain locked. Perhaps it works OK if one uses another computer for email and internet use. If one uses email and site logins on their Mac, one either has to retype their password every single time, and every single time go open Keychain and relock it, or they are sitting with the whole Keychain unlocked.

The command discussed is an easy way to pull passwords off of people's Macs. All you need is to wait for a few moments while they are distracted. This is a flaw. All passwords stored on the system should not be available for a passerby to examine without validation. Validation is only required if one is willing to unlock and relock the Keychain constantly, after every email check and site login.

tomwalsham• 14 years ago

A nice visible reason why the Rails/Node/OSX FOSS community really need to stop doing the following sort of thing for their installations (seen most recently on yeoman.io, but common to get.pow.cx, npm...)::

curl get.totallytrustworthyapp.io | bash

The above examples are obviously legit, but encouraging this kind of lazy access to even local privileges from arbitrary remote scripts (and Yeoman even asks for sudo in a super-friendly way), is the modern equivalent of padlock.gif on your payment page - training poor security practices.

blake8086• 14 years ago

You're still ultimately going to be running some code without reading all of it first, aren't you?

muyuu• 14 years ago

In Firefox and Chrome you can see all web passwords in plain text. It used to be the same in Safari but apparently not anymore. And that's when they don't leave their webmail logged in, which a lot of people do and they lend you their computer like nothing happened. This is often a master key to somebody's privacy, usually more critical than the kind of stuff have in their keychain most often (WLAN passwords and the like).

People around me are not the most security conscious, or they just know they can trust me.

I guess there's also the cultural bias to allow people "check their email" and stuff like that.

My keychain is always locked, I don't save sensitive web passwords in browsers, and I still don't let people use my computer unsupervised.

kristopher• 14 years ago

Apple provides an easy way to lock your desktop when you go for coffee. To set it up:

  1. Launch "Keychain Access".
  2. Open Preferences from the "Keychain Access" menu
  3. Check the option labeled "Show keychain status in menu bar"
  4. (optional) While holding the cmd-key, click and drag the menu item over to the far right of the menu bar for easy access.

Enjoy!

OSX password script for everyone to know

Related Stories