While we test some code, we deleted all full access keys of some NEAR accounts, and that account looks to be dead now.
We’re just curious why this is not forbidden. Is it useful somehow? It seems it could lead to catastrophic consequences for the user loosing control over their account.
While it is not useful and is dangerous for a regular account to get all its access keys deleted, it is a common pattern to create an account, deploy a contract, and remove all the keys from the account to prove that nobody can redeploy the contract anymore.
You can find a number of examples on NEAR mainnet already, e.g. staking pool contracts are deployed and "locked" this way staked.poolv1.near. See more details about locked contracts in this answer.
Accounts in NEAR may hold a contract, so there is no special case for contracts vs regular accounts. If there is no contract and no access keys, it is indeed a dead account, just as an account would be dead if it has public key(s) whose private key/seed phrase is lost.
The cool thing about NEAR's accounts model is that you could setup a backup key to the same account. All of your assets are attached to the account ID, so you can add new keys without a need to transfer all your assets.
Basic concepts documentation is a good starting point to learn more about accounts in NEAR.
The named account model should be quite familiar to anyone who used to work with Web2 apps, where users usually use their usernames as identifiers, and when signing in, the server generates a session token. The NEAR accounts model is almost the same but instead of some random session token, cryptographic keys are used.
I also believe that smart contracts holding fungible tokens or non fungible tokens should delete all access keys. Otherwise, it would be possible to change the contract, and modify the ownership of the tokens.
Related
I am writing a server side python script with Pydrive which needs to store a file in a specific gdrive. Pydrive and this post suggest to use a service account.
However this would mean that with the credentials of this service account all gdrives are accessible and I would rather avoid that.
Ideal only one specific gdrive or all gdrives where one specific user has access to should be accessible.
Is it possible to give programmatically access to only one specific gdrive?
[Edit]
As mentioned in the comments I am apparently not looking for a OAuth flow.
I am looking for a server-to-server communication for accessing one specific google drive using the principle of least privilege access. Doing this with a service account + domain wide delegate and google drive r/w scope would mean that with this service account all google drives can be accessed which is not what I want.
Unfortunately there is a domain wide policy in place which forbids to share google drives to "other" domains. This means I can not use a service account without domain wide delegation and just share the drive with it.
I don't understand what you mean by "programmatically", when you already tag the question as oAuth - asking for oAuth2 flow, which is interactive. When there is nobody, who would press the buttons, this probably isn't the authentication flow you're looking for. Just share a directory with a service-account; no domain-wide delegation is required (with that enabled, there would be no need to share it).
One could even abstract the whole Drive API access credentials away by using a simple Cloud Function, which has to task to update one file; triggered through HTTP, utilizing the Drive API.
Possible approach - dummy account
You could designate a new account that will be your "service account". In reality it won't be an actual service account, it will just be a dummy account that you can call something like "gdrivebot#yourdomain.com". Then you can share only what is absolutely necessary with it. I think this would be the only way to get that level of fine-grained control that you are looking for. This would require your admin to designate a new account just for this purpose though.
I have a .NET console application that performs operations on files. I would like to allow clients to give us access to their Google Drive accounts so we can read and write files. Our console application runs as a service so there is no way for the user to interact with it and authorize our access to their Google Drive account.
I was looking at using a Google Service Account for application level authentication until I learned that a Service Account does not have access to the Google Drive folder of the user that sets up the Service Account. This sort of defeats the purpose because it is the client's Google Drive account I am looking to gain access to.
I saw a workaround posted by SO member #pinoyyid posted in this SO answer where the refresh token can be generated using Google's Oauth2 Playground, but I am concerned that the refresh tokens could expire and user intervention would be needed again to generate another one.
Another response mentioned the solution was to create the Service Account and then share the user's Google Drive account with the Service Account.
What is the recommended approach by Google? How best to gain access to a Google Drive account while only requiring the owner to authenticate on a one-time basis, yet allowing them the ability to revoke access at any time?
Both Service Account and a stored OAuth Refresh Token are viable approaches. Each has its pros and cons.
A Service Account will work where your users only need to grant access to a specific folder which they can share to the SA. Be aware that any files the SA creates are owned by, and consume quota of, the SA. You can't "share the user's Drive account to the SA", you can only share individual folders.
Storing a RT is the more permissive option. You wouldn't use the OAuth playground as described in my answer that you referenced as that's far to clunky to ask users to go through. Instead you would need to write your own registration/authorisation service (you can use AppEngine, Lambda, etc - so it's not difficult to write and host).
I was going through the (seemingly intricate) procedures for getting a company's artifact on Maven Central. Then I got to the GPG signing part and entered a new world of confusion and conundrums. GPG has so many options, and it's not evident what a reasonable practice should be for signing company artifacts.
Let's say that Acme wants to publish an artifact org.example.acme:foobar:1.0.0 to Maven Central. What user ID should they use to sign it? What subkeys? How would that key be kept separate from the user's personal key?
Let me go through all the doubts to give you an idea of why it is confusing.
What email should I use for Acme? Should I use admin#acme.example.com? Should the identity be for Acme, or a division of Acme? Or should only individuals sign artifacts for publication on Maven?
What about the comment? One source said we should leave comments out altogether. Should I use "Acme (software) software#acme.example.com"? Or just "Acme acme#acme.example.com".
OK, so maybe you say it doesn't matter, and that all this is opinion based, and I can use whatever works for my company---fine. But then how do I keep my company and personal ID separate? Can I have a key for Acme and a separate key for John Doe on the same keyring on the same computer? How would I then distinguish them when publishing artifacts? All of the examples seem to assume you are using a single identity.
Should I be using subkeys? Should I create different subkeys for different departments? Or different identities for the same subkeys? Or what?
Should I make my keys expire? Or just the main key? Or just the subkey?
I could go on and on and on... Trying to summarize, all the examples seem to assume 1) the user only has one user ID installed on their keyring, and 2) everyone signing their artifacts are individuals, not companies.
What is the expected approach for signing the Maven artifact of an organization; and how does a user manage the organization's key separately from the user's individual key?
What email should I use for Acme? Should I use admin#acme.example.com? Should the identity be for Acme, or a division of Acme? Or should only individuals sign artifacts for publication on Maven?
Use the one that is used for public communication of the group/department using the key. For a smaller company, I'd probably go for some generic address like info#acme.example.com.
Don't mix in persons. This is a company key, which identifies the company (or a specific function inside the company) and not an individual.
What about the comment? One source said we should leave comments out altogether. Should I use "Acme (software) software#acme.example.com"? Or just "Acme acme#acme.example.com".
Does the "software" comment add any relevant information? I don't think so, so leave it away as it just adds noise.
Often, something like "signing key" is added as a comment for such keys. I don't consider this necessary, as the usage is obvious. If you want to prevent others sending encrypted mail using that key, better limit key usage to signing only, which enforces this limitation (and does not just ask other users not to use the key for encryption).
OK, so maybe you say it doesn't matter, and that all this is opinion based, and I can use whatever works for my company---fine. But then how do I keep my company and personal ID private? Can I have a key for Acme and a separate key for John Doe on the same keyring on the same computer? How would I then distinguish them when publishing artifacts? All of the examples seem to assume you are using a single identity.
You can have an arbitrary number of keys on your computer, that's not an issue. Maven (and other software relying on GnuPG) can be configured to use a specific key. Usually, you can either put a user ID, mail address, key ID or fingerprint in there -- as this is a one-time-configuration, better use the most specific way, the fingerprint.
Should I be using subkeys? Should I create different subkeys for different departments? Or different identities for the same subkeys? Or...
Yes, you should. This is an important key. Keep the primary key offline (in a safe, ...; with very narrow access for others but the most important people/managers in the organization). Only hand out subkeys limited to signing: you either put such a key on a build server, or hand it to the employee who is pushing the builds. If you need to exchange a key, you don't have to change the primary key, but only the subkey (which is not a lot of effort, and especially does not involve telling your customers about the new key).
To mitigate employees leaving the company taking copies of the key, take advantage of OpenPGP smart cards (which might also be a YubiKey). The key cannot be fetched from the card, so theft of the key is equal to theft of the card (and can hardly go unnoticed).
They don't want to give me their Amazon username and password because it has their complete purchase history.
Is there anyway for them to authorize me as a user?
Amazon has AWS Identity and Access Management, that should help with what your asking. http://aws.amazon.com/iam/
It's easy enough to create new accounts on Amazon, and it's also reasonable to keep corporate and personal accounts separate for expense purposes. I'd recommend doing that for simplicity, but I understand that it could be a concern regarding potential misuse on the rest of the Amazon site.
The use of access keys (as suggested by #KristianGlass) may be adequate, as well, allowing you to create and kill instances, but not allowing you access to the main AWS console. Elasticfox also works with the EC2 keys, so you could use that as a surrogate for the console.
Depending on what you're looking for, they might just be able to create you an Access Key and have you use that.
If they look under "Security Credentials" in their Account page (this should be a link to it) they can easily "Create a new Access Key" (they will of course need to give you both the Access Key ID and the Secret Access Key).
To paraphrase Amazon's documentation about Access Keys, you can use them for making requests to REST or Query APIs - specifically this includes EC2.
We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.
It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)
GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.
Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)
Just looking for some thoughts and ideas on best practices before starting implementation.
I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:
By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.
Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.
Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.
API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).
Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.
The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.
The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.
I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.