[
https://issues.apache.org/jira/browse/NIFI-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-5833:
--------------------------------
Description:
The {{GetTwitter}} processor marks properties {{Consumer Secret}} and {{Access
Token Secret}} as *sensitive*, but {{Consumer Key}} and {{Access Token}} are
not marked as such. The [Twitter API
documentation|https://developer.twitter.com/en/docs/basics/authentication/guides/securing-keys-and-tokens]
says:
{quote}
Your applications’ API keys should be guarded very closely. They represent your
unique access to the API and if leaked/used by other parties, this could lead
to abuse and restrictions placed on your application. *User access tokens are
even more sensitive*. When access tokens are generated, the user they represent
is trusting your application to keep them secure. If the security of both API
keys and user access tokens are compromised, your application would potentially
expose access to private information and account functionality.
{quote}
Once the processor code is updated to treat these properties as sensitive,
there may need to be backward-compatibility changes added to ensure that
existing flows and templates do not break when deployed on the "new" system
(following, marked as *1.X*). The following scenarios should be tested:
* 1.8.0 flow (unencrypted {{CK}} and {{AT}}) deployed on 1.X
* 1.8.0 template (unencrypted {{CK}} and {{AT}}) deployed on 1.X
* 1.X flow (encrypted {{CK}} and {{AT}}) deployed on 1.X
* 1.X template (no {{CK}} and {{AT}}) deployed on 1.X
The component documentation should also be appropriately updated to note that a
1.X flow (encrypted {{CK}} and {{AT}}) will not work (immediately) on a <=1.8.0
instance. Rather, manual intervention will be required to re-enter the
{{Consumer Key}} and {{Access Token}}, as the processor will attempt to use the
raw value {code} enc{ABCDEF...} {code} from the {{flow.xml.gz}} file as the
literal {{CK}} and {{AT}}.
was:
The {{GetTwitter}} processor marks properties {{Consumer Secret}} and {{Access
Token Secret}} as *sensitive*, but {{Consumer Key}} and {{Access Token}} are
not marked as such. The [Twitter API
documentation|https://developer.twitter.com/en/docs/basics/authentication/guides/securing-keys-and-tokens]
says:
{quote}
Your applications’ API keys should be guarded very closely. They represent your
unique access to the API and if leaked/used by other parties, this could lead
to abuse and restrictions placed on your application. *User access tokens are
even more sensitive*. When access tokens are generated, the user they represent
is trusting your application to keep them secure. If the security of both API
keys and user access tokens are compromised, your application would potentially
expose access to private information and account functionality.
{quote}
Once the processor code is updated to treat these properties as sensitive,
there may need to be backward-compatibility changes added to ensure that
existing flows and templates do not break when deployed on the "new" system
(following, marked as *1.X*). The following scenarios should be tested:
* 1.8.0 flow (unencrypted {{CK}} and {{AT}}) deployed on 1.X
* 1.8.0 template (unencrypted {{CK}} and {{AT}}) deployed on 1.X
* 1.X flow (encrypted {{CK}} and {{AT}}) deployed on 1.X
* 1.X template (no {{CK}} and {{AT}}) deployed on 1.X
The component documentation should also be appropriately updated to note that a
1.X flow (encrypted {{CK}} and {{AT}}) will not work (immediately) on a <=1.8.0
instance. Rather, manual intervention will be required to re-enter the
{{Consumer Key}} and {{Access Token}}, as the processor will attempt to use the
raw value {{enc{ABCDEF...}}} from the {{flow.xml.gz}} file as the literal
{{CK}} and {{AT}}.
> Treat Twitter tokens as sensitive values in GetTwitter
> ------------------------------------------------------
>
> Key: NIFI-5833
> URL: https://issues.apache.org/jira/browse/NIFI-5833
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: 1.8.0
> Reporter: Andy LoPresto
> Priority: Major
> Labels: api, key, properties, security, sensitive, token, twitter
>
> The {{GetTwitter}} processor marks properties {{Consumer Secret}} and
> {{Access Token Secret}} as *sensitive*, but {{Consumer Key}} and {{Access
> Token}} are not marked as such. The [Twitter API
> documentation|https://developer.twitter.com/en/docs/basics/authentication/guides/securing-keys-and-tokens]
> says:
> {quote}
> Your applications’ API keys should be guarded very closely. They represent
> your unique access to the API and if leaked/used by other parties, this could
> lead to abuse and restrictions placed on your application. *User access
> tokens are even more sensitive*. When access tokens are generated, the user
> they represent is trusting your application to keep them secure. If the
> security of both API keys and user access tokens are compromised, your
> application would potentially expose access to private information and
> account functionality.
> {quote}
> Once the processor code is updated to treat these properties as sensitive,
> there may need to be backward-compatibility changes added to ensure that
> existing flows and templates do not break when deployed on the "new" system
> (following, marked as *1.X*). The following scenarios should be tested:
> * 1.8.0 flow (unencrypted {{CK}} and {{AT}}) deployed on 1.X
> * 1.8.0 template (unencrypted {{CK}} and {{AT}}) deployed on 1.X
> * 1.X flow (encrypted {{CK}} and {{AT}}) deployed on 1.X
> * 1.X template (no {{CK}} and {{AT}}) deployed on 1.X
> The component documentation should also be appropriately updated to note that
> a 1.X flow (encrypted {{CK}} and {{AT}}) will not work (immediately) on a
> <=1.8.0 instance. Rather, manual intervention will be required to re-enter
> the {{Consumer Key}} and {{Access Token}}, as the processor will attempt to
> use the raw value {code} enc{ABCDEF...} {code} from the {{flow.xml.gz}} file
> as the literal {{CK}} and {{AT}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
