C'è un modo in cui la mia password viene hash, se mi viene chiesto di fornire solo 5 caratteri su molti?

Question

view on stackexchange narkive permalink

Esiste un sistema che, in un form di login, presenta circa 40 caselle per le lettere della password (per nascondere la lunghezza effettiva della password) e solo quelle casuali (la stessa quantità ogni volta) sono modificabili. La spiegazione è: proteggermi dai keylogger. Sembra legittimo. Ma significa che la mia password è mantenuta in testo normale? O esiste un algoritmo hash noto che lo consentirebbe?

Nota: non sto chiedendo se è buono o cattivo pratica, chiedo informazioni su possibilità / fattibilità / metodo di hashing.

Answer 1

view on stackexchange narkive permalink

No : in questo caso non esiste un modo pratico per eseguire l'hashing della password.

Affinché il sito web funzioni in questo modo, l'hash dovrebbe consentirti di verificare che un Il sottoinsieme di 5 caratteri della password corrisponde a un determinato valore. Ciò significa che potresti forzare quei 5 personaggi da soli, il che è prontamente pratico, e una volta che conosci 5 personaggi, è facile forzare il resto. Questo è in qualche modo simile alla debolezza delle password LANMAN.

Le password parziali hanno vantaggi in termini di sicurezza, specialmente contro i key logger. Le app bancarie a volte hanno una normale password con hash sul server e un codice di autenticazione aggiuntivo, che si immette solo parzialmente e NON viene sottoposto a hashing sul server. Questo è considerato completamente accettabile, ma sta diventando meno comune in quanto l'autenticazione a più fattori è una soluzione migliore.

In questo caso particolare, non è chiaro che questa sia una cattiva idea. È necessario valutare il rischio di compromissione del server rispetto al rischio di keylogger lato client. In effetti, è il cliente che è a rischio maggiore. Quindi, nonostante vada contro le normali best practice, questo sito Web non è poi così stupido.

Answer 2

view on stackexchange narkive permalink

Come altri hanno affermato, qualsiasi tentativo di risolvere questo problema con algoritmi di hashing è destinato a fallire.

Tuttavia, penso che valga la pena parlare di come ING probabilmente risolverà questo problema. (Dichiarazione di non responsabilità: non ho mai lavorato per ING, ma ho lavorato per altre grandi banche).

È probabile che ING memorizzi la tua password in un Hardware Security Module. Questo è un componente hardware a prova di manomissione, progettato in modo che nemmeno l'operatore del sistema possa estrarre gli hash delle password. Internamente, probabilmente memorizza la tua password in testo normale (o qualcosa di simile a testo normale), ma comunica solo con il mondo esterno tramite le operazioni "inserisci i caratteri x, yez" e limita il numero di tentativi consentiti.

In questo scenario, la sicurezza della password dipende dal fatto che l'HSM sia a prova di manomissione. Sono stati pubblicati attacchi agli HSM, ma la superficie di attacco è ridotta rispetto agli hash archiviati in un RDBMS.

Answer 3

view on stackexchange narkive permalink

Un modo in cui questo potrebbe essere implementato è memorizzare circa un centinaio di hash di password parziali. Ogni volta che l'utente accede con una password parziale, verrà contrassegnata come utilizzata. L'elenco degli hash può essere rigenerato ogni volta che è necessario immettere una password completa.

Questo schema indebolisce la sicurezza contro la forza bruta o la crittoanalisi, ma può proteggere dal key logger se devi spesso accedere da macchine non affidabili.

Avevo visto questo schema utilizzato su una carta travel money, poiché spesso i viaggiatori potrebbero dover utilizzare l'account da computer pubblici. Per le normali operazioni bancarie, tuttavia, penso che questo indebolisca solo la sicurezza. Se il tuo normale personal computer è infettato da un key logger, bastano pochi accessi per raccogliere la password completa dalle password parziali.

