When it's just an access key that is compromised on NEAR, it is easy to add a new key and delete the compromised one with add-key and delete-key commands.
But what if a 12-word seed phrase (eg for a wallet recovery) is compromised for an account like foo.near? How do you swap keys safely such that the account is no longer compromised (and you don't have to create a new account)?
You need to delete the account and transfer funds. Then you can create an account with the same name and the wallet will generate a new seed phrase
Related
I´m working on a contract using rust that creates subaccounts and transfer some tokens to it as part of its functionality, but since im repeating the process many times testing the functions I wonder if im leaving many subaccounts created. Is there a way to list all the subaccounts an account have?
There is no simple way because each subaccount is an independent account and the upper-level account has no control over subs.
Though you can try to use Indexer for Explorer public database to query accounts table with something like:
SELECT account_id FROM accounts WHERE account_id LIKE '%.youraccount.near';
From the README
NOTE: Please, keep in mind that the access to the database is shared across everyone in the world, so it is better to make sure you limit the amount of queris and individual queries are efficient.
I have 3 organizations Org1, Org2, and Org3 which use HLF v2.2. The organizations store some organization-specific data in key-value pairs(assets) on the blockchain (keys are unique across as we prefix with organization code). The key-value pair which goes on the blockchain with an organization code prefix is updatable by that organization (CREATE, UPDATE & DELETE) and the rest of the organizations can only have READ access. How can we achieve this behaviour? I am thinking of having a cache within the chaincode that maps Org mspid with Org code and in the functions that manage organization assets, I can then check if the invocation is coming from a specific organization and accordingly allow to perform the update operation. Any ideas are greatly appreciated.
Maybe Private Data fits your use case. Look at Scenario 2 in this article: https://kctheservant.medium.com/private-data-collection-policy-demonstrating-members-only-read-and-write-features-b2e03ff02332. This way you could define a private collection per organization that could be read by the other organizations (although the requesting client should query the peer of the corresponding organization).
If your privacy concerns are related only to clients (if you trust the peers and orderers from other organizations), maybe you don't need Private Data features. You can simply evaluate the requestor MSP in your chaincode to apply your restrictions.
This answer about upgradability suggests that at some point you should delete access keys to the account containing a smart contract: How do you upgrade NEAR smart contracts?.
It makes sense that a smart contract should be "frozen" at some point, and you want to give its users confidence that it will not be changed. But what about contract rewards and other funds belonging to the contract account? How would the original owner get access to that if keys are deleted?
But what about contract rewards and other funds belonging to the contract account? How would the original owner get access to that if keys are deleted?
The contract should be implemented in such a way that would allow certain operations.
Let's take a lockup contract as an example. This contract has a single owner, and the funds are locked for a certain amount of time, and the contract only provides certain methods to be called and guarded with the specific logic:
As an owner, I can delegate (stake) my tokens to staking pools while I still cannot arbitrary transfer the tokens
As an owner, I can withdraw the rewards from the staking pool through the lockup contract, and transfer those to an arbitrary account
Once the lockup time is over, as an owner, I can call add_full_access_key function, and thus gain full access over the account, and even delete it after that (transferring all the tokens to some other account).
All that is explicitly implemented on the contract level, and easy to review, and given there is no other AccessKey on the lockup contract, we can be sure that there is no other way to interfere with the contract logic.
Lets say that i need to have all the users entered data encrypted in my db and i am doing it like this:
Crypt::encrypt($request['content'])
Lets assume that my site will live and prosper for many years with many users and many many gb of encrypted user data.
Does this mean that i have to be absolutely sure that i don't loose my app_key which is in my .env file?
The only thing i could do if my key is compromised is to only decrypt and encrypt with a new key?
You are very right.
Laravel is using AES encryption and exact key is needed for decryption of data.
If you ever want to decrypt your data again then you need the encryption key.
In Laravel implementation it is not possible to simply change the key. If key is changed then you need to reencrypt your data.
I am building an authentication system in ruby, and using redis for storing users' access data. I like to know which of redis datatypes is more suitable to use?
None of them. Redis is supposed to be used in a trusted environment, its own authentication mechanism is basic, and there is no access right or ACL associated to data. It is quite weak to store security sensitive data.
Now, if you really need to do it, you can either serialize the properties of your users and store each user in a single string, or use one hash object per user to store the properties separately.
For instance:
SET user:1 {"lastname":"Smith","firstname":"John","passwd":"38E56712AB15"}
or
HMSET user:1 lastname Smith firstname John passwd 38E56712AB15
The first solution is more optimal if you access the users systematically in a global way (retrieving/updating all the properties in one shot).
With the second solution, it is a bit easier to encrypt only one part of the data, and to support partial update/retrieval. Of course encryption must be done on client side.