Prevent sync of passwords, api keys, and sensitive variables

[jeremyml]

Postman does not have a feature to prevent credentials and other sensitive variables from being synced to Postman servers. Unfortunately this is a large security vulnerability which prevents our organization from using Postman while signed in. We must use Postman without signing in (local only) to prevent sync of production credentials.

I read the Security page on the Postman website, but saying "only the founders have access" is not sufficient. If you build a tool where tens of thousands of users have api keys and passwords stored, then that repository will be a massive target. If the NSA can be hacked, then Postman can be hacked.

Postman is a great tool. We would be willing to pay for Postman if we could keep our credential variables private (not synced to Postman servers). However this feature does not exist.

In the meantime I recommend everyone with sensitive credentials use Postman offline (local only) until this feature exists.

[preethammavin]

@jeremyml We have introduced session variables to address this issue, so that the sensitive information is not stored on our servers and also when you share the environment it doesn't get shared to you team members as well. In environment you should be able to see Initial value (which is synced) and current value which is only local to your device and is not synced.

We understand the users concern of not wanting sensitive information stored on any server, hence this is available on all variable format in Postman

For more detailed info : https://learning.getpostman.com/docs/postman/environments_and_globals/sessions

[jeremyml]

Ok, great! I see that explanation now.

[nickbeaugie]

That link above is now dead... is is possible to post a new one?

[EddieSem]

That link above is now dead... is is possible to post a new one? https://learning.postman.com/docs/postman/variables-and-environments/variables/#sessions-in-postman

[argarner]

The session variables ("INITIAL VALUE") implementation does not go far enough with security and is inadequate. There is nothing preventing a user from accidentally adding sensitive credentials to this field and syncing with the server.

Possible solution: All variables should have the option to set its state to "secret", disabling the "INITIAL VALUE" field entirely, across browser and local apps (maybe changing it to "description" that can be used to document how to obtain the credential?), as well as disabling the "CURRENT VALUE" in the browser to prevent accidental setting of these envs outside the local installation of the app. Obviously, the ability to set this option should be linked to access control and only editable by admins.

[gritsly]

The session variables ("INITIAL VALUE") implementation does not go far enough with security and is inadequate. There is nothing preventing a user from accidentally adding sensitive credentials to this field and syncing with the server.

Possible solution: All variables should have the option to set its state to "secret", disabling the "INITIAL VALUE" field entirely, across browser and local apps (maybe changing it to "description" that can be used to document how to obtain the credential?), as well as disabling the "CURRENT VALUE" in the browser to prevent accidental setting of these envs outside the local installation of the app. Obviously, the ability to set this option should be linked to access control and only editable by admins.

Second that. Please reopen this issue.

[bkosborne]

Looks like this solves it? https://blog.postman.com/introducing-secret-variable-type-in-postman/

[aakarim]

@bkosborne it looks like any user (even not logged in) can visit the shared workspace link and click the eye button to reveal the secret, so I'm not sure how this helps.

Wouldn't it be more helpful to have access control on the environments, so even in a Public workspace you can't use certain internal environments? Or is this totally the wrong way of approaching API development using Postman?

[TicoM1]

Too bad online accs are now being forced after update and I effectively lost all collections. A warning would have been nice. I was close to getting Postman accepted as standard API tool in a 20000+ emp company. I'm forced to uninstall it now and switch to a different solution. That sucks so bad.

[preethammavin]

@TicoM1, the collections are present in your application unless deleted by the user. Postman allows you to export in case you do not want to sign up/sign in. When you do choose to sign up/sign in we also prompt you to migrate the data from scratchpad to the cloud. If you have concerns about migrating to the cloud or face hurdles during this migration, do write to us at migrate@postman.com.

[TicoM1]

