Bill Sommerfeld wrote: > my apologies for taking so long to get back to this. > > On Tue, 2007-07-31 at 23:35 -0700, Alan Wright wrote: > > To be consistent with the guidance given in the PSARC/2007/177 > > opinion, that software packages must not permit operation using > > placeholder sensitive values, the default password is an empty > > string and the NDMP service will not accept client connections > > if the password is an empty string. In order to initiate NDMP > > protocol services, a non-empty password is required, which would > > typically be set using the ndmpadm(1M) command. > > > > The team acknowledges concerns expressed with respect to NDMP > > protocol security but the protocol is external to this case, > > and, as the project is only delivering an NDMP server, there > > is no scope to influence the negotiated client-server security > > implementation. From the same email discussion mentioned above, > > the way forward seemed to be to write an opinion and try to > > progress the protocol security concerns with the appropriate > > standards groups. > > There's a missing piece here. The opinion for 2007/177 says that the > facilities it provides are not sufficient on their own to comply with > the existing Security SWG Policy for storing sensitive data in the > filesystem. > > The Policy is at: > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > > or externally at: > > http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/ > > It may be used but should be augmented with additional obfuscation or > encryption. If you need the cleartext value of the secret to > authenticate, you'll need to use a reversable encryption or obfuscation > mechanism. It's worth noting that a really lame obfuscation mechanism > meets the letter of the policy, but directly storing the sensitive value > does not. > > It's also worth noting that there is much existing practice which > doesn't meet this standard, but there are also new mechanisms available > that weren't there when much of that prior art landed in Solaris.
If that is a requirement, we will use an existing reversible encryption on the plain text before it is stored. > In particular, the cryptographic framework also provides mechanisms for > storing sensitive values which have substantially improved security on > systems which include hardware keystores. (and it's worth noting that > CRAM-MD5 is (just barely) a cryptographic protocol). The CRAM-MD5 hash is an over-the-wire authentication token, generated at runtime using a randomly generated, per connection challenge key and the plain text password. CRAM-MD5 is defined in the NDMP protocol specification (i.e. we have no other choice: the options are plaintext or CRAM-MD5) and is never stored. Alan
