]> git.wincent.com - passage.git/commitdiff
doc: More doc tweaks
authorGreg Hurrell <greg@hurrell.net>
Thu, 8 Dec 2016 08:23:49 +0000 (00:23 -0800)
committerGreg Hurrell <greg@hurrell.net>
Thu, 8 Dec 2016 08:23:49 +0000 (00:23 -0800)
README.md

index e4b12bdcac1626fa34a87fbea18912463c54e3a9..765d4e9bf2c52ea05f46b2f6fca66ccfd14e1d47 100644 (file)
--- a/README.md
+++ b/README.md
@@ -89,12 +89,12 @@ There are no options. This was quickly hacked together to address a specific nee
 The `~/.passage.sock` socket is created with user-only (`0700`) permissions, but can still be accessed by privileged users and processes running on the system. As such, it falls somewhere in the middle of the spectrum of password storage (ordered approximately from most to least secure):
 
 * **Storage in the system keychain, requiring explicit "Allow" intervention for each access:** This is the most secure, but also the most onerous. Key material only leaves the key chain with active approval (interaction with an intrusive GUI dialog).
 The `~/.passage.sock` socket is created with user-only (`0700`) permissions, but can still be accessed by privileged users and processes running on the system. As such, it falls somewhere in the middle of the spectrum of password storage (ordered approximately from most to least secure):
 
 * **Storage in the system keychain, requiring explicit "Allow" intervention for each access:** This is the most secure, but also the most onerous. Key material only leaves the key chain with active approval (interaction with an intrusive GUI dialog).
-* **Temporary storage in a process like `ssh-agent`:** This is quite secure not only because of the limited storage duration, but because the key material *never* leaves the agent; rather, other processes delegate work to be done by the agent. For example, when `ssh` tries to connect to a server, it will ask `ssh-agent` to perform the operations for private-key authentication, but there is no straightforward way to extract the actual private key material for the agent. However, this is not viable for situations like those in which you *do* need access to the private key.
+* **Temporary storage in a process like `ssh-agent`:** This is quite secure not only because of the limited storage duration, but because the key material *never* leaves the agent; rather, other processes delegate work to be done by the agent. For example, when `ssh` tries to connect to a server, it will ask `ssh-agent` to perform the operations for private-key authentication, but there is no straightforward way to extract the actual private key material for the agent. The most a local attacker can do is perform operations as you, and only while they have access to the agent. Note, however, this approach is not viable for situations like those in which you *do* need access to the private key.
 * **Temporary storage in the memory of the `passage` process:** Passphrases can only be inserted into `passage` via explicit approval, and only remain there for the duration of the session. You can shorten the duration in various ways, such as:
   1. Terminating the app or logging out.
   2. Setting up a cron job to periodically send a `SIGUSR1` to `passage` to cause it to drop its cache; you can do this with `crontab -e` and a method like the `launchctl kill` one documented above.
   3. Arranging to send `SIGUSR1` whenever the screensaver kicks in or the screen locks (something you should be able to do with a tool like [Hammerspoon](http://www.hammerspoon.org/)).
 * **Temporary storage in the memory of the `passage` process:** Passphrases can only be inserted into `passage` via explicit approval, and only remain there for the duration of the session. You can shorten the duration in various ways, such as:
   1. Terminating the app or logging out.
   2. Setting up a cron job to periodically send a `SIGUSR1` to `passage` to cause it to drop its cache; you can do this with `crontab -e` and a method like the `launchctl kill` one documented above.
   3. Arranging to send `SIGUSR1` whenever the screensaver kicks in or the screen locks (something you should be able to do with a tool like [Hammerspoon](http://www.hammerspoon.org/)).
-* **Storage in the system keychain, having previously granted "Always Allow" access:** This is problematic if you're using the `security` command-line tool provided by Apple, because once you've granted "Always Allow", you will never be asked for permission again. Even if you intended to grant access only to `my-special-script.sh`, the permission will actually be associated with the `security` tool, which any process can call. So here the security is contingent on a hostile attack not being able to run code as you (or trick/coerce you into running it).
+* **Storage in the system keychain, having previously granted "Always Allow" access:** This is problematic if you're using the `security` command-line tool provided by Apple, because once you've granted "Always Allow", you will never be asked for permission again. Even if you intended to grant access only to `my-special-script.sh`, the permission will actually be associated with the `security` tool, which any process can call. So here the security is contingent on an attacker not being able to run code as you (or trick/coerce you into running it).
 * **Storage in plain-text on the filesystem:** The security here is only so good as the security of the filesystem: privileged users will be able to retrieve the password regardless of filesystem permission. An unprivileged, determined attacker with local access will be able to elevate privileges by one means or another and gain access, even in the face of restrictive permissions.
 
 ## Limitations
 * **Storage in plain-text on the filesystem:** The security here is only so good as the security of the filesystem: privileged users will be able to retrieve the password regardless of filesystem permission. An unprivileged, determined attacker with local access will be able to elevate privileges by one means or another and gain access, even in the face of restrictive permissions.
 
 ## Limitations