OSX password script for everyone to know
blog.songz.me
blog.songz.me
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
In such a scheme, the keychain can do the computation and the password never leaves the keychain. We can even go as far as to have the keychain be separate hardware (eg USB dongle), so the password never even has to exist on the client's computer at all.
https://developer.mozilla.org/en-US/docs/HTML/Element/keygen
How about borrowing a friends computer? If you suggest that I'd bring a USB-dongle for that we live in different universes.
Regardless, the idea that the plaintext password doesn't have to leave the device (whether the device is a dongle, your phone, or the keychain application) is a valuable consequence of the challenge-response mechanism, and I wish support for it were more widespread.
Unless that is solved it isn't a solution worth considering.
- computer shows challenge#
- user types challenge# on bank supplied device
- bank supplied device shows response
- user types response on computerYou have to enter your password into all your devices anyway, so why not use challenge and response?
*Edit: Actually it looks like you can set Keychain to lock automatically after X minutes of inactivity or when the computer sleeps.
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)))
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."
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.
$ security set-keychain-settings -lut 1800It would be better if you could set it to require a password every time a previously unauthorized app requests access to a Keychain item.
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?
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.
Layering security on the user account after login tends to annoy the hell out of people. Ask any users you know what they think of Windows 7/Vista's UAC.
> Layering security on the user account after login tends to annoy the hell out of people. Ask any users you know what they think of Windows 7/Vista's UAC.
But this isn't another OS. This is OS X, which is built on BSD, and BSD is a secure OS. Another question to ask would be "Ask any users you know what they think of sudo".
I like the article. It's not sensationalist. It's not dramatic. It's just saying "Hey, do this! Surprised? This is why you need to be careful with your account and your password."
That seems reasonable to me. Many people Using OS X are not from a Unix background. They have never used a BSD before. They don't really have the security stuff ingrained.
Gentle reminders from time to time are a good thing.
Your login Keychain is usually unlocked - it's encrypted with a key derived from your password that's held in memory from when you log in.
You can lock your login Keychain (or any other) from Keychain Acccess (/Applications/Utilities) or from the security menu bar item (if you have it added) and you'll be asked for the password rather than asked to "allow" it.
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.
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.
Actually you can configure KeyChain to do just that: just set the keychain to lock after 0 minutes of inactivity. But there is always the tradeoff between security and convenience. And when you give away physical access and a logged-in session away to a malicious user, offering protection will require a lot of inconvenience.
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.
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.
And it's worth pointing out that the "other parts" have also been audited by security professionals.
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
[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]
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.
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.
What do you mean with "only". It's asking you exactly for that reason.
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
doneBut I'm just guessing -- I don't know too well what a private key would look like in this format.
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.
1Password is more portable though - Keychain is only useful in MacOS X.
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.
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.
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.
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.
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.
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.
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".