Per rafforzare questo schema dalla crittoanalisi e dall'attacco di forza bruta, il le password dovrebbero essere memorizzate con un hash molto lento, come PBKDF2 con molti round. E per ostacolare la capacità dell'attaccante di forzare gli hash in parallelo in una volta sola, è necessario forzare l'utilizzo della password parziale nell'ordine specifico in cui sono stati creati. Ad esempio, l'utilizzo dell'ennesima password parziale per crittografare l'elenco dei numeri e il salt per la n + 1esima password parziale costringerebbe l'attaccante a risolvere l'ennesima password parziale prima di poter iniziare a lavorare sulla n + 1 ' th.

Answer 4

view on stackexchange narkive permalink

Sì - È possibile che abbiano semplicemente cancellato tutte le combinazioni che ti mostreranno.

Anche se penso che non l'hanno implementato e stanno memorizzando la tua password, probabilmente crittografato, ma non sottoposto a hashing.

Una migliore combinazione di sicurezza che utilizza questo metodo tenendo conto dello spazio di archiviazione:

1. Crittografa la password in chiaro e mettila in una sorta di freddo -storage.
2. Decifra periodicamente la password per creare nuove combo e le hash.

In questo modo lo spazio di archiviazione viene mantenuto ragionevole. E la tua password senza hash dovrebbe trovarsi in un livello più sicuro del sistema.

Answer 5

view on stackexchange narkive permalink

Potrebbe non essere sottoposto ad hashing, ma potrebbe essere archiviato crittografato. Teoricamente avrebbero potuto usare Schema di soglia con caratteri ASCII consentiti come chiavi, quindi controllare se il risultato corrisponde al risultato. In questo modo (teoricamente) non dovresti aver bisogno di memorizzare una password solo una soluzione.

PS. Ad esempio, vedi http://programmingpraxis.com/2011/06/17/adi-shamirs-threshold-scheme/

Answer 6

view on stackexchange narkive permalink

Supponi che la password possa contenere 40 caratteri. Supponiamo che i caratteri possano essere interpretati come numeri c_1, c_2, ... c_40 di un campo finito F adatto ( Campo di Galois). Supponiamo anche che F abbia almeno 40 elementi.

Supponiamo di calcolare il polinomio di interpolazione p per 40 elementi predefiniti nessuno zero di F tale che p (a_j) == c_j. Memorizziamo ora 35 coefficienti di questo polinomio più un hash (salato) dell'altro 5.

Ogni volta che l'utente ci dà 5 dei caratteri possiamo sfruttare i 35 coefficienti noti per recuperare i 5 coefficienti mancanti e poi calcolare l'hash. Se uno qualsiasi dei 5 caratteri è sbagliato, ci ritroveremo con un polinomio diverso e quindi un hash diverso. Quindi potresti voler memorizzare l'hash in qualche modulo di sicurezza hardware dedicato come James_plc ha già sottolineato.

Quindi sì, questo è possibile. Tuttavia, se il tuo negozio protetto viene compromesso, è almeno altrettanto semplice da decifrare quanto forzare brutalmente una password di 5 lettere.

Per altri algoritmi in questa direzione potresti voler saperne di più sulla condivisione segreta.

Answer 7

view on stackexchange narkive permalink

Significa che la mia password è mantenuta in testo normale?

È molto probabile che sia in testo normale o crittografata, ma non è certo.

Ad esempio, quando inizialmente invii la tua password, è possibile eseguire l'hashing e salvare diverse combinazioni di 5 caratteri della tua password e degli indici dei caratteri a cui si applicano.

Tuttavia, chiunque abbia accesso a tali informazioni e all'algoritmo di hashing potrebbe facilmente decifrare gli hash di 5 caratteri e riassemblarli per ottenere la tua password originale, quindi anche se è sottoposto ad hashing è un modello debole .

Answer 8

view on stackexchange narkive permalink

Suppongo che potresti memorizzare un elenco di hash di tutte le combinazioni di qualsiasi carattere X, dove X è il numero di caratteri che devi fornire.

Questo non sarebbe un hash molto forte se il resto dell'hash era formato da personaggi noti. Sarebbe possibile derivare il resto dei caratteri spazzatura da un sale utente o derivarli in qualche modo dai caratteri X forniti, ma non è ancora l'hash più forte.

