BIND 10 #2716: password in ~/.bind10/default_user.csv is cleartext

[BIND 10 Development]

#2716: password in ~/.bind10/default_user.csv is cleartext
-------------------------------------+-------------------------------------
            Reporter:  cas           |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  Next-
           Component:  Unclassified  |  Sprint-Proposed
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by cas):

 Care should be taken when a security protocol designed for another purpose
 is taken and used in a different context.

 I'm not an expert in security protocols, it might be good to ask someone
 from the RIPE/IETF/DNS community with experience in designing security
 protocols to evaluate the BIND 10 authentication protocol.

 htdigest has been designed (to my knowledge) to store passwords server
 side (on webservers). In that original use case, if the evil doer gets
 access to the htdigest file, all he gains is access to the server (which
 he already must have to be able to access the file). The security breach
 is not getting worse because of access to the file.

 In the BIND 10 use case, the file would be not stored on a (usually
 protected and locked down) server, but on client machines (laptops,
 workstations, smartphones and tablets). Laptops get lost or get stolen.
 All kind of unauthorized people can have access, and even trojans could be
 used to harvest the file. The password will end up in backups etc.

 If my view the password should not be stored in the default configuration,
 instead the user should be asked for a password on login every time. That
 initial password should be used to negotiate a session password (session
 key or token) that is held in memory only to re-authenticate if necessary.

 Only if the user decides to keep the password around (and changes the
 configuration), it should be stored locally in a way that it is impossible
 to gain the original clear text password. It cannot be prevented that if
 some evil doer gains access to the stored password file, that this person
 can login to the BIND 10 server.

 But as administrators and users (despite better knowledge) re-use
 passwords in different systems, a non-reversible password hash would
 prevent the evil doer to take over other systems as well.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2716#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development