Github user alopresto commented on the pull request:

    https://github.com/apache/nifi/pull/267#issuecomment-216594397
  
    My recommendation would be a command line utility (could be a shell script 
wrapping a JAR) which is  invoked without arguments, provides a secure prompt 
for entering a raw password, and returns the hashed password in _bcrypt_ 
format. 
    
    I think the Java code necessary to read from the XML configuration file, 
accept a username and password entered in the UI form field, verify the 
credentials are correct, and return a JWT authentication token should remain. 
    
    The administrative functionality of the utility (reading and writing the 
XML file) does not seem necessary to me. 
    
    Again, I understand the desire for this from a proof-of-concept and 
quick-deploy mindset, but I'll reiterate my feeling that this lightweight 
option will become an accidental de facto default because it requires less 
effort to deploy than LDAP, Kerberos, or client certificate authentication. 
Currently, I believe those alternatives are all more robust and secure than 
this approach:
    
    - Each is a widely supported approach with many eyes on them, making 
discovery of vulnerabilities more likely
    - Each protects the knowledge of the end users' passwords from the 
administrator, unlike this approach
    - Each scales without the manual intervention of the administrator 
(authorization still requires manual intervention)
    
    I appreciate the effort to move away from anonymous access as the default 
for the application. However, I believe there should be a balance here, as the 
default is very clear that no authentication is performed. Administrators must 
make an intentional effort to secure the instance with LDAP, Kerberos, or 
client certificates, all of which I acknowledge have a higher cost of entry 
than simple username/password authentication from a file store. My fear is that 
as this method is the lowest cost, it will be explained (incompletely) on a 
random blog article, become the quickest route for admins to get it running 
without fully reading the documentation or knowing its limitations, and then be 
deployed to a production environment. 
    
    I understand these concerns are mostly intuitive and not examples I can 
point to with empirical evidence. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to