Paride Desimone ha scritto: > Fermo restando però che sono in completo disaccordo sulla frequenza > di cambio delle password.
il NIST ha appena rilasciato delle linee guida[¹] che demoliscono la pazzia che ha preso tutti gli enti che emettono linee guida o standard di sicurezza. Da quel che ho capito queste poi diverranno obbligatorie per tutte le pubbliche amministrazioni USA. Però manca la regola assurda di non riusare la stessa password o parte di essa usata nelle 4-5 volte precedente (sulla parte numerica spesso viene fatto il controllo che quel numero non sia presente, cioè se usi 5, allora le password successive non possono contenere 5! anche se scrivi 100594!). Ok, se non devi cambiare spesso password, ma cambiarla solo in casi "estremi", allora la regola di non usare la stessa password usata nelle 4-5 volte precedenti ci può stare, ma non quella di porzioni di password, come nell'esempio fatto sopra. Visto che il NIST è quasi sempre preso come base da cui emettere ogni linea guida e standard di sicurezza, probabilmente fra un po' arriveranno anche da noi. Schneier ne ha fatto un riassunto[²] che riporto qui: Nota: CSP = credential service providers 1 Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length. 2 Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters. 3 Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords. 4 Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a signgle character when evaluating password length. 5 Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords. 6 Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. 7 Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant. 8 Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords. 9 Verifiers SHALL verify the entire submitted password (i.e., not truncate it). Ho visto che molti criticano il punto 5, ma in realtà si permette con gli altri punti di usare un set di caratteri più vasto. Inoltre per ottenere quel risultato molti usano la stessa strategia che invalida tale richiesta per password "forti" (esempio sostituire la A con 4, la c con ç, far iniziare la password in maiuscolo, ...). Altri invece usano la stessa combinazione finale che racchiude i caratteri richiesti. Inoltre visto che il NIST consiglia l'uso di password generate da "portachiavi" personali, si avrebbe che queste regole potrebbero rendere invalide la maggior parte di queste password. Interessante il confronto tra queste due password: "Runner678!" e "kbndvueepu" la prima ha un'entropia di 20 bit, ma potrebbe soddisfare i criteri di uso di caratteri diversi, mentre la seconda ha un'entropia di 47 bit. Per chi vuole una striscia di xkcd su questo argomento: https://xkcd.com/936/ Ciao Davide [¹] https://pages.nist.gov/800-63-4/sp800-63b.html https://www.auditboard.com/blog/nist-password-guidelines/ [²] https://www.schneier.com/blog/archives/2024/09/nist-recommends-some-common-sense-password-rules.html -- La mia privacy non è affar tuo https://noyb.eu/it - You do not have my permission to use this email to train an AI - If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to training your model and all the source of the program that use that model
