OSX password script for everyone to know • Hacker News Board

Re: OSX password script for everyone to know

#81

Post by droithomme » Fri, Sep 14, 2012, 4:56 PM UTC

klodolph wrote: post #72

droithomme wrote: post #53

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 yo…

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…

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.

Re: OSX password script for everyone to know

#82

Post by stuartd » Fri, Sep 14, 2012, 10:25 PM UTC

geofft wrote: post #12

stuartd wrote: post #7

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

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

As I said, edited..

Re: OSX password script for everyone to know

#83

Post by thronemonkey » Sat, Sep 15, 2012, 6:44 AM UTC

javajosh wrote: post #56

zx2c4 wrote: post #55

Earlier quoted context omitted.

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

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…

As far as not widely audited goes, the encryption is handled by GPG so that part is at least fine.

Re: OSX password script for everyone to know

#84

Post by thronemonkey » Sat, Sep 15, 2012, 6:46 AM UTC

zx2c4 wrote: post #55

javajosh wrote: post #52

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.…

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

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?

Re: OSX password script for everyone to know

#85

Post by jasomill » Sat, Sep 15, 2012, 10:43 AM UTC

zx2c4 wrote: post #55

javajosh wrote: post #52

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.…

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

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).

Re: OSX password script for everyone to know

#86

Post by zx2c4 » Sat, Sep 15, 2012, 10:52 AM UTC

jasomill wrote: post #85

zx2c4 wrote: post #55

Earlier quoted context omitted.

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

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…

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

Don't use -c then. Inherent weakness of clipboard.

> II. While I wouldn't personally consider it a "real" security problem, 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:

This is ridiculous. Of course, if someone has root access they can do whatever they want.

Your technical comments are a bit overblown. If you're root, just replace the executable with a program that pilfers off the passwords. Easy as pie. But sure, you can also dtrace, or load a kernel module, or ... anything?

Not to mention, if you're root, you can just listen to keystrokes, or monitor browser logins, or sniff input fields, or take memory dumps of the whole system, or ... um... anything?

FUD.

Re: OSX password script for everyone to know

#87

Post by zx2c4 » Sat, Sep 15, 2012, 11:24 AM UTC

thronemonkey wrote: post #83

javajosh wrote: post #56

Earlier quoted context omitted.

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…

As far as not widely audited goes, the encryption is handled by GPG so that part is at least fine.

Yes.

And it's worth pointing out that the "other parts" have also been audited by security professionals.

Re: OSX password script for everyone to know

#88

Post by jasomill » Sat, Sep 15, 2012, 12:08 PM UTC

zx2c4 wrote: post #86

jasomill wrote: post #85

Earlier quoted context omitted.

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…

> I. OS X Screen Sharing, Microsoft's Remote Desktop Connection, and many other remote access clients enable pasteboard sharing with remote hosts by default. Don't use -c then. Inherent weakness of clipboard. > II. While I wouldn't personally consider it a "real" security problem, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard…

No FUD intended. Given the option, when the alternative is manual entry, many people will use the pasteboard, security be damned. In other words, convenience can be an important part of security.

As for root, while I completely agree, I guess I just prefer concrete examples. Even when running as root, one can never do "anything" for free, and costs are always important to security. Writing a dtrace script is much easier than reverse engineering...well, pretty much anything.

But I'm honestly more interested in how you feel your solution improves upon Keychain's security.

Re: OSX password script for everyone to know

#89

Post by jasomill » Sat, Sep 15, 2012, 1:02 PM UTC

droithomme wrote: post #81

klodolph wrote: post #72

Earlier quoted context omitted.

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…

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…

The fact that a Keychain is unlocked still only gives designated programs access to passwords and /usr/bin/security is no exception. The command from the article results in about a thousand "always allow/allow/deny" dialog boxes on my system, and there's an option for each password in Keychain to require a password to "allow" (from Get Info > Access Control, then set Confirm before allowing access and Ask for Keychain password, and clear the "Always allow access" list; admittedly, this would be a huge PITA for lots of passwords). Alternatively, if you want to "lock" every password but Mail's in one stroke, you don't need another computer: just create another Keychain with nothing but your Mail passwords, select it as the login keychain, and set the original keychain to "Lock after 0 minutes of inactivity."

Re: OSX password script for everyone to know

#90

Post by klodolph » Sat, Sep 15, 2012, 2:27 PM UTC

droithomme wrote: post #81

klodolph wrote: post #72

Earlier quoted context omitted.

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…

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…

It sounds like you really haven't explored how to use Keychain access -- including some of its most basic features like ACL configuration and multiple keychains.

1) Relocking the keychain can be done through the menu bar, if you enable the keychain menu item. You don't have to open Keychain access. When I let someone else sit down at my account for a moment, I lock the keychain. This is not a very difficult "workflow". This same menu gives you a "lock screen" item.

2) If you want to unlock and lock things with finer granularity, you can put those things in different keychains. For example, put your mail password in its own keychain. When you unlock that keychain, nothing else gets unlocked.

3) If you want to make it so new applications require typing in your password before accessing a password (rather than just confirming with a yes/no dialog box) you can check the box in the password ACLs. It's a bit of a bummer that there's no global setting for this.

I think we have to weigh this against all the other bad things that someone could do when given access to your account. If the keychain containing your email password is unlocked it's basically game over, since there's so much damage they could do with your email account, and it doesn't even require getting the password.