Audit modelPassword security
Evaluation of the security of passwords according to the CNIL standard
1. General recommendation
1.1. If the treatment involves specific risks, are additional appropriate measures planned?
1.2. Are additional measures planned for categories of users at risk (such as IT administrators)?
2. Governance
2.1. Has a password management policy been formalized and validated?
2.2. Are staff accesses reviewed at least once a year?
2.3. Is the effective application of the password management policy verified at least once a year?
2.4. Is the password management policy, particularly its technical measures, reviewed at least annually to assess the need for updating?
2.5. Are the relevant parts of the password management policy made available to data subjects?
2.6. Have all staff been trained or made aware of how to manage their passwords?
2.7. Is a password manager offered to staff?
2.8. Do all the cryptographic mechanisms implemented respect the rules and recommendations described in annexes B1 and B2 of the RGS or the ANSSI cryptographic mechanisms guide?
2.9. Do the software and software components used implement up-to-date versions with respect to security?
2.10. Is a watch on published updates and vulnerabilities implemented for all software and software components used?
2.11. If private keys are used, are they stored securely?
2.12. Are there no clear or hashed passwords in the URLs?
2.13. If the authentication is done on a web page, does this page not contain any advertisement or call to third party sites?
1. Authentication server
1.1. Is the authentication page secured by the TLS protocol in a way that complies with the recommendations of the ANSSI in its security recommendations for TLS?
The recommendations are available here (in French) : https://www.ssi.gouv.fr/guide/recommandations-de-securite-relatives-a-tls/
1.2. Is the identity of the authentication server securely controlled, for example by a security certificate?
1.3. Is the communication between the client and the authentication server encrypted?
3. Choice of PMP (Password management platform)
3.1. In the case where users have the freedom to choose non-random passwords, have the risks to individuals of identity theft been identified?
3.2. If the risks to individuals established in the previous question are not negligible, does the policy implemented require (very) long passwords rather than complex ones?
3.3. If the risks to people established in question 1 of this section are, at least, significant, are additional measures implemented (e.g., entropy increase, 2FA, etc.)?
3.4. If the password is to be used for processing that is sensitive to password abuse (including processing that is accessible via the Internet), is there a maximum possible size for the password?
3.5. If they are not unlock codes, is the maximum size defined greater than 50 characters?
3.6. Are the most common passwords prohibited?
3.7. Is the comparison with the most common passwords case-insensitive?
3.8. Has the use case and target audience been considered in the selection of criteria to be imposed in the password management policy?
3.9. Does the password policy offer users a password policy that matches one of the cases in the recommendation or a higher level?
1. Password policy case
1.1. Case 1: Does the policy correspond to a level of 80 bits or more?
1.2. Case 1: Have special measures been taken to help users achieve the security level (e.g. password strength visualization tool)?
1.3. Case 2: Does the policy correspond to a level of 50 bits or more?
1.4. Case 2: Is a mechanism implemented to guard against automated and intensive attempt submissions?
1.5. Case 2: Has the impact of the unavailability of their account on the users considered been assessed as limited or negligible?
1.6. Case 3: Is the password policy equivalent to or greater than 13 bits?
1.7. Case 3: Does the authentication concern an individual's own equipment?
1.8. Case 3: Is the number of authentication attempts limited to (at most) 3?
4. General practicalities
4.1. Are passwords hidden by default when entered?
4.2. When an authentication fails, does the error message give any information about the cause of the failure?
4.3. If there is a default password, is the user required to change it the first time they log in?
4.4. Is the user able to paste a password into the password field from the operating system clipboard?
4.5. For passwords sent by mail, are there any measures to detect their interception or prevent their use?
4.6. For all other channels, are no passwords transmitted in clear text to the user?
4.7. Are all passwords provided to the user either temporary or one-time use?
5. Create, change or renew a password
5.1. Do technical measures help the user to enter a strong password?
5.2. Are the conditions of password acceptability clearly displayed to the user in a way that the user can understand?
5.3. Are users guided through the password selection process to easily determine a strong, policy-compliant password?
5.4. If a non-compliant password is selected, is the rule that caused the password to be rejected clearly displayed to the user?
5.5. Is the user able to change his or her own password independently?
5.6. Aren't users required to change their passwords periodically?
5.7. Are privileged accounts required to change their passwords periodically?
5.8. When a reset is requested by the user, is only a message like "if an account exists, then an information is sent" displayed?
5.9. If the password renewal is done by sending a link or a token through another channel, is it done through a previously validated channel?
5.10. Are newly added or modified communication channels excluded from these mailings?
5.11. Is the user systematically notified when communication channels are added, modified or deleted?
5.12. If a link or token is sent to the user, is it a one-time use link or token?
5.13. If a link or token is sent to the user, does this link or token have a maximum validity of 24 hours?
5.14. If a link or token is sent to the user, are previously sent links or tokens automatically revoked?
5.15. If renewal requires answering secret questions, is information that is usually public (parents' names, place of study, pets' names, etc.) excluded?
5.16. Are the answers to these secret questions stored in a different location from the password or encrypted?
5.17. Is the user systematically notified when these secret questions are added, modified or deleted?
6. Password storage
6.1. Are passwords never stored in clear text?
6.2. If a PAKE is implemented, is it a public and proven safe scheme?
6.3. As part of the authentication mechanism, are stored passwords kept in hashed form with a specialized function for storing passwords?
6.4. Does the chosen password storage function use at least one time cost configuration parameter, at least one memory cost configuration parameter and a salt?
6.5. Is the salt randomly generated and is it at least 128 bits?
6.6. Are the parameters reviewed at least once a year?
6.7. Is the choice of hash function re-evaluated at least once a year?
6.8. For password managers, are passwords stored encrypted with a public algorithm deemed secure (i.e. compliant with annexes B1 and B2 of the RGS)?
7. Compromise management
7.1. Are users systematically notified in case of a known or suspected compromise of their authentication means?
7.2. In the event of a proven or suspected compromise, is an assessment of the risk of account usurpation and its impact planned in order to decide on the need to temporarily block accounts or to reinforce user identification?
7.3. In the event of a proven or suspected compromise, is the user required to renew their password?
7.4. If additional information is used (case 3), does it have to be renewed in case of a proven or suspected compromise?
7.5. If secret questions are used, are they and their answers necessarily repeated in the event of a proven or suspected compromise?
8. Logging
8.1. Are successful authentications logged?
8.2. Are authentication failures logged?
8.3. Are the passwords used excluded from any logging?
8.4. Are unknown system identifiers excluded from logging?
9. Subcontractors and software publishers
9.1. Does the contract clearly state the scope of responsibilities?
9.2. Does the contract clearly state the security level of the system?
9.3. Is documentation covering all the points in these technical recommendations available to data controllers?
9.4. For software, does the documentation specify how passwords are generated, stored and transmitted?
9.5. Is the solution configurable to meet all of these technical recommendations?
9.6. Is the solution configured by default to meet all of these technical recommendations?
9.7. If hosting on behalf of a controller, are the logs regularly audited for suspicious behavior?
9.8. In the case of hosting on behalf of a controller, are actual or suspected compromises systematically notified to the controller?
Created at:01/01/2023
Updated on :09/16/2023
License : © Creative commons :
Attribution / Pas d'utilisation commerciale
CC-BY-NC
Attribution / Pas d'utilisation commerciale
CC-BY-NC
author :
Uses :4