Password policies inadeguate - NIST SP800-63b

Le password policies di SPiD sono insicure ed inadeguate ai moderni standard.

esempi:

  • Forzare il cambio password dopo X tempo:
  1. apre a possibile phishing attack verso gli utenti ingannandoli con finti rinnovi
  2. non è più sicuro, se ci sono password compromesse bisogna bloccare gli account e fare un reset.
  3. Incentiva gli utenti ad utilizzare password sequenziali
  4. E’ frustrante sopratutto perchè inutile
  5. E’ costoso da gestire in termini di supporto tecnico e software

Altri esempi da un provider italiano:

  • Upper limit di soli 20 caratter :frowning:
  • Massimo 2 caratteri identici consecutivi :frowning:
  • Non deve contenere un carattere specifico :cry:
  • Non può essere già stata utilizzata :sob:

Vorrei sapere qual’è il forum/internet space dove si possono discutere le specifiche di SPiD e le policies con gli sviluppatori?

Se gli sviluppatori non sanno cosa fare possono copiare la base minima indicata in NIST sp800-63b?

5 Mi Piace

Non concordo sulle valutazioni dei singoli punti, ma concordo sullo spirito: “P@ssw0rd” (anche senza virgolette) andrebbe bene al provider, secondo le richieste minime.
Credo che il forum potrebbe essere un luogo nel quale riflettere se un livello minimo comune, come il NIST, sia opportuno che si materializzi in una funzionalità o in una linea guida destinate a tutti.

Ciao Cristiano, credo che dovresti leggere la SP che ho condiviso. Abbiamo inserito i punti sopra nella sezione 5.1.1.2 più di un anno fa ormai e sono ben realizzati dalla maggior parte degli iDP nel mondo occidentale.

Non capisco come tu possa non condividere i punti che sono documentati in letteratura ma asserire di voler seguire le line guida del NIST. I due statement sono in conflitto.

Non mi occupo più di tanto di SPID. Comunque immagino che ogni IP possa adottare le sue regole, purchè non in contrasto con quelle Agid

vedi capitolo E.4.1. Livello 1 SPID

Concordo completamente.
Bisognerebbe che le linee guida AGID incorporassero in qualche modo le linee guida NIST in materia di password.

È proprio lì che vengono definite le norme insensate che citava Tom. Cito:

E.4.1. Livello 1 SPID

Per il livello 1 SPID (corrispondente al LoA2 dell’ISO-IEC 29115) l’Identity Provider
fornirà al Richiedente una credenziale a singolo fattore costituita da una password.
In particolare, per garantire di ottenere password complesse e difficilmente attaccabili,
verranno imposti i seguenti vincoli:
a) lunghezza minima di 8 caratteri;
b) lunghezza massima di 16 caratteri;
c) inclusione di almeno un carattere minuscolo e uno maiuscolo;
d) inclusione di almeno un carattere numerico;
e) inclusione di almeno un carattere speciali ad es #, $,% ecc.
f) impossibilità di inclusione di più di due caratteri identici consecutivi.
g) divieto di utilizzo di formati comuni (ad es. codice fiscale, patente auto, sigle
documenti, date, includere nomi, account-Id ecc.).

Secondo quelle regole, bisogna usare Tr0ub4dor&3.

Non condividere le faccine non è in conflitto con il suggerimento di seguire anche le linee NIST. Immagino che ci sia stata un’incomprensione.
Secondo me è opportuno, ulteriormente, prendere atto dell’esistenza e sviluppare strategie per misurare la qualità del prodotto “password”: sia come contributo a dizionari di attacco, sia verificando che non siano già state estratte da attacchi noti.
Per consentire a tutti di farlo: vedete difficoltà a rendere disponibili dei generatori di password che verifichino queste due condizioni? O, facendo un passo indietro, pubblicizzare l’esistenza di generatori e di verificatori di qualità della password in un riquadro sulla pagina di impostazione della password?
Credo che bisogna puntare sull’insegnamento: creare e memorizzare una password deve richiedere “energia”; termine che uso in senso largo per misurare l’importanza che il prodotto “password” ha nel proteggere i dati che gli affidiamo.

@Cristiano_Passerini I generatori di password TOTP ora in servizio presso ai vari gestori di spid non sarebbero conformi all’ultima variante delle normative NIST introdotte recentemente, dove tutti i servizi devono diventare passwordless con transazioni di chiavi pubblico-private. Operativamente per stare dentro alle specifiche NIST dovremmo strutturare tutti i servizi in configurazione SPID livello 3 con certificati, altrimenti non siamo conformi(e la questione niente scadenza password non funge). Le normative italiane e americane, nella configurazione attuale, sono talmente differenti che dubito potremmo configurare i servizi lato spid in una maniera fruibile dal cittadino imponendo i livelli statunitensi(io ci metterei la firma ma dubito il pensionato medio apprezzerebbe la complessità aggiunta da ciò).

@matteosaitta Se non capisco male, credo che nella riflessione che fai sia necessario scomporre due fattori. Un fattore è quello del livello di sicurezza che è richiesto dall’autenticatore; un altro fattore è il livello di sicurezza dello strumento di autenticazione.
La password, in sé non è bandita dal NIST63B. Pensare che sia opportuno che il servizio SPID sia AAL3 è ragionevole. Per contro, non sottoscrivo un approccio che suggerisca che poiché SPID non può essere agevolmente trasportato a livello AAL3 allora non è interessante concentrarsi sull’importanza di guidare alla scelta password sicure.
Perché le password servono anche se non si usa SPID. Per me è un dovere della PA suggerire pratiche digitali corrette ed in questo senso andrebbe la normazione delle motivazioni di rigetto di password per SPID.
Ad esempio: la raccomandazione di segnalare il motivo per cui una password è stata rifiutata è una prassi importante, perché incentiva la riflessione delle persone.

Quello a cui facevo riferimento è EO 14028 del 2021, il quale richiede in maniera esplicita MFA, preferibilmente via passwordless. Una volta delineato che bisogna sempre usare mfa via vettori sicuri(AKA FIDO2 o CEC), la password può essere anche pippo123 perpetuamente e rimanere sicura.
Anche le attuali normative europee delineano uno scenario simile(ma ahimè non uguale) dove una volta gestita la transazione via token hardware non vi è più il vincolo di cambio password, ma non menzionano direttamente tecnologie come fido. Motivo per il quale indico che nist è un suggerimento ma non la norma da seguire, le direttive di bruxelles sono sempre indietro di due o tre anni rispetto agli aggiornamenti degli standard nist.