Domanda:
C'è un modo in cui la mia password viene hash, se mi viene chiesto di fornire solo 5 caratteri su molti?
Mołot
2015-09-23 15:17:47 UTC
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?

Screenshot

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

I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/29851/discussion-on-question-by-molot-is-there-any-way-my-password-is-hashed- if-im-o).
Undici risposte:
#1
+62
paj28
2015-09-23 15:38:55 UTC
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.

I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/29587/discussion-on-answer-by-paj28-is-there-any-way-my-password-is-hashed- if-im-onl).
Ti rendi conto che per dimostrare che la risposta è negativa devi dimostrarlo matematicamente?
Tieni presente che soppesare il rischio di compromissione tra server e client non significa solo confrontare le possibilità, ma anche confrontare le conseguenze. Server significa che * tutti * i dati degli utenti sono a rischio, client significa che lo sono solo i dati degli utenti interessati. (Il che può o meno portarti alla stessa conclusione.)
@hvd, confronta anche i numeri. Numero di client vs numero di server.
#2
+53
James_pic
2015-09-24 14:12:01 UTC
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.

Punto interessante! È sempre utile ricordare alle persone che c'è più di un modo per scuoiare un gatto.
Può essere crittografato con una chiave casuale e la chiave crittografata con una chiave pubblica. Quindi, quando deve essere controllato, i cinque caratteri, più la password crittografata e la chiave crittografata vengono passati all'HSM che decrittografa la password ed esegue il controllo. In questo modo l'archiviazione non deve essere all'interno dell'HSM
Hai un collegamento a un HSM che esegue questa tecnologia? Non ho mai sentito parlare di un HSM che lo fa.
#3
+13
Lie Ryan
2015-09-23 19:14:01 UTC
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.

Penserei che un keylogger non sarebbe sufficiente, dato che non conoscerà le posizioni assolute dei personaggi. Un esempio semplificato: se il sistema richiede 3 caratteri e il tuo keylogger registra le seguenti voci: `FED`,` BAC`, `FAC` e` DAC`, non saprai se la mia password è `FEEDBACK`, "BOLDFACED" o "FRIEDBACON". Le combinazioni "F E B" e "E D A" ne eliminano 1, e usando "I", "K" o "N" si eliminano 2, ma ovviamente quelle sono solo 3 possibili password. Penso che ci vorrebbero molti, molti accessi perché un keylogger da solo assembli la password completa.
#4
+9
BAR
2015-09-24 14:20:57 UTC
view on stackexchange narkive permalink

- È 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.

#5
+5
Marcin Raczkowski
2015-09-27 03:16:39 UTC
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/

Noto anche come [Secret Sharing] (https://en.wikipedia.org/wiki/Secret_sharing)
#6
+4
Udo Klein
2015-09-27 12:47:47 UTC
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.

#7
+2
Briguy37
2015-09-24 20:49:09 UTC
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 .

#8
+2
Ian Newson
2015-09-24 23:22:56 UTC
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.

#9
+1
David Scholefield
2015-09-23 15:30:39 UTC
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.

Questo sarebbe un disastro. Dovresti immagazzinare un sacco di hash, ognuno dei quali sarebbe facilmente utilizzabile con la forza bruta. La risposta alla domanda è no.
@paj28 Perché dici che la risposta è no? Mi sembra che dovrebbe essere possibile costruire una funzione irreversibile il cui valore è zero in un insieme di valori scelto, ognuno dei quali corrisponde a ottenere cinque caratteri nella password.
@DavidSchwartz - Non so come farlo. Se riesci a spiegare in dettaglio la funzione irreversibile che hai in mente, sono felice che mi venga mostrato sbagliato.
Tra "possibile", sostenuto dall'esempio, e "impossibile", sostenuto da una legge matematica fondamentale, c'è un'ampia area di "metodo non ancora conosciuto", "non dimostrato in nessun modo" ecc.
@DavidSchwartz - Sento che sei pedante con me ora, ma attendo con impazienza la tua risposta.
Ho appena visto così tante cose una volta considerate impossibili in crittografia (e in alcuni casi persino dimostrate impossibili) che sono state successivamente realizzate. Sono molto scettico nei confronti delle persone che dicono che qualcosa è impossibile solo perché non riescono a pensare a un modo per farlo. (E questo potrebbe essere un esempio della categoria "provato impossibile" - guarda il mio commento alla tua risposta "dimostrando" che non è possibile.)
@DavidSchwartz Anche se ciò fosse possibile, risolverebbe solo uno dei due problemi a cui alludeva paj28. Non è più necessario archiviare un sacco di hash, ma è ancora prontamente in grado di forzare: supponiamo che un utente malintenzionato desideri violare la password e abbia accesso ai dati memorizzati. Per prima cosa cerca di forzare i primi 5 caratteri - questo è possibile, poiché i dati memorizzati sono sufficienti per convalidare le sue ipotesi, e facile, poiché ci sono al massimo 40 bit di entropia, probabilmente meno. Quindi cerca di forzare i successivi 5 personaggi. Continua in questo modo finché non ha risolto il problema.
Non vedo come, se il sale fosse tenuto segreto, gli hash per sequenze brevi sarebbero facili da usare con la forza bruta. Il sale segreto aumenterebbe lo spazio di inversione dell'hash alla lunghezza del sale + la stringa di caratteri che necessitava dell'hashing. Quindi, se avessi anche una sola lettera (la posizione 5 corrisponde alla lettera 'w'), se il sale segreto fosse '78tfo43bfqdagd7q4q4vk0ss09s' l'hash sarebbe difficile, se non impossibile, invertire con la forza bruta perché non potresti 'indovinare' tutti i sali possibili.
I sali di @DavidScholefield vengono normalmente memorizzati accanto agli hash delle password per consentire la verifica. Quindi non dovresti dare per scontato che il sale sia segreto se qualcuno sta cercando di rompere l'hashish.
@James_pic Tu e David Schloefield presumete che l'algoritmo non crei falsi positivi. Potrebbe introdurre un tasso di falsi positivi di uno su un milione che sconfiggerebbe i tentativi di forzatura bruta ma non indebolirebbe in modo significativo lo schema. Il tentativo produrrebbe più password non password che password e ti darebbe poco aiuto per ottenere la password effettiva.
@DavidSchwartz Difficilmente chiamerei escludere il 99,9999% delle password "piccolo aiuto". Ed è ancora possibile che schemi più sofisticati abbiano successo. Supponiamo che l'aggressore abbia un candidato per i primi 5 caratteri della password. Ora può indovinare il personaggio 6 e controllare la sua ipotesi usando le combinazioni dei primi 5. Se trova una corrispondenza, ora ha 6 caratteri e può indovinare a 7. In caso contrario, torna indietro. Forse un algoritmo di hashing intelligente potrebbe impedirlo in qualche modo, ma non è stato ancora proposto alcun algoritmo concreto.
#10
+1
theinvisibleduck
2015-09-24 22:54:35 UTC
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.

#11
-1
Wouter
2015-09-24 02:24:39 UTC
view on stackexchange narkive permalink

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.

OK, quindi come testare una password se tutto ciò che hai è un hash e * alcune * lettere dalla password? Dici di sì perché conosci un modo per farlo o semplicemente perché non è stato ancora smentito?
* "Non puoi imparare la password dal protocollo." * Puoi assolutamente farlo, indipendentemente dalla parte del protocollo a cui ti riferisci.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...