La verifica dell'identità in base alla posizione nelle password indica che le password vengono archiviate senza alcun rispetto? [duplicare]

Se è possibile verificare la password per carattere, riduce in modo significativo la forza effettiva della password. Piuttosto che essere esponenzialmente più strong per ogni personaggio, sarebbe solo incrementalmente più strong.

Ad esempio, supponiamo di avere una password di quattro caratteri che è "ABCD". Se devo conoscere l'intera password per farlo bene, le possibili permutazioni (diciamo solo superiore, inferiore e numerico consentito per ragioni di discussione) sono combinazioni 62 ^ 4 o 14.8M possibili. Se d'altra parte posso determinare da solo un successo per ogni carattere, posso trovare la password in 62 * 4 combinazioni, o 248 operazioni usando la forza bruta.

Quindi, anche se in questo modo potrebbe essere possibile o meno hash una password, fare così eliminerebbe efficacemente la sicurezza di farlo.

È possibile che il servizio non solo ha calcolato l'hash della password completa al momento della creazione, ma ha anche cancellato il 3 ° e il 7 ° carattere (o eventualmente ogni carattere) individualmente. In questo modo, tecnicamente non memorizzerebbero i caratteri o la password completa in testo semplice. Tuttavia questa sarebbe una pessima idea. Un hash di un singolo carattere non è essenzialmente migliore del testo in chiaro poiché ci sono solo 62 possibili hash di singoli caratteri per ogni sale (se si usa un sale).

In entrambi i casi, se il servizio è in grado di riconoscere parte della password anziché solo la password completa, si tratta di cattive notizie.

Qualsiasi autenticazione che richiede all'utente dettagli sulla password indica che la password in chiaro è disponibile per il sistema. Ciò significa che non sono stati modificati, ma possono comunque essere crittografati e protetti con altri mezzi.

Non ci sono tecniche per verificare il sottoinsieme di una password con hash rispetto all'intera password hash. Questo è in realtà uno degli obiettivi di una funzione hash in quanto protegge dall'indovinare una password carattere per carattere.

