Come ha notato John Deters, 2x8 è quasi certamente peggio, ma i motivi per cui è necessario spiegare un po '.

Ci sono stati un paio di problemi con gli hash LANMAN (il classico caso di spezzare una password a metà , andato storto):

• Poiché le password tendono ad essere generate dall'uomo e un po 'brevi, se una singola password fosse solo un po' più lunga della prima metà (diciamo, 8 caratteri), poi risolvere il secondo tempo richiederebbe drammaticamente meno tempo e potrebbe anche rivelare quello che probabilmente sarebbe stato il primo tempo

• LANMAN era proprio così maledetto veloce (che l'attaccante possa tentare, in operazioni di hash al secondo)

• LANMAN ha tagliato in due le password con una lunghezza sfortunata (7), che era abbastanza suscettibile al completo esaurimento (e anche di più sulle GPU moderne)

Tuttavia, la tua domanda è leggermente diversa dal caso LANMAN:

• Non afferma che le password 2x8 siano in realtà una singola password spezzata a metà (potrebbero essere indipendenti endently generato e random)
• Afferma esplicitamente che le due password sono di lunghezza 8 (piuttosto che, diciamo, una di lunghezza 8 e l'altra di lunghezza 1, il famoso caso peggiore di LANMAN)
• A meno che i tuoi sali non siano banalmente piccoli, costruire tabelle arcobaleno non sarebbe fattibile , che è lo scopo del salting (a differenza degli hash LANMAN, che erano completamente non salati)

Quindi è una domanda interessante, a cui si risponde in gran parte guardando la matematica associata.

Facciamo alcune ipotesi:

• Entrambi i Gli approcci 9x1 e 8x2 vengono salati e sottoposti a hash utilizzando le stesse lunghezze e algoritmi di sale

• Caso peggiore per l'attaccante: le password vengono generate casualmente dal set di caratteri ASCII stampabili (95 caratteri), con sali ragionevolmente lunghi. (La domanda sarebbe meno interessante se le password fossero generate dall'uomo, perché in pratica di solito cadrebbero sotto attacchi facili molto prima che l'aggressore debba ricorrere alla forza bruta)

• L'hardware e le velocità moderni sono un gioco leale

• L'algoritmo hash può o non può essere compatibile con il parallelismo

Considerato tutto quanto sopra, vorrei approssimativamente aspettatevi:

• L'hash 1x9 sarebbe esaurito al 100% nelle operazioni di hashing 95 ^ 9 (6.302 × 10 ^ 17) (che potrebbero essere parallelizzate bene o male).
• Gli hash 2x8 sarebbero esauriti al 100% in (95 ^ 8) x2 (1.326 × 10 ^ 16) operazioni di hashing (e indipendentemente dall'algoritmo, potrebbero essere facilmente parallelizzati in modo ingenuo semplicemente craccando ogni hash su un sistema diverso - ma spesso può essere parallelizzato in modo molto efficiente anche su un singolo sistema, a seconda dell'algoritmo).

In altre parole:

• Quel nono carattere aggiunge 95 volte il lavoro da esaurire e potrebbe essere difficile parallelizzare
• Tw o Le password di 8 caratteri raddoppiano solo la quantità di lavoro necessaria, e possono essere banalmente parallelizzate

Un altro modo di pensarci è che l'aggiunta di un carattere in più crea approssimativamente lo stesso lavoro di dover decifrare 95 password di otto caratteri ! (Se questo non è intuitivo, inizia con casi semplici confrontando casi più piccoli come 1x1 vs 1x2, finché non lo capisci).

Quindi, a parità di altre condizioni, 1x9 dovrebbe quasi sempre essere migliore di 2x8 .

E in realtà, questa non è solo una semplice illustrazione della potenza della parallelizzazione, ma dovrebbe anche rendere ovvio il motivo per cui consentire lunghezze di password più lunghe è così cruciale. Ogni carattere aggiuntivo nel modello precedente aggiunge 95 volte il lavoro allo spazio delle chiavi complessivo. Quindi l'aggiunta di due caratteri aggiunge 95 ^ 2 - o 9025 volte - il lavoro. La forza bruta diventa rapidamente irrealizzabile, anche per hash molto veloci e non salati.

Questo sarebbe un'ottima domanda per i compiti a casa. ;)

Partendo dal punto di vista matematico ... (per semplificare il calcolo presumo solo cifre di password)

Situazione A: 2 parti 8 cifre password, 'l'attacco bruteforce sulla prima parte richiede un massimo di 10 ^ 8 hash, lo stesso per la parte. Totale di max 2 * 10 ^ 8 hash richiesti "

Situazione B: 1 parte di password di 9 cifre," attacco bruteforce richiede max 10 ^ 9 hash "

La matematica dice che B è meglio di A

In poche parole

l'aggiunta di più password aumenta forza bruta di moltiplicazione di numero di parti (in questo scenario è 2x)

l'aggiunta di più cifre aumenta la forza bruta della potenza di numero di cifre (in questo lo scenario è x10 ^ 1)

Dividere la password è quasi certamente peggio. Consente di creare una tabella arcobaleno di otto caratteri. Ciò implica che tutte le password nel sistema saranno in 8 parti di caratteri. (Questo è esattamente il modo in cui sono state violate le password di NT LANMAN.) Nel tuo caso, sarebbero necessarie semplicemente due tabelle arcobaleno.

Il sistema di password a nove caratteri non ha alcun difetto visibile, il che implica che se si inserisse una password corretta di 14 caratteri, sarebbe stata salvata in modo sicuro come un unico hash.

Nessuna risposta significativa è possibile senza sapere qual è il tuo scenario di minaccia . Da cosa stai cercando di proteggerti? Sei preoccupato per la forza bruta o il cracking dell'hashish? Nel primo caso dobbiamo conoscere la tua procedura di login (es. Inserisco le password in sequenza o in parallelo?). Inoltre, se la tua procedura di accesso non mi blocca dopo migliaia o milioni di tentativi di accesso falliti, non funziona. Non è una questione di sicurezza della password.

E gli utenti che annotano le cose? Surf sulle spalle? Phishing? Qual è il modello dietro le password?

Esistono usi legittimi di due password, ad esempio una password di accesso in lettura e una password separata per l'abilitazione del cambiamento. Dubito che tu lo abbia in mente a causa della tua alternativa di password di 9 lettere, semplicemente buttandola là fuori per dimostrare che la realtà è più complicata di una domanda accademica sulla robustezza della password basata solo sulla lunghezza.

I sistemi di password implicano compromessi tra la sicurezza contro l'accesso illegittimo e la resistenza agli attacchi denial of service. Un potenziale vantaggio dei sistemi a password divisa è che le due metà del sistema possono applicare diversi compromessi. Ad esempio, la resilienza contro gli attacchi denial-of-service può richiedere che la funzione di hashing della prima metà sia abbastanza veloce da tenere il passo con i tentativi di accesso di spam, ma non sarebbe così necessaria per la funzione della seconda metà poiché solo un attaccante che avesse violato la password della prima metà sarebbe stato in grado di tentare l'accesso con la seconda.

Se Fred Jones fosse avvisato ogni volta che qualcuno tentava di accedere con una prima credenziale errata, un malintenzionato potrebbe facilmente inondare il signor Jones con così tante notifiche che diventerebbero inutili, indipendentemente dal fatto che l'autore dell'attacco abbia o meno una reale probabilità di ottenere l'accesso. Notificare al signor Jones se qualcuno immette la prima password corretta ma non riesce a inserire una seconda password corretta, tuttavia, sarebbe molto più utile. A meno che il signor Jones non fosse la persona che stava tentando di accedere all'account, tale notifica servirebbe come avvertimento molto tempestivo e utile che la password principale è stata violata ed entrambe le password dovrebbero essere cambiate al più presto.

Indipendentemente dai dettagli dell'hashing o da meccanismi di cracking plausibili, il nocciolo della questione è che lo sforzo necessario per decifrare password a due n bit non è di 2n bit. È n + 1 bit.

Supponi quindi che le tue password di otto caratteri, P1 e P2 , abbiano ciascuna, diciamo, un'intensità equivalente a 30 bit. (Non importa, sto solo cercando di scegliere un numero per essere concreto. Quindi ci vogliono 30 bit di sforzo [Vedi nota] per decifrarli. Per decifrarli entrambi, non ci vogliono 60 bit. Invece ci vogliono 31 bit) un po 'di sforzo.

Ora supponiamo di prendere P1 e aggiungere semplicemente una cifra scelta in modo uniforme (tiri un D10) e incollarla alla fine. Quindi il tuo P1 aumentato impiegherà circa 33,3 bit di sforzo per decifrare. Questo è più di quattro volte più faticoso che cercare sia P1 che P2.

Se scegli una singola lettera o cifra minuscola (quindi 36 possibilità) a caso da aggiungere alla fine di P1, allora questa nuova password è più forte di 5 bit, e quindi ci vorranno 16 volte più tentativi per decifrarlo rispetto a quello per decifrare entrambi P1 e P2.

Vault di sicurezza più elevati?

Lavoro per 1Password, un gestore di password e riceviamo richieste di vault all'interno dei vault. Questa è una password principale per sbloccare generalmente 1Password e quindi una seconda password per sbloccare alcuni dati di sicurezza più elevati. Abbiamo rifiutato queste richieste per i motivi che io (e altri qui) abbiamo sottolineato.

Il risultato sopra descritto è controintuitivo è controintuitivo. Le persone percepiranno l'utilizzo sia di P1 che di P2 come più sicuro di un aumento leggermente più lungo di P1 . Consideriamo anche la scelta di una password principale da parte di una persona come il punto più debole della sua sicurezza 1Password (diversa dall'esecuzione su una macchina compromessa) e quindi non vogliamo introdurre elementi che potrebbero incoraggiare le persone a utilizzare password principali più deboli di quanto farebbero altrimenti . Vorremmo anche che le persone ottenessero la massima sicurezza per lo sforzo, e fare e ricordare una piccola aggiunta a una password principale è meno faticoso che creare e ricordare un'altra password.

Note:

"bit di sforzo": n bit di sforzo significa approssimativamente che occorrono in media 2 ^ ( n -1) tentativi per trovare la password corretta.