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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)