macOS Converting .csv/.txt into .keychain?

[kumquat]

Is there a reverse script for security dump-keychain -d example.keychain > example.txt? Something which would take a .csv or .txt file & convert it back into a .keychain file?

I have divided up the iCloud & login keychains from several different Macs into, for instance Application-Passwords-iMac.keychain, Web-Passwords-MacBook-Air.keychain, Login-Certificates-Mac-Mini.keychain.

I did so because I was running into a number of errors & hundreds of missing items when using ruby keychain.rb keychain.txt | sort > keychain.csv & dividing them up by type allowed me to see what changes I needed to make to the keychain.rb file to allow all items to pass through from the .txt to the .csv. After tinkering with the keychain.rb file, a complete text dump & csv conversion of all passwords was accomplished, with the certs & keys exported through the Keychain Access UI.

My intention was to then load the content of all the .csv files into Excel, or the like, along with passwords from 1Password, Blur, etc. I would, next, remove duplicates & mark ones I felt needed to be changed. After this, I had intended to re-import the complete & cleaned up list of passwords originating from this variety of sources into OS X Keychain....However, looking more closely at the import options, I'm not seeing the ability to import any type of text document into Keychain at all.

So, is there a way to convert any type of text doc into a .keychain file? What I want is to be able to edit all my passwords in pretty much any UI other than that of Keychain Access so I can see everything at once & not have to run an 'Allow' Applescript five million times. I would very much appreciate any suggestions. Thanks.

 

[chown33]

Consider building a series of 'security' commands, which are then executed in sequence. In short, build a shell script file. This is just an idea based on the 'security' command's man page:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/security.1.html

According to the man page, there are two sub-commands that add passwords: add-generic-password and add-internet-password. I hope that part of your cleanup managed to preserve this property from the original export, because it looks like you'll need it.

Each of these sub-commands has a host of options. After my brief reading, it appears that everything about the password entry can be specified with a suitable option.

So the way to proceed is to parse the .csv or .txt file, presumably getting the data from the proper column (field) using whatever delimiter you've got in there. Once you have a collection of fields, you emit text with the proper options and whitespace. Here's a simple example:

Suppose the fields consist of tab-delimited account, password, item-type, and kind (terminology per 'security' man page). In awk, these would be:
$1 = account
$2 = password (cleartext)
$3 = item-type
$4 = kind

The awk statement to print these would be:

print "security add-internet-password" "-a" $1 "-w" $2 "-C" $3 "-D" $4

Since the default output separate in awk is a space (the OFS variable), the above would be printed with a single space between the items.

Awk seems pretty well suited to doing this task, because it automatically does the "read a line and break into fields" for you, and can automatically match input patterns to specific actions. The output from awk would look like a series of 'security ...' commands. You could copy and paste one into a Terminal window to make sure it works before committing to the whole sequence.

If there are more than just password entries, you'll have to produce 'security' command-lines that do the correct thing according to the entry's type: add a cert, add a private key, etc.

The output of awk can also be piped into a shell, which would then interpret the commands produced. This would be the daredevil approach. Safer would be to redirect awk's output to a file, which you then review carefully, try one or two commands individually, then if all proves well, you can tell the shell to run.

Personally, I'd go one step further and write only to a nonce keychain created expressly for testing (see the 'security' man page). To complete the test, open the repopulated keychain with the Keychain utility app and make sure it works. If not, it's much easier to close that file and trash it than it is to manually remove a bunch of borked entries from your main login keychain.


Think of it as writing a program in awk that takes the input data and produces a shell script. Executing the shell script is what writes all the keychain entries, not the awk program itself.

 

[kumquat]

Wow, ok, that gives me a lot to chew on. Thank you.

Yes, the 'class' property has been preserved as that was how I differentiated between keychain items & each of the five 'classes' I found within my tangle of passwords required different fields with different definitions be requested for output/conversion. The lack of those specifics per 'class' was what was borking up the original (and an adapted version of) keychain.rb for me & figuring out what needed to be included/excluded was mostly trial & error. I have delayed doing any merging or 'cleaning up' of all these dumped & converted files until I found a solution for re-importing.

Definitely agree that doing a test output & populating to a new keychain is the safest way to go & creates the least amount of mess to clean up if/when things go sideways.

It still seems kind of crazy to me that there isn't a built-in mechanism for importing non-.keychain files -- nor, for that matter, for exporting to a human readable format.

 

[chown33]

It still seems kind of crazy to me that there isn't a built-in mechanism for importing non-.keychain files -- nor, for that matter, for exporting to a human readable format.

I think it's a consequence of a couple factors: utility (who would use it, how often) and security.

One of the working principles of security is to keep secret things secret. That means private keys are kept wrapped (encrypted), even when exported. Same thing for all other secrets, including passwords. Exporting to cleartext defeats that. Furthermore, if there's a simple pathway to both export and import in which the intermediate form is cleartext, then that design is fundamentally encouraging users to break the important principle of secrets remaining secret.

If a person has need to move keys, passwords, etc. around as files, then that's what keychain files are for. Since they're wrapped (encrypted), they don't defeat the secrecy principle. Moving content using files is one of the main purposes of import/export, so that purpose is better served using keychain files. Granted, one of the other purposes of import/export is interoperability, and that requires an external compatible format. That's why all the exporting typically wraps secrets by default, and you have to make an effort to export secret items in cleartext.

I'm not saying that cleartext import wouldn't be useful. It would. It's just that on balance, relatively few people would use it, and its presence would undermine security in a significant way. As a directly accessible feature, it's a casualty of utility and security tradeoffs.

 

[ArtOfWarfare]

Just going to mention that I tend to manage passwords using the Python module keyring. It automatically uses whatever is appropriate for each platform - so Keychain on OS X.

Setting and getting passwords is trivial.

It's available via pip.