[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: Cifratura disco per NIS2



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


Reply to: