pam_pwcheck memorizza solo le password per un determinato utente, come dice l'altra risposta.
L'altra parte della domanda è: "Quale potrebbe essere l'obiettivo di questo tipo di controllo?"
Esistono dei sistemi che controllano tutte le password esistenti. Generalmente tali sistemi memorizzano le password in testo semplice o un hash non salato che non dipende dal nome utente o da qualsiasi altra cosa che impedisca di trovare rapidamente una corrispondenza. Mi sono imbattuto in questo come utente, come una richiesta di funzionalità (che ho rifiutato come impossibile con qualsiasi ragionevole mezzo di memorizzazione della password, insieme ad essere intrinsecamente imperfetta come di seguito) o come obiezione a fissare l'uso di memorizzazione in testo normale.
E l'obiettivo è duplice:
-
Dato che le password dovrebbero essere difficili da indovinare, l'ideale sarebbe se fossero quasi casuali in termini di imprevedibilità (il problema di ricordare la password è un'altra cosa *, e spesso dimenticato quando le persone sviluppano un nuovo entusiasmo per la sicurezza della password). Dal momento che intuitivamente, casuale significa che c'è poco nel modo di ripetizione (qualcosa che qualcuno qui probabilmente saprà è un errore, ma certamente un errore che viene tenuto), quindi la ripetizione è quindi un brutto segno.
-
Più ragionevolmente, se qualcun altro sta utilizzando la password, probabilmente è una password debole che non siamo in grado di rilevare (ad esempio, utilizzando i dettagli di un ufficio aziendale come il numero di telefono per creare la password in modo che un'altra il dipendente potrebbe provare ma altrimenti supera i test di forza), che potrebbe essere indovinato, in quanto essenzialmente l'utente lo ha effettivamente indovinato.
I difetti con il primo pensiero sono il difetto di non comprendere la ripetizione in modo casuale e con l'aspettarsi una password perfettamente casuale, a meno che non sia supportato da una politica che permetta di ricordare con sicurezza la password difficile da ricordare.
I difetti con il secondo pensiero sono:
- Abbiamo bisogno di archiviare la password in modo relativamente insicuro per poter effettuare il controllo in primo luogo.
- Abbiamo appena fatto trapelare una password a qualcuno.
- Probabilmente abbiamo identificato una password debole, ma non abbiamo avvertito la persona che la sta effettivamente utilizzando.
Ma ancora, questi difetti non significano che non accada. C'è poi un altro difetto nel sistema nello scherzo; rifiutando carottegéante a causa del segno diacritico. Ci sono ragioni tecniche per rifiutare i segni diacritici in vari punti (sebbene a meno di non dover interagire con il codice di altre persone, queste ragioni sono assolutamente imperdonabili nel codice moderno), ma ho visto piuttosto bizzarramente rifiutato da sistemi che accetterebbero segni diacritici in nomi utente! Allo stesso modo molti sistemi rifiutano gli spazi nelle password e così via. In generale, lo metterei nella programmazione settoriale del carico; qualcun altro l'ha fatto, quindi lo copi. In una certa misura questo non è del tutto irragionevole; Certamente copio ciò che sanno quelli che sanno meglio di me quando si parla di sicurezza, quindi non incolperei del tutto qualcuno che copi ciecamente tali politiche. Tuttavia, ci vuole solo una breve pausa per rendersi conto che non c'è modo per accettare "jdiwmfojkslofklo" ma non accettare "כסּוּ ٺقد ӐӓҾӌȕ" migliora nulla, e in effetti riduce la gamma di possibili password da attaccare.
In ogni caso, la regola che alcuni sistemi hanno rispetto agli spazi ci fornisce un approccio per tradurre lo scherzo in inglese; fai in modo che la seconda password tenti di "carote giganti" con uno spazio.
* Ecco a cosa servono le note post-it, vero?
