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. 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). - Bill