Come le risposte precedenti hanno già affermato, non esiste una tecnica nota per eseguire un hash parziale di una password e verificare la stringa. La natura delle funzioni hash unidirezionali rende impossibile verificare se una password è simile a un'altra, solo che le password sono identiche. Pertanto, ciò implicherebbe che la banca abbia memorizzato le password usando la crittografia bidirezionale, eseguendo l'hashing delle sottostringhe o (l'horror!) Come testo in chiaro.

Questa tecnica ha in realtà una serie di vantaggi e svantaggi, contrariamente alle opinioni correnti secondo cui questa tecnica non ha fattori di riscatto.

Il compromesso delle password bancarie può avvenire in due modi, tramite l'hacking dei server bancari che si traduce in una perdita di hash o tramite una password compromessa all'utente finale (keylogger, trojan, semplice spionaggio, attacchi MITM su SSH) ecc.

La memorizzazione delle password in modo da consentire il recupero delle sottostringhe consente a un hacker che ha ottenuto l'accesso al database della banca per ottenere facilmente le password in chiaro, anche se estremamente potenti. Se la banca utilizzava la crittografia a due vie, un hacker che ha ottenuto l'accesso al database crittografato sarebbe quasi certamente in grado di ottenere le chiavi. Se invece hanno cancellato una selezione di sottostringhe, si otterrebbe un caso simile agli hash deboli di NTLM che renderebbero è facile recuperare le password in chiaro. Lo spazio hash molto piccolo di 3-5 caratteri (supponendo che fosse usato un hash) avrebbe reso banali i tentativi di inversione, anche se fosse stato utilizzato un sale.

Tuttavia, questo deve essere bilanciato contro i rischi alternativi. Un potenziale hacker bancario che ha ottenuto l'accesso solo al computer della vittima (e potenzialmente anche il suo token di autenticazione a 2 fattori) non sarebbe in grado di accedere al conto bancario della vittima, poiché sarebbe richiesto un diverso sottoinsieme di caratteri dalla password.

Poiché l'ultimo caso di compromissione della sicurezza dei conti bancari è molto più probabile, è logico che le banche applichino tali sistemi di hashing in misura limitata.

Sembra che la password parziale non debba essere memorizzata in modo equivalente al testo normale. Questo schema, basato sullo schema di condivisione segreta di Shamir potrebbe essere utile: link

A. Global Parameters

At the beginning, someone has to define global parameters of the system. Well, there is actually just one - how many letters will users have to select. Let us call the parameter N. The maximum length of password (L) is important only from the database point of view - you will need to store a 32b long number for each character.

B. adding New User

1. User chooses his/her password P. It consists of letters p1, p2, p3, ... pk.
2. The system will generate at least 32 bits' long secret key - K - unique for each user. 32 bits is enough if N is 3, for larger N (the number of letters users have to correctly select each time) you may want to increase the length of K.
3. The system will also generate N-1 32 bits' long random numbers R1, R2, ... R(N-1)
4. The next step is a computation of k points (k being the length of the password) on a polynomial: y=K+R1*x + R2*x^2 + ... + R(N-1)*x^(N-1), for x = 1, 2, ... k. Let us denote the results as y1, y2, ..., y(N-1).
5. Values s1=(y1-p1), s2=(y2-p2), ... sk=(yk-pk) is stored in the database. Each number takes 32 bits. One will also need to store K, or the hash of K.

C. Authentication

The next part of the system is user authentication, which is very simple and fast.

1. The system selects N positions in the password - i1, i2, ... iN.
2. A user selects N letters from her/his password at specified positions so that we have pairs (p'1, i1), (p'2, i2), ..., (p'N, iN).
3. The system recovers yi values for indices i selected in step 1 - simply just adding stored values (see step 5 above) to values p'i entered by the users.
4. Now we have to solve the polynomial equation to obtain K'. The equation for that looks horribly but it is quick to compute and can even be partially pre-computed as it uses indices (positions of letters): K' = \sum_i [ yi * [ (\PI_j (j) ) / (\PI_j (i-j)) ] ], where i and j run over i1, i2, ..., iN (step 1), and j skips the actual selected i. Example: let's say that user selected 2nd, 3rd, and 4th letter, the solution will be: K'=y2*( 3*4/[(2-3)(2-4)] )+y3( 2*4/[(3-2)(3-4)] ) + y4( 2*3/[(4-2)*(4-3)] )
5. The last step is to compare K and K'. If they are equal, user entered correct values and is logged in.

One note here - the secret is not K, but values yi reconstructed when user enters his/her letters.

(Non sono un esperto di sicurezza e non so se questo schema ha senso)

Se sempre usano il terzo e il settimo carattere per questo, potrebbero salvare solo le hase della password e questo estratto. In sostanza, questo dividerebbe la password di intera lunghezza abcdefghijklm in due password più corte cg e abdefhijklm . Di questi, la password di due caratteri non offre praticamente alcuna sicurezza. Inoltre, la password rimanente non è solo abbreviata di due caratteri, ma è anche suscettibile di attacco "crib": a meno che la password originale non fosse completamente casuale, i personaggi facilmente indovinati danno un buon suggerimento su ciò che siamo cercando (ad esempio, tra tutte le password in uso con il settimo carattere 2 scommetto che c'è una proporzione significativa che ha lunghezza esattamente 10 e finisce in qualcosa tra 2000 e 2015 ).

In ogni caso, se avessero considerato le implicazioni di sicurezza abbastanza a fondo per memorizzare in modo sicuro gli "estratti" della password, avrebbero dovuto notare che l'estratto è un grande rischio. Ciò suggerisce che tali considerazioni non sono state fatte, il che suggerisce di nuovo che memorizzano la password in chiaro (ovvero il rasoio di Occam).