Quando dovrebbe essere usato un codice password e quando dovrebbe essere usata una password normale? [duplicare]

Risposta breve

Dipende dal tuo "codice".

La regola

Se il codice restituisce uno spazio di ricerca grande quanto lo spazio di ricerca richiesto per la forza bruta, lo schema è efficace al 100%.

Esempio

Per spiegare questo, usiamo un esempio banale. Supponiamo che ci sia un sito Web molto povero che richiede una password alfabetica di quattro cifre.

Lo spazio per la ricerca di forza bruta è 26 ^ 4 = 456976.

Nel frattempo, ci sono solo circa 4000 parole di quattro lettere, quindi lo spazio di ricerca degli attacchi del dizionario predefinito è solo 4000. Molto male.

Ora diciamo che usi una trasformazione molto semplice: prendi ogni lettera e aggiungine una, così A diventa B, B diventa C, ecc. Per cercare il dizionario e questa semplice trasformazione, l'attaccante deve ora cercare uno spazio dei nomi contenente 8.000 voci. Questo è un po 'meglio.

Ora, l'attaccante non saprà che ne stai aggiungendo uno. Potrebbe sospettarlo. Ma potrebbe anche aver bisogno di controllare +2, -1 e -2. Quelle sono quattro trasformazioni per un totale di 16.000 sequenze. Ancora povero, ma meglio di 4.000.

Ora, probabilmente ci sono molte possibili trasformazioni che potresti fare nella tua testa. Sposta le tue mani una chiave a destra e tocca il tipo. Una chiave a sinistra. Digita la parola all'indietro. Scambiare vocali e consonanti Ecc, ecc. Se ci sono 100 trasformazioni, ora l'attaccante deve cercare 400.000 possibili sequenze. Ehi, questo sembra abbastanza buono.

A un certo punto l'attaccante ha intenzione di rinunciare alla ricerca di nuove trasformazioni perché porterà a uno spazio di ricerca superiore a quello richiesto per la forza bruta, 456976. Nel momento in cui ciò accade, il tuo schema è efficace al 100%.

Se vuoi davvero renderlo sicuro

Se vuoi davvero renderlo sicuro, presenta un segreto. Ad esempio, memorizzare una poesia, quindi mappare ogni lettera dell'alfabeto in una riga in quella poesia e sostituire la prima lettera della riga per ogni lettera. Se l'attaccante non conosce la poesia, avrà un tempo incredibile a scrivere un programma per indovinarlo. A meno che non legga la tua stessa letteratura, forse non lo capirà mai. Ora forse un hacker intelligente là fuori introdurrà un database di poesia nel suo algoritmo di ricerca, ma alla fine finirà per essere più costoso dal punto di vista computazionale di un semplice attacco di forza bruta.

Conclusione

Se il dizionario viene attaccato più costoso di un attacco di forza bruta, l'hacker utilizzerà un attacco di forza bruta. Questo è lo scenario migliore, dal momento che non c'è modo per un utente finale di mitigare la forza bruta attraverso la scelta della password.

Sembra improbabile che non sia stato chiesto qui prima, ma non ho trovato un buon duplicato.

I gestori di password, se combinati con password lunghe e generate casualmente, operano su un approccio che mi piace chiamare "metti tutte le uova in un paniere e custodisci bene quel cesto veramente ". La lunghezza e la casualità delle password proteggono dagli attacchi di forza bruta e dizionario e la casualità impedisce anche gli attacchi di condivisione delle password in cui un sito memorizza la password in modo non sicuro. Il vettore di attacco principale, ovviamente, è un utente malintenzionato che accede al database del gestore di password, a quel punto accede a ogni account dell'utente.

Se riesci a ricordare tutte queste password lunghe e generate in modo casuale, non ci sono database da violare e stai meglio. Tuttavia, molte persone non possono farlo.

In alternativa, puoi utilizzare un algoritmo per generare in modo riproducibile una password su richiesta per un sito (una serie di opzioni sono descritte in Qual è il tuo modo di creare password valide che possano essere effettivamente ricordate? ). Questi mantengono il vantaggio di non avere un database analizzabile. La questione, quindi, è se il vantaggio di evitare il database delle password superi o meno gli svantaggi derivanti dal passaggio da password generate casualmente a uno schema riproducibile.

Se lo schema è ovvio guardando un testo in chiaro (ad esempio siteName + accountName ), una violazione in un sito non sicuro apre l'intero set di account a qualsiasi utente malintenzionato che acceda alla tua password. Questo è ovviamente piuttosto terribile dal punto di vista della sicurezza. La maggior parte degli schemi non sono che ovvi, ma stai scommettendo sull'attaccante per non essere in grado di decodificarlo - se è una buona scommessa o meno è in discussione, e dipende dal tuo specifico schema pure. Vale la pena notare che le possibilità di un reverse engineering di successo si innalzano drasticamente quando un utente malintenzionato ottiene l'accesso a password in chiaro da più siti.

Un altro problema con schemi di password riproducibili è che non forniscono un modo semplice per cambiare la password per un sito - sono riproducibili e per generare una nuova password, è necessario integrare un'ulteriore informazione (alcuni sorta di "round"), che è necessario memorizzare o memorizzare.

Sia l'utilizzo del gestore delle password che gli schemi di password riproducibili sono dei downgrade di sicurezza dall'opzione di memorizzazione della password ideale. Inoltre sono entrambi molto meglio di quello che fa la maggior parte delle persone, ovvero utilizzare la stessa password insicura su molti account. Quale è "migliore" dipende molto dalle specifiche del tuo gestore di password e dallo schema con cui lo stai confrontando, e da quali attacchi sei preoccupato.

Risposta breve: cattivo consiglio.

Non farlo. Una singola password, recuperata da es. un hacking del database delle password che pubblicizzava la lista delle password, avrebbe immediatamente infranto la tua sicurezza. È assolutamente despicabile consigliare qualcosa di simile.

E anche senza di esso, un utente malintenzionato probabilmente farebbe entrambe le cose: un semplice attacco di dizionario basato su password comuni e un attacco di dizionario leggermente più avanzato basato su modifiche del nome utente, del nome del sito, della data di nascita dell'utente, ecc.

Would it be better to make strong passwords for every different website or to use a universal cipher, maybe a mixture of both somehow?

Ovviamente, sì. Una password casuale non ottiene alcun tipo di sicurezza diventando crittografata, quindi usa solo una fonte casuale di caratteri come generatore di password. Sotto linux, dd if=/dev/urandom bs=1 count=256|md5sum è un simpatico generatore di password (urandom fornisce esattamente le stesse cose di / dev / random) .