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

 Replying to [comment:6 cas]:
 > Replying to [comment:5 muks]:
 > > Replying to [comment:2 muks]:
 > > > We'd have to store `~/.bind10/default_user.csv` in cleartext, or
 something that can be converted back to clear text on the client-side to
 answer the server for HTTP digest authentication.
 >
 > This design decision is what I'm challenging. In my view, every protocol
 that requires that the password can be converted back to clear text on the
 client-side to answer the server is not a good security protocol. If HTTP
 digest authentication demands that, then HTTP digest authentication might
 not be the best choice.

 In this context, the unencrypted password is the secret key.

 Even in the context of public-key authentication, the private key has to
 be deciphered on the client side (if it is stored encrypted)
 before use. This happens both during SSH authentication (typically using
 an agent process which manages the clear key), and during SSL
 client-authentication if a client certificate is used.

 Not storing the password is a reasonable point here. This is something
 that we should discuss.

 Whether we should do SSL client authentication (equivalent to the SSH
 authentication mechanism that you have mentioned) is another point that
 we can discuss. In this case, by the comments above, the client
 certificate would have to be stored encrypted and we should not save its
 passphrase anywhere.

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