Storing Reusable Passwords on a Filesystem

Storing Reusable Passwords on a Filesystem

Copyright 1991-2007, Sun Microsystems, Inc

Policy Synopsis

Reusable passwords must not be stored on a filesystem without sufficient protection.

Contents

• Applicability
• Audience
• Background
• Policy
• Advice
• Implementation
• Conformance
• Exemptions
• References
• InitialCosts
• OngoingCosts

Overview

Applicability

 All software produced by SMI

 All programs that store, on a filesystem, a password, passphrase or other string used to authenticate a principal or authorize an action.

 This policy applies to all such programs delivered by Sun. For those programs where Sun does not control the interface, Sun should, to the extent possible, work with the interface owner to determine if the security risks created by this condition can be further reduced.

Audience

ARCs, Project Teams 

Background

Policy

• Applies to This policy must be implemented in all major releases of Sun software products, and should be incorporated in minor releases when possible.
• Authority SAC
• Effective All projects exiting PLC Phase 3 on or after 2004/03/01
• Policy 
   Reusable passwords must not be stored on a filesystem without sufficient protection.
• Details

  Programs that require a reusable password should attempt to obtain this information directly from a principal or indirectly from a principal's security credentials.

  If a program must store a principal's reusable password on a filesystem in order to automate future authentication attempts, then the program must place the password in a file which is readable only to the principal whose password is stored in the file. The permissions of the file should grant no access to either group or world.

  Further, it is recommended that the actual reusable password should be stored on the filesystem in either an encrypted or obfuscated format in order to help prevent against accidental disclosure. While obfuscating the password will not protect the information against a targeted attack, it will help mitigate the risk of accidental disclosure (e.g., due to a system administrator using 'grep' on the directory in which the file is located).

  In the case where a single program must store and protect a variety of reusable passwords, consider the use of a master passphrase that is used by the program to encrypt and decrypt the password store. After a principal has provided this master passphrase, the password store can be decrypted and used while the session remains active or until a pre-defined, configurable time interval expires at which point the principal must re-enter the master password to continue the use of the passwords. If using a master password, remember that the master password must never be stored on the filesystem in any form.

  Project teams are cautioned that the standard file access controls are often insufficient to protect the confidentiality and integrity of stored passwords if the filesystem on which the passwords are stored is shared over the network (using NFS, Samba, etc.) as these protocols do not provide, by default, strong authentication, integrity protection or encryption.

  In this case, project teams should consider the use of non-shared filesystems for the storage of this password material. For example, a local directory such as:

  /var/security/cred/
        or
  /var/security/user/ 

  (owned by  with default permissions of 0600) could be used to store files containing such password information. The security benefits gained by this approach must be weighed against any compatibility and consistency issues as well as the impact (if any) to the principal. A compromise between security and compatibility, for example, would allow the use of the local password store if it exists otherwise the program will use the default password storage location (that could be on a shared filesystem). This allows customers to choose between security and convenience based on their own risk/threat assessment.

  A variation of this approach stores the key material, used to encrypt and decrypt ("wrap") the reusable password, on a single system's local filesystem even when the encrypted reusable password must be stored on a shared filesystem. This wrapping key is protected by being only available to a specific principal on a specific system even when the wrapped reusable password is more widely available.

  If shared filesystems must be used, then project teams must supplement their product documentation with information outlining the risks to this information as well as additional controls that a site could implement to mitigate some or all of these risks, such as the use of local key stores (as discussed above) or Kerberized NFS to provide strong authentication, integrity protection and encryption for NFS shares.

  Note that the security credentials described above are not specific to any one authentication mechanism. The credentials used will be specific to the entity being accessed.

Advice

 The storage of reusable passwords on a filesystem can create a number of significant security risks, such as:

 If the shared filesystem is not adequately configured for security (e.g. not using Kerberized NFS), it is possible for an unauthorized principal to access the filesystem and its contents, exposing the reusable password to disclosure and possible modification.

 As the theft of reusable passwords is hard to detect, the compromise may be compounded since it may go unnoticed resulting in an attacker's continued ability to repeatedly use the stolen credentials.

 Note that in this case the unauthorized principal need not have compromised the remote system to be able to implement this kind of attack. See references [3] and [4] for more information. For example:

• $HOME/.netrc used by the FTP client must not be readable or writable by anyone but its owner. If this is not the case for a particular user, the FTP program (1) does not use the file's contents for authentication and (2) provides a warning to the user. While this approach provides moderate security when used on a local filesystem, depending on how the filesystem is shared, the contents of the file may still be vulnerable.

 If the program requiring the reusable password does not check the file ownership and permissions of the object and warn if they are not adequately secured, it is possible that an administrative or user error may inadvertently give read and/or write access to the file containing the reusable password. In this case, the administrator or user may not even be advised of the risk. Given user's tendencies to reuse a limited set of passwords across a wide range of services, this could lead to a catastrophic breach of many services and functions.

 For this reason, programs must, by default, require files containing reusable passwords to be readable only by the principal associated with the password - if this capability is supported by the language in which the program is written or in the environment in which the program is run.

 For example, for UNIX-based C programs, this means having the file be owned by the principal and having UNIX permissions 400 or 600.

 If required, project teams can make this setting configurable, but they must provide adequate documentation warning the principal or administrator of the security risks associated with changing the default.

 Although not appropriate in all instances, programs accessing password, authentication or other security relevant information should consider first verifying that the file has ownership, group membership and permissions that are set to be within some predefined tolerance.

 Finally, it is recommended that the functionality granted to a principal through the use of a reusable password be as granular as possible so that in the event of a compromise, the damage can be contained. A compromise of a principal's password should ideally not compromise all of the functions available to that principal. This may not be possible in all situations however.

 For example, rather than having coarse-grained privileges such as only "user" and "administrator", consider more granular privileges such as those in the Trusted Solaris OS. Each privilege could then be assigned to a principal either individually or as a group. The damage caused by the compromise of a single password could then be better contained.

 This policy does not specifically address the security issues related to protecting files containing reusable passwords when stored on backup media. While topics related to storage and handling are outside of the scope of this policy, it is encouraged that these issues be described in the product documentation so that the customer is aware of these risks and can therefore take appropriate action (e.g., the use of encrypted backups, special handing procedures, etc.)

Implementation

This rule is to be applied by all Architecture Committees. 

Conformance

The project materials submitted for ARC approval must follow this policy. ARC approval will not be granted otherwise. 

Exemptions

 The only time the use of reusable passwords stored unprotected on the filesystem is allowed in Sun products is for either backward compatibility with previous minor releases of the same product or to comply with an external standard interface.

 In those cases of relating to standards compliance, the existing mechanism must be updated to comply with this policy.

 Note that exceptions to the compatibility requirements are often granted to address security holes so it is often possible and advisable to remove these in a minor release. This is particularly true if the expected use is in development, rather than deployment environments. At the recent Customer Advisory Council meeting that focused on security, customers indicated they would be willing to break backward compatibility if there were a solid security reason behind it.

References

 The following definitions apply to this policy statement.

1. Reusable Password. A password string that can be used successfully more than once. This differs from one time passwords, such as those generated by S/Key or OPIE in that they can be used successfully only once.
2. Principal. A unique entity. For example, a principal can be a user or a service.
3. NFSshell. ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz
4. RFC 2623. NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5. http://www.ietf.org/rfc/rfc2623.txt?number=2623

InitialCosts

 Minor. Required to remove the use of reusable passwords (if possible) from files used by the project or to implement additional security measures to better protect the reusable password.

OngoingCosts

None