Supponiamo che io ricordi una password master ad alta entropia e utilizzi varianti di essa per ciascuna delle mie password.
Ad esempio se ricordo tSaF4nWeACVkUU4 come password principale e uso tSaF4nWeACVkUU4t (con una t e la fine) come password Twitter e tSaF4nWeACVkUU4g (con una g alla fine) come password Google.
Questa è una cattiva pratica se è così quanta variazione dovrei inserire in diverse password.
Usi password distinte su sistemi distinti perché conosci che alcune di queste password potrebbero perdere. Se le tue password sono abbastanza alte nell'entropia, allora non colano attraverso la forza bruta, ma potrebbero comunque fuoriuscire attraverso altri modi, ad es. compromissione del server (cattura le password man mano che arrivano), keylogger (acquisisce la password mentre viene digitata), ... L'utilizzo di password distinte è una funzione contenimento dei danni . Per mantenere il server compromesso localmente quel server.
Se la password per il sito B può essere facilmente dedotta dalla password per il sito A, come nel metodo suggerito, non si riesce a contenere il danno. Che la password inizi con un'alta entropia non ha alcuna influenza su questa affermazione. L'alta entropia consiste nell'evitare una violazione attraverso la forza bruta (alias "attacco al dizionario"). Tuttavia, una volta che è avvenuto un altro tipo di violazione, l'entropia non è più rilevante. L'entropia è una misura di ciò che l'attaccante non sa . Se l'utente malintenzionato potrebbe afferrare la tua password, allora sa tutto e non c'è più alcuna entropia. Abbiamo superato quel passaggio.
Perché il contenimento dei danni funzioni, la conoscenza della tua password per il sito A non deve fornire alcuna informazione sulla tua password per il sito B - il che significa che entrambe le password devono essere generate casualmente e indipendentemente l'una dall'altra . In particolare, mentre ciò significa che non si dovrebbe fare alcuna "derivazione della password" come quella che si propone, non si dovrebbe rifiutare le password candidate per il sito B perché sarebbero "non abbastanza diverse" dalla password sul sito A: tale rifiuto la regola aiuterebbe anche un attaccante a limitare i suoi sforzi di forza bruta.
(È possibile applicare la derivazione della password basata su crittografia da una password di root, ma queste cose sono sottili e, in ogni caso, non sarai in grado di eseguirlo nella tua testa, il che vanifica il vantaggio dell'usabilità di avere una semplice regola di derivazione.)
In un mondo perfetto, sicuro che sarebbe un metodo meraviglioso per un umano ricordare le proprie password. Tuttavia, il mondo è ben lungi dall'essere perfetto.
Il problema principale con il tuo metodo è che se una sola delle tue password viene mai scoperta (attraverso perdite, ipotesi, violazioni, ecc.) l'intero apparato di sicurezza potrebbe districarsi - perché i modelli sono banali da rilevare.
Per rispondere alla tua domanda sulla variazione; dovresti avere password completamente diverse. So che questo può sembrare noioso da ricordare, ma considera l'utilizzo di una password sicura per contenere tutte le tue password individuali e ricorda semplicemente la tua (mai cambiata) password principale.
Questo fornisce quasi nessuna sicurezza aggiuntiva rispetto all'utilizzo della stessa password ovunque. L'intero punto di utilizzo di password multiple è quello di impedire che una perdita di uno possa compromettere più account.
Se ottengo la tua password su Twitter, la prima cosa che farò tentando di hackerarti su Google sarà provare le permutazioni della tua password twitter. Non ci vorrà molto per capire che sostituire t con g lo fa funzionare, infatti, probabilmente sarebbe la prima cosa che ho provato prima di provare le permutazioni casuali.
Se vuoi davvero sicurezza, ciascuna password dovrebbe essere completamente unica e non correlata alle altre tue password. In alternativa, puoi andare all'estremo opposto e impostare il più possibile su oAuth. Ciò lega tutto alle stesse credenziali, ma offre anche un solo servizio che può essere compromesso per ottenere la tua password e offre anche solo un posto dove è necessario cambiarli non appena viene rilevato il compromesso. Non è ancora abbastanza sicuro come avere un sacco di password completamente uniche, ma è molto più utilizzabile.
Il mio suggerimento è "no". Lo schema che hai suggerito è vulnerabile agli attacchi di forza bruta.
Utilizza invece un'applicazione di database delle password che viene trasferita ai dispositivi che utilizzi e puoi generare password complesse e riempirle automaticamente per te.
Poiché non sono d'accordo con la conclusione della maggior parte delle risposte, ho intenzione di rompere questo problema in un modo leggermente diverso. Prendiamo in considerazione un paio di violazioni ed esaminiamo quale sarebbe l'effetto di tale schema di password, tuttavia farò una piccola modifica al tuo schema (dato che il tuo schema attuale è semplicemente too semplice):
Eg if I remember tSaF4nWeACVkUU4 as a master password and use tSaF4nWeAtCVkUU4 (with a t in the middle) as my Twitter password and tSaF4nWeAgCVkUU4 (with a g in the middle) as my Google password.
Il database degli utenti è compromesso e la password con hash è compromessa. La password ha un'alta entropia, quindi non sarà rotta attraverso la forza bruta. Anche attaccare altri siti usando questa conoscenza è impossibile.
La versione in chiaro della password è compromessa. Ora è possibile eseguire una bruteforce semplice con circa 3 a 10 tentativi realisticamente su un altro sito prima di essere bloccato. Usando lo schema proposto questo sicuramente resisterà anche sotto un controllo relativamente ravvicinato. Recentemente ho osservato quanti siti utilizzano effettivamente timeout e blocchi account e risulta che molti siti non hanno né l'uno né l'altro. Senza protezioni di base come quella, un utente malintenzionato si troverà nella stessa situazione descritta di seguito con una sola password di testo semplice e più hash (sebbene la velocità di provare le password contro l'hash sia significativamente inferiore attraverso un servizio Web ).
Ora, questo schema diventa seriamente debole solo quando un attaccante è in grado di attaccare un certo numero di siti diversi e poi fare un attacco mirato contro di te. In questo caso, può cercare esplicitamente le differenze nella password e quindi capire il tuo schema. Una cosa simile è possibile se uno degli hack è semplicemente un hack del database, poiché può quindi cercare le permutazioni prima in un attacco di forza bruta contro l'hash ... che a sua volta porterà probabilmente alla scoperta del tuo schema.
In conclusione penso che l'uso di uno schema ben progettato che richiede che almeno 3 diverse istanze di password siano compromesse è sufficiente per molti usi. Solo nel caso in cui ti aspetti un attacco mirato, questo diventerà un problema. Ovviamente, l'utilizzo di password completamente diverse è decisamente più sicuro, utilizzando password completamente diverse e un gestore di password è leggermente più sicuro (a seconda del gestore di password e del modo in cui lo si utilizza), ma presenta notevoli vantaggi rispetto all'aver un gestore di password senza quasi tutte le insidie di avere un numero fisso di password diverse.
E a tutti coloro che sostengono che questo è così semplice, provatelo (e questa è anche una versione estremamente semplice con solo due variabili):
Ora, è chiaro che dovrebbe essere fattibile, dopotutto, sei stato in grado di hackerare tre siti diversi e lo schema non è quello complesso, ma se hai solo i primi due che non riuscirai a capire il terzo in tempo prima che Twitter ti blocchi. Se hai il primo e il terzo tu potresti trovare il secondo però, ma è per questo che ho ancora definito debole questa versione. In ogni caso, con tutte queste informazioni conosci un milione di volte più di quanto un hacker possa mai sapere ... così come tu, ragazzi, stai attaccando questo approccio, questa dovrebbe essere una passeggiata nel parco.
Either way, the answer is Hsx3e8(first letter - 1)[HS](if high security)TBT , now imagine mixing in categories or more complex letter schemes or anything else you like. For example, instead of the above three have a look at the plain text versions: GOpwYjbm2vX, GOp24WYjBmvX, gOpWY12jbmvY (that's even more complex than my own scheme though :P )
Come altri commenti dicono, il problema principale è la struttura troppo stretta tra password diverse.
Una soluzione migliore sarebbe applicare un metodo di hashing a questa "password + modifica" in modo che il risultato non possa restituire la tua password principale.
Questo è il principio base del link :
Il risultato è una password dall'aspetto casuale che non può restituire la password principale in quanto contiene troppi sali.
Lo svantaggio principale di questo metodo è che è molto vulnerabile ai keylogger se registrano l'intera sequenza e che usi una sequenza simile per tutte le tue password (con solo la modifica dell'URL del sito web).
Ad esempio, terrò la password principale fornita: tSaF4nWeACVkUU4 (che non mi piace perché non ci sono caratteri speciali).
Quindi scrivo che è per l'uso con il sito web "test.com", hash con "HMA-SHA-256", con il nome utente "test", con il modificatore "test" e una lunghezza di "10". Qualsiasi modifica di uno di questi parametri genererà una password completamente nuova (eccetto per la lunghezza che aggiunge o rimuove solo caratteri).
Tutto questo mi fornisce una nuova password: "FBaJZ +: 1 @ N" che non dice molto sulla sua password principale.
Se non hai esattamente tutti gli stessi parametri, l'algoritmo hash dovrebbe impedire di recuperare quelli mancanti.
Non sono un esperto di crittografia, potrei aver frainteso alcuni aspetti e posso commettere errori. Tutto questo messaggio è ciò che capisco, quindi non è la verità necessaria.
Ecco un framework che uso (YMMV) che si basa sul tipico approccio CISSP alle password (qualcosa che conosci, qualcosa che sei, qualcosa che hai). Rompendo la struttura della password in questi tre argomenti con la sostituzione dei caratteri. Attualmente non riutilizzerò mai la password, la mia password tipica è di circa 20 caratteri e posso sempre richiamarli:
Sostituzioni: (molto comune)
s = $
e = 3
o = 0
a = @
i = 1
Qualcosa che sono: (esempio)
human = hum@n
Qualcosa che ho: (esempio, accedo al mio account Gmail)
gmail - gm@1l
Qualcosa che so
mytelephone_number_with_shift_key = @!@%%%!@!@
La mia password per gmail potrebbe essere:
[email protected]@1l.@!@%%%!@!@
Per dove posso conservare qualcosa che conosco, qualcosa che sono e cambiare qualcosa che ho:
Qualcosa che ho: (accesso ora alla mia banca)
bank = b@nk
Questa sarebbe una ripartizione:
[email protected]@nk.@!@%%%!@!@ (bank password)
[email protected]@1l.@!@%%%!@!@ (gmail password)
[email protected].@!@%%%!@!@ (bank password)
Questo mi consente di mantenere sempre delle password forti, ricordandole sempre. Intendiamoci, c'è una minaccia che qualcuno possa capire la struttura tramite la registrazione della battitura, l'inferenza, è ancora molto strong nel suo design, più facile da ricordare rispetto alle sciocchezze generate. Mi aggiro lungo una struttura come questa e il modo in cui la vedo, se qualcuno sta attaccando questa metodologia, allora sono un avversario molto strong.
----- ADDED NOTE (modificato)
Forzare brutalmente la maggior parte delle mie password non funziona usando oclhashcat o John. La maggior parte sono troppo lunghi e richiederebbero mesi. Faccio un punto per cambiare la mia struttura delle password una volta ogni tre mesi. Ancora una volta, il tuo chilometraggio può variare, e ora posso vedere le risposte / i commenti: " Tutto quello che devo fare è capire una cosa " A cui rispondo: "se qualcuno riesce a capire qualcuna delle mie le password, un avversario strong che sono. Loro DESERVE di romperlo "
Leggi altre domande sui tag passwords