opened
cmgrote
username_0
(This is required for lowest level **passing** for CII.)

If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt). (N/A allowed.)

This criterion applies only when the software is enforcing authentication of users using passwords, such as server-side web applications. It does not apply in cases where the software stores passwords for authenticating into other systems (e.g., the software implements a client for some other system), since at least parts of that software must have often access to the unhashed password.

This is a bare minimum today when storing passwords. Sometimes software needs to have a credential, such as a password, to authenticate it to other systems; those are intentionally out of scope for this criterion, because in many cases it's not possible to store them as iterated hashes using per-user salt.

(see: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md#crypto_password_storage)
[crypto_password_storage] store passwords securely
issue
created
cmgrote
username_0
Two pieces here:

1. I don't believe we store any passwords for our own authentication (other than for demo purposes): that is, we are relying on external providers like LDAP in production scenarios?  If so, then for the first point (`[crypto_password_storage]`) we simply have `N/A`.
1. For the second point, so long as we use the `EncryptedFileBasedServerConfigStoreConnector` we are using cryptographically secure random number generator (`java.security.SecureRandom`) and thereby meeting `[crypto_random]` requirement.
comment
closed
cmgrote
username_0
issue