[ https://issues.apache.org/jira/browse/NIFI-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694818#comment-16694818 ]
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 <joew...@apache.org> > 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)