[ 
https://issues.apache.org/jira/browse/NIFI-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-5833:
------------------------------
       Resolution: Fixed
    Fix Version/s: 1.9.0
           Status: Resolved  (was: Patch Available)

> 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
>             Fix For: 1.9.0
>
>
> 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