An account is created locally using near-cli toolkit, which creates a local keypair. How can you import this account such that it is usable via a wallet on NEAR, for example by using a seed phrase recovery?
Presumably you can map the private key to the seed phrase. Is that advisable?
Related
My question is regarding taking over a partially minted CM project. I'm not too familiar with Solana development.
A buddy of mine is taking over ownership of a project. I just wanted to confirm: if the authority of the candy machine is updated to his wallet and he has the CM id that's all that would be required to relinquish previous ownership? He'd be free to make changes to the CM configuration at that point.
Also, the authority of each minted NFT would have to be updated as well? Would the only downside of not updating the existing NFTs be not being able to change the royalties?
Is there anything else to consider in transferring ownership?
Thanks in advance!
An already partical mint has a few things that need to be updated to fully take over a project.
You'll need to have on hand the update auth keypair for the Candymachinne given to you by the old owner or have them perform some of the actions here if they do not hand it over as some actions need to be performaned by the original keypair.
Update the CandyMachine CM to a new authourity. This will grant access to the new wallet full controll of the CM only and all NFT's minted from that point forward will their update authoritys will be set to the new candymachine authority on minting.
Get Treasury Balance (optional). If you are taking over the original treausry then getting the old owner to either hand over the private key to treasury account (extremely unlikely) or by getting them to transfers the funds to wallet of your choosing. If they for what ever reason give you the keys to the treasury wallet then you then transfer this balance out to a wallet of your choosing.
Update the CM treasury - When a purchase is made from a candymachine the SOL is sent to the treasury address, this obviously needs to be a wallet that new owner owns.
Updating already minted NFT's to the new authority. If minting has already happened then the update authoritys for these NFT's will belong to the old candymachine authority (the old owner). To secure these NFT's you'll have to update the update authority of them to the new owner. So this means you will need the original private key of the candymachine auth or you will have to get the original owner to transfer the auth over to you.
A tool to update the authority of NFT's is Metaboss. If you look at this page here https://metaboss.rs/set.html there are a few commands you can use for updating the authority. You'll also obviously need a snapshot of all the current NFT's that have been minted so you can run the set auth commands. https://metaboss.rs/snapshot.html
Once you have update authority over the NFT's you can then change royalty % and everything else.
1.- Yes, if the authority is changed he just need to provide the New wallet address, and that New wallet will be the only one that can modify the Candy Machine configs.
2.- All the already minted NFTs will be attached to the old wallet, the New minted NFTs should be attached to the New wallet. In order to change the authority of the already minted nfts to the New authority the old wallet have to do it using metaboss for example.
3.- The old wallet can update every data of the NFT (if the nft is marked as mutable that normally everyone does it), it can change the images, the attributes, the royalty fees, the creator array, names, etc. Its really important that the New wallet have the authority of all NFTs in order to not get malicious attacks from the old owners of the project that you wont be able to fix after.
Need a help on how do I handle rotating keys on google cloud storage thats managed by one google account but being accessed by an app thats running on another google cloud account. I tried searching for solutions but couldn't find an answer
With IAM service you can grant permission at project level, and, for some resources, at resources level.
It's the case for your KMS keys where you can grant permission on the key rings
Or directly at the key level
Choose what works the best for your use case, and grant the service account of the external project with the correct permission (decrypter to read the files in the GCS, encryter to write files)
Note: A key rotation is a new version of a key.
We are starting to use Terraform to build our aws ec2 infrastructure but would like to do this as securely as possible.
Ideally we would like to do is to create a key pair for each Windows ec2 instance dynamically and store the private key in Vault. This is possible, but I cannot think a way of implementing it without having the private key written to the tfstate file. Yes I know I can store the tfstate file in an encrypted s3 bucket but this does not seem like an optimal secure solution.
I am happy to write custom code if needs be to have the key pair generated via another mechanism and the name passed as a variable to Terraform but dont want to if there are other more robust and tested methods out there. I was hoping we could use Vault to do this but on researching it does not look possible.
Has anyone got any experience of doing something similar? Failing that, any suggestions?
The most secure option is to have an arbitrary keypair you destroy the private key for and user_data that joins the instances to a AWS Managed Microsoft AD domain controller. After that you can use conventional AD users, and groups to control access to the instances (but not group policy in any depth, regrettably). You'll need a domain member server to administrate AD at that level of detail.
If you really need to be able to use local admin on these Windows EC2 instances, then you'll need to create the keypair for decrypting the password once manually and then share it securely through a secret or password manager with other admins using something like Vault or 1Password.
I don't see any security advantage to creating a keypair per instance, just considerable added complexity. If you're concerned about exposure, change the administrator passwords after obtaining them and store those in your secret or password manager.
I still advise going with AD if you are using Windows. Windows with AD enables world-leading unified endpoint management and Microsoft has held the lead on that for a very long time.
I have my agent hosted in DialogFlow. Because of security reasons, I need to update DEVELOPER_ACCESS_TOKEN. I know there is a way to update CLIENT_ACCESS_TOKEN from settings. But didn't find any way to update DEVELOPER_ACCESS_TOKEN.
If your developer access token is compromised, you should create a new agent and transfer your intents and entities across.
Create a new agent
Export your current agent as a zip
Import the zip to the new agent you created in step 1.
If you are using this Dialogflow agent with Actions on Google and wish to continue using the API V1, you will need to create a new Action.
Alternately, consider switching your agent to use the API V2 Beta, which uses Google Cloud Service Accounts instead of API keys and will solve your problem.
I need to migrate a huge application to Windows Azure. The application depends on a third-party library that requires an activation key stored in a special binary file on the role instance filesystem.
Obviously that key has to be either included into the role package or stored somewhere where role can fetch it. The activation key will not be bound to the machine (since I have no idea where exactly a role will be run in the cloud) so anyone can use it to make a copy of that library work.
Since Azure roles run somewhere not under our control I feel somewhat paranoid about the key being stolen and made widely available.
How do I evaluate how likely it is to steal a binary file that is included into Azure role? How do I mitigate such risks?
When asking questions like this you need to differentiate your attackers:
A2) Rogue internet hacker
A3) A developer in your organization
A4) A person in your organization who does deployments
Your role binaries are not accessible to A2, however they are very accessible to A3 and A4.
As mentioned in another answer, you can store your secrets in the Role Configuration File.
However, these secrets are still accessible to A4 (anyone with access to the portal).
To defend against A4 you want to encrypt the secrets in the role configuration file with a key that isn't present in the role binaries or the role configuration. Then in your role binaries you decrypt the encrypted role setting, with the decryption key.
The key to use for encrypting the secrets is a certificate, which the Azure SDK will install for you. You can find a post about setting up certificates for azure here.
In summary, for secrets where you need to defend against people in your organization who do deployments/have access to your configuration files you do the following:
Have a trusted party do the following:
Generate a Certificate/Private Key
Encrypt secrets with the Certificate, and store the encrypted settings in your configuration files
Upload the Certificate/Private Key to your service.
Then modify your service to:
Have the service model install the Certificate/PrivateKey
Have your application, load the private key for decrypting secrets
Have your application load the encrypted settings from role configuration, and decrypt them with the private key.
As far security is concerned, unless your team is extremely capable in this area, the default always upgraded Azure OS is probably much more secure than any self-configured host. At least, this is how we (aka my company, Lokad) assess the situation two years after migrating in full to Windows Azure compared to our previous self-hosted situation.
Then, if you have credentials, such as licence keys, then the most logical place to put them is the Role configuration file - not the Role binaries. You can naturally regenerate the special file within the VM as needed, but this way, you don't internally spread your credentials all over the place as you archive your binary versions.