@preethammavin they're not only concerns! There is absolutely no way possible, I will ever (or will be allowed) to store info like that on some cloud platform without any benifit, when there is tons of identical offline solutions. Postman is out. We checked tesfully (they explicitely offer pm scratchpad alternative) but we switched to insomnia now. Found the postman collections I exported a while back and imported them to Insomnia -- no issues. 1-2 h and we're all set again (online community is very strong and there's a an existing stackexchange article for everything).

[ilya-scale]

It seems that both Initial value and Current value of a Secret variable are being synced to the cloud. Today Postman has forced me to create an account and if I import my collection, then all the env variables would be in the Postman cloud. I assume that it is not protected with the master password like e.g. LastPass or 1Password, meaning a hack of the Postman cloud would reveal enormous amounts of secrets.

Is there a way to make secrets really secrets in Postman with online sync?

I do not see any way and using Postman in this state becomes a huge security vulnerability as far as I can see.

This is what I have found for Insomnia:

End To End Encryption (E2EE)

Insomnia supports end to end encryption (E2EE) which allows us to fully encrypt all data that we create and requires a passphrase in order to be decrypted.

This capability is turned on by default on every account of Insomnia.

With E2EE enabled, the data is encrypted on Insomnia’s servers as well, and nobody can access it but the legitimate owner (not even the Insomnia team).

I was not able to find anything similar for Postman.

[preethammavin]

@ilya-scale - we do not sync current values to the cloud. All values stored on current values are stored locally for usage in the application. Users can choose to enter into initial value which is synced to the cloud which is not done by default.

You can read about this in detail in our documentation here: https://learning.postman.com/docs/sending-requests/variables/#sharing-and-persisting-data

You can also read about our security here: https://www.postman.com/trust/security/

[ilya-scale]

Thanks for the clarification @preethammavin , it was not quite clear that this is the case since I used only offline version before and then I had initial value set up.

When I synced with Postman my test collection the initial value was apparently written to current value in the cloud so it looked like it was synced but in reality it was only "duplicated" from initial.

It is probably a good idea to warn about this thing since I guess many have exactly the same thing: initial values with secrets

Can I also ask if you maintain history? I.e. if initial value is changed, would the previous one be stored?

[TicoM1]

This is what I have found for Insomnia:

End To End Encryption (E2EE)

Insomnia supports end to end encryption (E2EE) which allows us to fully encrypt all data that we create and requires a passphrase in order to be decrypted.

This capability is turned on by default on every account of Insomnia.

With E2EE enabled, the data is encrypted on Insomnia’s servers as well, and nobody can access it but the legitimate owner (not even the Insomnia team).

I was not able to find anything similar for Postman.

I didn't want to worry about any of that. It's not feasibly safe for daily use of a couple of people. Just go with Insomnia. I switched due to the account force. Collections can just be imported from postman and you can pretty much just continue to work. Community is strong, so you quickly get into usage of variables etc. Plus I already have some extensions, that sound cool, that I want to play with.

[ilya-scale]

@TicoM1 You are up for a surprise in Insomnia then, there is an account force in the latest version there as well :)

[sskop99]

Postman needs to add some kind of feature where the collections can be prevented from going public and even in that case, credentials and secrets must not be visible but just the documentation, explicit permission needs to be taken from user for making credentials public. This is a basic feature and is missing from postman.

For that matter, any action related to variables and credentials must be double confirmed jsut in case. Just adding a separate variable type isn't just enough, accidents can happen and prevention must be in place always. Reality is different unfortunately.

[DannyDainton]

With V11 of Postman, we have introduced the Postman Vault (https://learning.postman.com/docs/sending-requests/postman-vault/postman-vault-secrets/), which allows you to store your sensitive data in an encrypted local vault that is not synced with the Postman Cloud. Also, we have added multiple security features to help prevent accidental exposure of your API credentials.

This blog was also published last week and sets out the direction we are taking to safeguard our users sensitive data within elements that they have explicitly made public.

https://blog.postman.com/public-api-network-security-updates-secret-protection-policy/

[TicoM1]

@TicoM1 You are up for a surprise in Insomnia then, there is an account force in the latest version there as well :)

Yeah :( A few days after I wrote that I switched again. Fortunately there are tons of alternatives, that all offer importing.