Create new KeyChain Option
vamsig7 opened this issue · comments
Is there a way to store Keychain items in custom keychain(myOwnKeyChain) rather than in the default login keyChain? I didn't find any relavant function to create a new Keychain. I have a usecase in which I have to store a bunch of seperate Keychain items preferably in a custom keychain
Or a way to store items in different keychain if its already created and path is known
Thankyou
Hi @vamsig7! Thanks for your interest in Valet.
Can you help us understand your use case? We currently support storing items in the login and iCloud keychains, but you're right that we don't have support for creating a new keychain.
I'm curious to understand the motivation behind using a new keychain, and I'm also curious which platforms you're attempting to support.
To be honest, I don't know that much about custom keychains. But I'm interested to learn more. Worst case I can provide some guidance on how hard it would be to add this functionality to Valet via a fork. If you've got any docs you can link me to, that'd be helpful as well.
@dfed
1.)In my case I have a bunch of keyChain items that I don't want user to tamper (Assume user viewed/modified a keychain item from KeyChain Access application ),This modifications can impact my application and cause unpredictable ,undesired outputs.)So I want to create my custom KeyChain such that user cant view/modify values inside that.
2.) I want to store a handful of KeyChain items of different types(keys/passwords/Data),its convenient for me to have a seperate a KeyChain for my group of apps
3.) Incase if I store any normal Data like(Integer,String) there is no need to hash the value by some sort and store it (As I don't want user to see this value ,yes this is value is user specific but not something user allowed to modify ).
Having a custom KeyChain allows me lock/unlock KeyChain once my usage is done(with my own password ,In case login KeyChain its user password). SecKeyChainLock
User can't delete a particular item inside KeyChain(As user can use his own mac password here)
.Yes user can still delete entire KeyChain from the KeyChain path provided while creating KeyChain with SecKeyChainCreate, this can be considered as fresh installation of application and easy to handle ,rather than checking availability of each keychain item inside keychain(just my opinion)
While uninstalling application its easier to clean ,just delete my Keychain rather than each keychain item using SecKeyChainDelete
Deployment target : macOS10.15+
I tried creating a KeyChain by using SecKeyChainCreate ,unlocked it/opened the correct path ,then i used valet to write values using _setObject(),still it writes inside login rather than in my own KeyChain
Rather than apple docs ,there isn't much help on usage of this functions any where ,this is makes is hard to use 😩
https://developer.apple.com/documentation/security/1401214-seckeychaincreate
https://developer.apple.com/documentation/security/1402180-seckeychainlock
https://developer.apple.com/documentation/security/1400341-seckeychainunlock
https://developer.apple.com/documentation/security/1396431-seckeychainopen
I used this functions to create/unlock/open custom KeyChain
Thanx for response
Looks like we'd need to add a kSecUseKeychain key:value pair to our SecItem* calls. As expected, this key is only available on macOS.
Thinking on this more, I don't think this is functionality that I'd want to add to this library. Valet is a keychain wrapper for folk who don't need or want to know that much about how Keychain works, and this is getting into pretty advanced / deep knowledge about the system.
The good news is that it should be somewhat trivial to fork Valet to add this functionality yourself. What you need to do is add a kSecUseKeychain key:value pair where the value points at your custom keychain to the keychain base query before returning from the generateBaseQuery method here.
I'm going to close this issue out. Thank you for providing the docs I needed to dig in, and helping me understand your use case. Hopefully the above information can help you create a low-maintenance fork that solves your needs.
As an aside, while I don't know much about the project you're working on: unless the values you are storing have national security implications (or otherwise enabling a customer to view these secrets would cause harm), I'd recommend storing these secrets in the login keychain. If a customer modifies the keychain themselves and that breaks your app, I think it's fair to say that the customer utilized your app and its data in an unsupported fashion. Modifying an application's keychain storage is akin to going into the application package or ~/Library/Application Storage/YourApp/ and modifying files.
I think the workflow you outlined is a great way to ensure your keychain data is not modified by a customer. But I do wonder if this approach is worth the effort. And I also wonder how I'd react if I saw a custom keychain in my Keychain app that I didn't create or explicitly ask to be created.
Just my $0.02. Feel free to ignore! Hopefully the approach I outlined in the previous post will enable you to accomplish your goals.
Thanks for the pointers, these are no national secrets, I just don't want the user to know the internal working of my app and break the app through keychain
Anyway, thanks for your time and this great library :)