Dear PTLs and committers, In connection to today presentation @PTL call I'd like to kindly ask you to review your projects answer to below CII badging questions (* badge level, + question). I'd like also to ask you to revise your answers and be more conservative with issuing N/A answers. It would be very helpful if you could provide some rationale why you think this question is not applicable to your project.
* Passing + No Leaked Credentials Question: The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access. Details: A project MAY leak "sample" credentials for testing and unimportant databases, as long as they are not intended to limit public access. My Comment: ONAP currently leaks almost all credentials in OOM Charts. It's OK to leak credentials for test account etc as long as they are well documented and not deployed by default. Taking into account that ONAP may be deployed on public cloud almost all passwords as important (yes, even for services that are not exposed outside of the cluster as this is a second tier of protection). + Crypto password storage Question: 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.) Details: 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. My Comment: User password should never be stored in plain text or any reversible form. Encryption is a reversible form of protection and it should not be used for passwords. If your service stores passwords as plain text or encrypted you should answer No to this question. + Crypto Working Question: The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are inappropriate to the context, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol. (N/A allowed.) Details: ECB mode is almost never appropriate because it reveals identical blocks within the ciphertext as demonstrated by the ECB penguin, and CTR mode is often inappropriate because it does not perform authentication and causes duplicates if the input state is repeated. In many cases it's best to choose a block cipher algorithm mode designed to combine secrecy and authentication, e.g., Galois/Counter Mode (GCM) and EAX. Projects MAY allow users to enable broken mechanisms (e.g., during configuration) where necessary for compatibility, but then users know they're doing it. My comment: This question is about using cryptography in a correct way. If you encrypt password instead of hashing them you say no. If you encrypt user cookie instead of just signing them, most likely you should also say no. * Silver + Input Validation Question: The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a *whitelist*), and reject invalid inputs, if there are any restrictions on the data at all My Comment: If you don't escape all fields for SQL Injections or XSS then you don't meet this criteria. + Crypto Used Network (Suggested in Silver, Mandatory in Gold) Question: The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select "not applicable" (N/A) My comment: If you expose any HTTP endpoint or communicate with other service using http instead of https you don't meet this criteria. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4961): https://lists.onap.org/g/onap-tsc/message/4961 Mute This Topic: https://lists.onap.org/mt/31610104/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
