[
https://issues.apache.org/jira/browse/NIFI-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694816#comment-16694816
]
ASF subversion and git services commented on NIFI-5833:
-------------------------------------------------------
Commit f6b171d5f76aabf59c1e4644927ab6484be9839a in nifi's branch
refs/heads/master from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=f6b171d ]
NIFI-5833 This closes #3180. Marked GetTwitter Consumer Key and Access Token
processor properties as sensitive.
NIFI-5833 Added unit test to demonstrate arbitrary decryption of sensitive
values regardless of processor property sensitive status.
NIFI-5833 Updated GetTwitter documentation with note about 1.9.0+ marking
Consumer Key and Access Token as sensitive.
Signed-off-by: joewitt <[email protected]>
> 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
> Assignee: 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)
