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

ASF GitHub Bot commented on NIFI-5833:
--------------------------------------

Github user joewitt commented on the issue:

    https://github.com/apache/nifi/pull/3180
  
    actually looks like the todo may be legit to hang around in  general and 
isn't specific to this twitter scenario so will leave that alone.  given kojis 
review and comments and mine am +1 will merge to master


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

Reply via email to