In che modo alcuni siti (ad esempio banche online) richiedono solo caratteri specifici da una password senza archiviarli come testo normale?

Anche se non conosco esplicitamente come le banche gestiscono questo requisito, un processo alternativo a quello che @rakhi menziona sarebbe usare un HSM e crittografia reversibile.

L'idea è che la password completa venga archiviata nel database crittografato utilizzando un codice simmetrico (ad esempio, AES). Quindi, quando i caratteri della password vengono passati all'applicazione, vengono inseriti nell'HSM insieme alla password crittografata.

HSM potrebbe quindi decrittografare la password e confermare che i 3 caratteri sono come previsto, restituendo una risposta pass / fail all'applicazione. Quindi in nessun punto la password è mantenuta in chiaro (a parte nell'HSM considerato sicuro).

Ciò si collegherebbe al modo in cui la crittografia PIN può essere gestita dalle reti ATM (ad es., crittografia simmetrica e HSM)

Ogni volta che si incontra un caso in cui è necessario conoscere qualcosa sulla propria password oltre all'hash della password completa, si può presumere che la password non sia con hash. Mentre è stato menzionato PCI-DSS, non esiste alcuna regola che sia a conoscenza di ciò che si applica alla crittografia delle banche o alle informazioni sulla password di hashing. PCI-DSS non copre i dati del tuo conto bancario, incluso il login con il tuo PIN o qualche variazione di esso.

Se sono buoni, la password viene archiviata utilizzando la crittografia. Se non sono così buoni, potrebbero effettivamente essere archiviati in testo semplice.

Ammetto che mi piace il compromesso qui. L'intero database delle password potrebbe essere esposto a un maggiore rischio di attacco se è compromesso, ma contrometterei che la sicurezza delle banche dovrebbe essere nella fascia più alta. Se si sospettava un compromesso del database, tutto dovrebbe essere cambiato comunque con hash o crittografato. Entrambe le istanze Con questo metodo particolare, ci vuole molto più tempo e un maggior grado di complessità per un utente malintenzionato di ottenere sufficienti informazioni utili per effettuare un attacco con un keylogger.

Qualcosa legato tangenzialmente: link

Lo schema di NatWest mi colpisce per un valore dubbio. Nello schema di NatWest, un attacco di phishing può probabilmente rubare l'intero PIN e tutta o la maggior parte della password. Ecco come funzionerebbe l'attacco di phishing.

1. Il sito di phishing presenterebbe una schermata di login fasulla, richiedendo 3 cifre del PIN e 3 caratteri della password.

2. L'utente digita la risposta in.

3. Il sito di phishing ora presenta una risposta che indica che la voce non è corretta e richiede di nuovo all'utente.

4. Molti utenti probabilmente presumono che abbiano inserito qualcosa di sbagliato e riprovano.

Se il phisher è intelligente, il secondo prompt del sito di phishing richiederà un diverso set di cifre e caratteri. Se l'utente prova una seconda volta, il sito di phishing può apprendere tutte le 4 cifre del PIN e 6 caratteri della password dell'utente. (Si noti che NatWest richiede agli utenti di scegliere una password contenente 6-8 caratteri, quindi è garantito che 6 caratteri della password siano tutti o quasi tutti.) A quel punto, è game over.

Di conseguenza, non mi è chiaro che lo schema di NatWest ti compra qualcosa.

In a domanda simile , un commento di @captaincomic ha linkato a questo articolo: Password parziali - Come? (Da Archive.org) Spiega come consentire a questa funzionalità senza di memorizzare la password in una forma recuperabile o a separare ogni carattere separatamente - utilizzando lo schema di condivisione dei segreti di Shamir.

È solo collegato in modo tangenziale, ma David Aspinall (Università di Edimburgo) e Mike Just (Glasgow Caledonian University) hanno pubblicato un documento sulle password parziali nel 2013: " Give Me Letters 2, 3 and 6! ": Implementazioni di password parziali e amp; Attacchi .

Il loro articolo esamina gli attacchi online per i quali il meccanismo di back-end storage è irrilevante, ma fa un'osservazione di passaggio che è pertinente alla tua domanda:

To support the partial protocol the implementation will need to either store plain-text for the password, or devise a mechanism for performing one-way checks on all combinations that might be queried (which can be a large number for long passwords). We don’t investigate this attack mode here.

No, ciò che stanno facendo è troncare ogni carattere e memorizzarlo o archiviare la password in chiaro in un dispositivo sicuro, ad es. HSM.

Non è un approccio negativo; la banca richiede all'utente di inserire un numero di caratteri (ad esempio HSBC è 3 da posizioni casuali). Significa che se un trojan, un key logger o un sito di phishing hanno catturato quei 3 caratteri, non hanno la password completa.

Permette inoltre alla banca di utilizzare la password parziale per autenticare gli utenti al telefono ecc. senza fare affidamento su domande segrete o una password diversa, sempre senza che il call centre conosca la password completa

Alcuni problemi che probabilmente sono il motivo per cui non è più usato:

• Il principale è che non si desidera archiviare la password in chiaro (infatti i regolamenti come PCI-DSS non lo consentono). Quindi l'approccio è creare un hash unidirezionale della password e memorizzarlo. Quando l'utente immette la password, questa viene sottoposta a hash e confrontata con l'hash memorizzato, se corrispondono all'utente autenticato. Con una password parziale è necessario memorizzare la password con crittografia reversibile che non è la procedura migliore o memorizzare un numero elevato di hash, ad es. per HSBC con un compleanno più ogni carattere della password richiede un hash separato. Devi anche imporre una lunghezza massima della password in modo da poter allocare i campi nel database per archiviare tutti gli hash (anche se probabilmente ci sono probabilmente più intelligenti tecnologie di database e applicazioni che potrebbero aggirare questo)

• Incoraggia gli utenti a selezionare password deboli, ad es. se ho una password complessa di 8 caratteri: tpEz% e2S. Cercando di ricordare quale sia il secondo, il quinto e il quinto carattere di questo è difficile, il che incoraggia gli utenti a selezionare una semplice parola del dizionario.

• Inoltre, se non ci sono funzionalità di blocco degli account, è esponenzialmente più facile da indovinare o forza bruta 3 caratteri di 8 caratteri.

• La confidenza che la password completa non è nota potrebbe essere collocata erroneamente ad es. se la password è Fulham e conosci F, l, h, potresti forse fare una discreta supposizione con la password completa

• Un sito di phishing che chiedeva semplicemente il 1 °, 3 °, 5 °, poi ha detto che la password errata e cambiata per chiedere il 2 °, 4 °, 6 ° potrebbe anche ottenere la password completa come utente probabilmente inserirla prima che ci pensassero due volte

• Dal punto di vista dell'utente, significa che non possono utilizzare i browser per ricordare password o un gestore di password come Lastpass o 1Password

La maggior parte delle banche si sta allontanando dal fare affidamento su nome utente e password, ad es. HSBC offre un token RSA per i clienti aziendali, Barclays ha un lettore di smart card EMV, quasi tutti utilizzano la tecnologia di rilevamento come l'autenticazione adattiva RSA per stabilire una linea di base di browser, posizione, profilo di utilizzo, velocità ecc per l'autenticazione passiva e il rilevamento di uso non autorizzato.