HAPI Key Security

[gillytech]

As it stands the HubSpot API will accept the HAPI Key for all requests.

As a corollary this means that anyone who has the HAPI Key can do anything with the account. Such as:

• Export all contact information
• Send any email campaign
• Manage users
• Export and manage deals
• Etc.

There is no way to limit the power of the HAPI Key in HubSpot which is really a weak point. If the key is ever compromised, the portal is at extreme risk which can do irreparable damage to a company/brand.

What is needed is a more comprehensive security setup for HAPI keys. Yes, we can phase them out and move to OAuth, but seriously, the HAPI Key is used in so many integrations by now that it would be literally impossible to "phase out" at this point.

So, for the long run I am proposing:

• Create a way to maintain multiple keys and suspend/revoke their access
• Make it possible to limit them by IP
• Add an optional hashing mechanism for [sensitive] calls
• Add a way to fine tune any key's access to different APIs.

As an example, look at SparkPost's API key management:

I would also like to add that the key itself looks like a UUID v4 — not guaranteed to be cryptographically secure.

I think you would be better off using other recommended hashing methods to generate guaranteed unique and unguessable keys at least 128bits long. Just my own two cents.

[gillytech]

Hi Everyone, I'm very happy to announce that Private Apps is live! You can learn more here.

[gillytech]

Hey @gillytech , I reached out via email on 8/17 and 8/19, but hadn't heard back. If there's a better email address to contact you feel free to send me a PM. Thanks!

[gillytech]

Hi All! As @rad mentioned back in June, we've been working on a more secure alternative to HAPI Keys. We're about to launch a small Private Beta. If you're interested in participating, please complete the form below and someone from the HubSpot Product team will reach out over the next couple of weeks if you meet our beta participant criteria: 

Private Beta Form 

[gillytech]

Hey friends! We should have some updates quite soon on our plan to deprecate many of these risks associated with API keys & replace them with a better system. We're not quite ready to invite folks to try out our new system just yet, but we should have some exciting new things coming in the next few weeks & months to address this. When we do, I'll post an update on this thread!

[MarkdeLange]

Great idea, I agree the happykey is a weak spot from a security point of view. 

Another use case is where on a global account individual users may need to be restricted to accessing data via the happykey  to assets based on HS teams/brands. 

[hannuCR]

Yes, this is definitely a necessary feature, please implement this.

[gillytech]

SECURITY ADVISORY

As a supporting argument for better API security, and to deter unsuspecting HubSpot users from compromising the security of their accounts, I'd like to point something out.

I was on a site called emaillistverify.com. The site offers email verification services which isn't a bad thing. However, they offer a HubSpot "integration" which asks for your hapikey in order to connect. HubSpot offers a standard OAuth authentication structure for legitimate apps. You should NEVER give out your hapikey to any other company or individual on the internet. With this key anyone can do almost anything to your account with reckless abandon.

To the HubSpot engineers, please help us secure our HubSpot accounts! There needs to be granular access controls and multiple key management.

[RiccardoPisani]

+ 1 definitely needed - It is imo one of the most important things for a big company and a more structured HS account like the one we have. 

[Hani-RT]

Does this feature request also take into consideration the issue mentioned here? https://community.hubspot.com/t5/HubSpot-Ideas/Allow-more-than-one-active-API-key-at-a-time/idi-p/31...

[gillytech]

@Hani-RT Yes, I believe this implementation would cover the feature request you linked to, but in a slightly different way. With a more robust API key auth system such as what I mention above, you would be able to keep one key alive while you roll out a new key in parallel. When you're sure the old key is no longer being used (request logging per key would be good for making sure of that) then it could be deactivated.

HubSpot engineers: Please take note of this, there will be a breach sooner or later with your current (risky) hapikey setup and you want to have all bases covered before it happens. In the info security world, nothing happening ever is a good thing!

[Hani-RT]

Thanks for the reply, @gillytech!  That's fantastic.  🙂

[gbe]

This is very important for us, as GDRP compliance rely on building a 'registry of treatement' + 'inform in case of sensitive data breach'.

In this registry, we have to indicate who is allowed to export which subset of information.

Today, this means that each integration is allowed to export any sensitive data.

Even worse, we have no way to identify if any of them did export sensitive data, while there are legal delay to publicly disclose security breaches.

[alvinlzg]

This is a good idea. I am relatively new to HubSpot but we do use the API Keys for integration. OAuth seems to be a safer approach, but it also requires more effort. Some of the things we hope HubSpot would do is to allow the Admin account to have multiple keys instead of one account = one key and then share this key to other parties. It makes things worse when these keys allow the 3rd party to do everything.

Next thing you know, your API Key is too old and you're supposed to rotate them. So, who did I pass those keys to? Maybe I should rotate and see who comes back shouting at me? 🙂

[gillytech]

Guys I just saw the API log in the changelog and I am SO excited  Thanks for taking this into consideration and all your infosec minded customers will thank you!

I would like to suggest an improvement to the new API Call Log: please include the IP address of which machine made the call. This way we can see if there is any unauthorized usage right away.

[sambitc]

Having just one active key, makes the roation quiet hard in case if the keys are present inside the project. There will be a warranted downtime when u generate a new key and build and deploy the projects. So it is helpful if u add the support for temporarily accepting both old key and new key.

[mcraciun]

+1 This would be so helpful!!

[mlevin2]

Has there been any update to this? My use case is as follows:

• We are using CMS Hub for website content
• We want to use it "headless" (yes, I realize CMS Hub was not designed to be used this way – long story)
• We want to fetch page contents via API and render it in our own web app (not using CMS Hub to build the page, just getting the page as JSON)

There doesn't seem to be any concept of an API key with read-only access such that we could fetch the page client-side in our app without exposing a key with full access. Aside from fetching the content using the key server-side, does anyone have a suggestion for how to realize this use case?

Thanks

[gillytech]

@mlevin2 I don't think there's a way to do this. The HAPI key grants god-mode access to your HubSpot portal.

You could check out the OAuth-based authentication that's available. That gives you more granular access to the features of the API afaik.

[gillytech]

@rad Is there any update on the roadmap for this idea?

Also, quite interested in the calling IP address on the API Call Log. Any info would be appreciated.

[Guy_Dawson]

Being able to keep an old key active while a new key is being 'rotated in' is key to preventing integration downtime when rotating the API key.

We want to be able to:

• create a new key
• distribute the new key
• use the new key
• stop using the old key
• monitor any old key usage in the logs and resolve
• disable/delete the old key

With multiple systems and releases we don't expect to be able to switch every integration from the old key to the new key 'in an instant'. 

[DPolikoff]

I shouldn't be forced to hand over the "keys to the kingdom" to an external vendor of ours working with us on an integration project.

[PSMS]

@rad, you have put this into "in planning" status April 2020, can you give an update?

It there an expected timeline for delivering this feature?

Can we read up on what you folks are planning to implement?

Thanks

[rad]

Hey friends! We should have some updates quite soon on our plan to deprecate many of these risks associated with API keys & replace them with a better system. We're not quite ready to invite folks to try out our new system just yet, but we should have some exciting new things coming in the next few weeks & months to address this. When we do, I'll post an update on this thread!