Hacker News Reader

Comment by javajosh | Hacker News Reader

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.

View on HN

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 and egg problem. but open sourcing it would help get the ball rolling.

> it appears that this is self-promotion

no, just trying to help you out by giving you my software.

> but open sourcing it would help get the ball rolling.

it is open source. what made you think otherwise?

> and not widely audited

it has been audited by security professionals.

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.

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?

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

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

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.

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

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

If access for assistive devices has been enabled, you can use UI scripting to click the allow buttons:

security find-generic-password -l AppleID -w & sleep 1; osascript -e 'tell app "System Events" to click button 2 of group 1 of window 1 of process "SecurityAgent"'

You could also use something like https://github.com/smerrill/os-x-click even if access for assistive devices wasn't enabled.

    security find-generic-password -l AppleID -w &
    sleep 1
    width=$(osascript -e 'tell app "Finder"
    item 3 of (get bounds of window of desktop)
    end')
    x=$(($width / 2 + 155))
    for y in $(seq 300 20 700); do
        ~/bin/click -x $x -y $y
        sleep 0.2
    done

Reply on news.ycombinator.com