Il sito consente l'autenticazione della password sia parziale che completa; hanno la mia password in chiaro? [duplicare]

Per supportare "password parziali", la banca deve necessariamente memorizzare la password in chiaro, o almeno alcuni valori che consentano la ricostruzione rapida della password completa. Si vede facilmente nel modo seguente: quando la banca chiede, per esempio, la 3a, la 4a e la 8a lettera della password, allora ci sono meno di un milione di possibilità (supponendo che le "lettere" siano caratteri stampabili). Eppure la banca può in qualche modo decidere se le tre lettere fornite sono quelle giuste o meno. Pertanto, qualunque sia il deposito in banca è sufficiente per eseguire un attacco di forza bruta sulla 3a, 4a e 8a lettera e quell'attacco avrà successo in meno di un milione di tentativi.

La banca può aggiungere strati di crittografia e hashing e cosa non lo è, questo non cambierà il fatto. Ogni volta che c'è il supporto per "password parziali", allora c'è spazio di archiviazione molto sensibile sul lato server. In questo senso, il supporto per le password parziali riduce la sicurezza, invece di aumentarlo. (Si può sostenere che le password parziali aumentano la sicurezza sul lato client: shoulder surfers ottengono solo una vista parziale della password, ma devi essere consapevole che questo è un compromesso: più sicurezza lato client per meno sicurezza lato server.)

Per supportare l'autenticazione con password completa, la banca deve memorizzare qualcosa che sia sufficiente per verificare una password completa. Lo stesso ragionamento di cui sopra si applica, ma per un attacco di forza bruta sulla password completa, non su una password parziale. Se una banca supporta entrambe le autenticazioni "password parziale" e "password completa", allora probabilmente memorizza uno dei seguenti:

• La password completa in un formato "recuperabile" (testo in chiaro o crittografato con una chiave che il server sa - che la crittografia è la protezione soprattutto contro gli aggressori occasionali sul lato bancario, ad esempio stagisti sottopagati).

• Un hash della password e degli hash completi per tutti i sottoinsiemi di password che la banca può chiedere all'utente di connessione.

La seconda possibilità richiede molta più memoria e complessità di implementazione da parte della banca, quindi la reputo improbabile. Gli sviluppatori di applicazioni bancarie non sono meno pigri dei loro simili.

Prendi nota che la tua password è non la tua risorsa più sensibile affidata alla banca. La banca detiene i tuoi soldi . E i soldi sono ciò che cercano gli aggressori. Se un utente malintenzionato trascina completamente il server di autenticazione, non si limiterà ad afferrare password crittografate o con hash; immediatamente falsificherà alcuni autentici trasferimenti di autenticazione e attivazione. Chi ha bisogno di una chiave per una porta quando è già dentro?

Le discussioni sulle password crittografate o con hash sono pertinenti per le violazioni parziali , ad es. quando l'utente malintenzionato trova un nastro di backup per un database o ottiene una vista di sola lettura tramite un attacco di SQL injection. In questo tipo di scenario, ciò che può essere fatto da un utente malintenzionato dipende molto dai dettagli sottili di come vengono implementate le cose nel server, quindi è difficile parlare in generale.

Probabilmente stanno memorizzando la password crittografata (cioè non hash); la crittografia è reversibile, quindi non vi è alcun motivo per cui non possano utilizzare il codice che accetta i caratteri di input dell'utente, decodifica la password memorizzata e verifica che l'input corrisponda ai caratteri nella password.

Se fatto correttamente, il programma usato per fare ciò memorizzerebbe solo temporaneamente il testo in chiaro e cancellerà esplicitamente quella memoria dopo l'uso (in modo che in caso di crash la password non venga scritta su un file leggibile dall'uomo).

Anche se è ovviamente possibile (improbabile?) che utilizzino password in testo semplice.

Per inciso ... un modo per aggirare la debolezza di non avere l'hash della password (derivante dalla funzionalità PPA) è avere due livelli di password, mentre questo non fornisce alcuna garanzia aggiuntiva di per sé, vuol dire che uno la password può essere memorizzata come hash (e utilizzata sempre completamente) mentre l'altra è crittografata (e utilizzata per PPA).

Il vantaggio di PPA è che può aiutare a sconfiggere le minacce di keylogging, anche se un utente malintenzionato ha accesso agli screenshot, dovranno osservare e acquisire i tratti chiave da più eventi di accesso prima che abbiano sufficienti informazioni per avviare un attacco riuscito.

Citando wikipedia :

It is good practice to not store passwords in cleartext. Instead when checking a whole password it is common to store the result of passing the password to a cryptographic hash function. As the user doesn't supply the whole password it cannot be verified against a stored digest of the whole password. Some have suggested storing the digest of each combination of letters that could be requested but they note that this results in generating and storing a large amount of digests. A better solution in terms of storage space and security is using a secret sharing scheme.