Pulling Passwords from Keychain with Script

kyle_bareis
New Contributor III
New Contributor III

Hey all,

I am working on an after hours project in which I am trying to pull a password from Keychain. The command I am using is:

security find-generic-password -wl "com.squirrels.Reflector-2"

While this command does give back the correct data when run as a user and via Policy, it displays a message to the end user asking them to allow the lookup. The exact message is: a0e1feff621843809283d4fe2c1da23a
While this is not the worst thing in the world (doesn't require admin authentication for the end user), I would like to remove it if possible from showing up. Anyone know of a way to suppress, accept, or add Terminal temporarily to the Access Control so that end users don't see this?

Thanks!
Kyle

2 ACCEPTED SOLUTIONS

davidacland
Honored Contributor II

You can add to the access control tab of the keychain item but that also prompts the user to accept.

If the search is something you would like to be able to run in the future, it might be better to ask security to be added to access control once, than repeatedly asking the user to authorise the search.

To add the entry you can use:

security add-generic-password -a "account name" -s "com.squirrels.Reflector-2" -T "/usr/bin/security" -U

You'll need to check what the account name is on com.squirrels.Reflector-2 and use that after the -a option.

View solution in original post

davidacland
Honored Contributor II

The -U option tells the security command to update if an item already exists. If the item name, or account name don't match, a new entry will be created. I've just tested again on a couple of my keychain generic passwords and the security binary was successfully added. No new keychain entry created.

When the command runs I get:

c88fa83608d84588a1e5ea5e10c5896e

View solution in original post

5 REPLIES 5

davidacland
Honored Contributor II

You can add to the access control tab of the keychain item but that also prompts the user to accept.

If the search is something you would like to be able to run in the future, it might be better to ask security to be added to access control once, than repeatedly asking the user to authorise the search.

To add the entry you can use:

security add-generic-password -a "account name" -s "com.squirrels.Reflector-2" -T "/usr/bin/security" -U

You'll need to check what the account name is on com.squirrels.Reflector-2 and use that after the -a option.

mm2270
Legendary Contributor III

Unfortunately the security add-generic-password command can't add in Access Control settings to an existing keychain entry. It can add ACL entries at the time it creates a new entry, but can't do so afterwards, so the command above will just add a new entry with the same name, but with no password. I don't know of any way to add in an ACL after the fact, since technically that would be a security risk. Its always going to prompt the user for authorization to allow access to the keychain item. If it were as simple as running a security command to add in your own access, there would probably be a lot of malware out there trying to do the same thing to all our keychain entries.

Just to confirm that what I'm saying is correct, I had tried the above on one of my own keychain items and it just made a new entry with the same name, with "security" in the ACL list, but there was no password associated with it, of course.

davidacland
Honored Contributor II

The -U option tells the security command to update if an item already exists. If the item name, or account name don't match, a new entry will be created. I've just tested again on a couple of my keychain generic passwords and the security binary was successfully added. No new keychain entry created.

When the command runs I get:

c88fa83608d84588a1e5ea5e10c5896e

mm2270
Legendary Contributor III

@davidacland Hmm, that's interesting. I've never been able to get that to work that way. I wonder if its something to do with the keychain entries I'd tested it on, or, maybe I've just been doing it wrong. :/ Its been awhile since I've tested that (other than earlier today) so I don't know. I'll have to give that another go. Thanks!

kyle_bareis
New Contributor III
New Contributor III

@davidacland

Thanks! That seems to work well!