Answer 9

view on stackexchange narkive permalink

Non riesco a vedere perché l'algoritmo di autenticazione non è riuscito a memorizzare tutte le combinazioni delle sottostringhe della password come hash rispetto all'elenco ordinato delle posizioni dei caratteri, quindi se la password fosse:

password

quindi ci sarebbe una tabella di (chiave, hash) dove le chiavi erano ad es.

"1" solo per la prima lettera "1,2" solo per la prima e la seconda lettera "4,5 , 6 'solo per la quarta, quinta e sei lettere

e memorizza su queste chiavi l'hash di una stringa delle lettere indicate, quindi contro

' 4,5,6 'sarebbe essere l'hash ('swo') dalla password di esempio.

Il problema con questo ovviamente è che invertire gli hash sarebbe semplice a meno che non fossero salati con un sale per utente, e anche in questo caso sarebbe relativamente semplice per forzare gli hash di sequenze brevi per ovvie ragioni se la vendita fosse compromessa (mantenere il segreto del sale sarebbe una soluzione a questo).

Non sono sicuro di come lo farebbero altrimenti però .. .

Domanda interessante.

Answer 10

view on stackexchange narkive permalink

La risposta è che dal punto di vista della sicurezza è una cattiva idea, ma è tecnicamente possibile che sia sottoposto a hashing.

Se si tratta di un sottoinsieme casuale della tua password completa che stai inserendo (come il primo, il secondo, il quinto, il sesto e l'ultimo carattere una volta e una diversa selezione casuale la volta successiva) puoi farlo (al salvataggio iniziale) suddividendo la password in sottoinsiemi predeterminati e quindi eseguendo l'hashing.

Essenzialmente questo è solo un modo stravagante per far sì che gli utenti inseriscano più password senza sapere che è quello che stanno facendo. L'utente sa quindi quale password inserire in base alle caselle disponibili.

Sebbene ci siano cose che potresti fare per compensarlo (imponendo password iniziali molto più lunghe, rigorosi 3 tentativi di accesso al giorno, aumentando il numero di password multiple salvate e passando a una nuova dopo ogni tentativo di accesso e non consentire la ripetizione fino a un accesso riuscito, ecc.), questo in generale renderebbe le tue password più brevi (nel tuo caso 5 caratteri) e quindi più deboli.

Per inciso, la protezione che otterresti dai keylogger in ogni caso sarebbe minima. Richiederebbe solo al keylogger di esaminare effettivamente molti dei tuoi accessi e capire qual è la tua password completa. Una migliore sicurezza per il key logging consiste nell'usare l'autenticazione a due fattori, che non deve essere complicata o costosa. Quando l'utente accede, presentagli un codice che può annotare e inserire per accedere la volta successiva.

Answer 11

view on stackexchange narkive permalink

sì Mi ricorda il protocollo a prova di conoscenza zero. La password non può essere intercettata perché non viene mai trasmessa o addirittura inserita completamente dall'utente. (Non puoi imparare la password dal protocollo.) Ma il segreto dovrebbe essere abbastanza forte. Se chiedi un carattere, ovviamente dopo aver visto ogni posizione conosci la password. Lo stesso vale per l'hashing. Se l'hash è debole può essere rotto.

Modifica: penso che l'hash in questo caso non sia un hash md5 o simile, in questo caso con l'hash si intende il segreto che contiene la password. Nella documentazione a conoscenza zero c'è spesso un grafico colorato o un grande polinomio. Non ricordo i dettagli.

Forse pensalo come scomposizione in fattori primi. Supponi di avere un elenco di numeri primi e di memorizzare (Prodotto: i: p [i] ^ i) (es. 504) nel database e ti chiedo il 3 ° fattore primo ... nel caso in cui rispondi 2 puoi facilmente controllare terzo numero ... come 504 == 7 * 3 * 3 * 2 * 2 * 2 ora passa a numeri primi grandi come nella crittografia avanzata.