[jira] [Commented] (NIFI-5833) Treat Twitter tokens as sensitive values in GetTwitter

["Joseph Witt (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693704#comment-16693704 ] 

Joseph Witt commented on NIFI-5833:
-----------------------------------

Andy - i believe old flows will work right away as they'll take the unprotected value in then encrypt it.  *i think*.  If not then we can flag in migration guide.

> 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)