Come può essere migliorato questo algoritmo di crittografia?

-2

Attualmente sto sviluppando un'applicazione per memorizzare le mie password in modo sicuro. All'inizio sarà una prova di concetto, ma ho intenzione di aggiornarlo in seguito. Ad ogni modo, ecco come si accede alle password:

  1. Inserisci un nome utente e una password. Blocca entrambe le voci dopo l'invio e confronta gli hash memorizzati nel codice. Se gli hash corrispondono, procedi al passaggio successivo.
  2. Utilizzare il nome utente e la password effettivi immessi come chiavi / puntatori ai dati in un file di testo di una grande quantità di caratteri apparentemente casuali. Questo file verrà generato manualmente e verrà archiviato con il programma.

Esempio: username può essere convertito in un numero che corrisponde al carattere da cui iniziare nel file. Il password verrà convertito in un numero che rappresenta la quantità di caratteri tra ogni carattere utile nel file, cioè leggi il file, a partire da username , ma conserva solo ogni password -th carattere.

Non sono sicuro di come rendere questo approccio più sicuro e accolgo con favore eventuali suggerimenti.

    
posta GamrCorps 10.05.2016 - 06:38
fonte

1 risposta

8

La prima regola di crypto è non eseguire il rollpoint della propria crittografia . Stai cercando di trovare una nuova soluzione a un vecchio problema in cui esistono già le migliori pratiche consolidate. Questa è una cattiva idea, dal momento che anche se sei un professionista della sicurezza come un umano, è probabile che tu faccia degli errori e la tua soluzione non testata subirà una revisione molto inferiore rispetto a una soluzione già consolidata.

Quindi qual è il modo giusto per farlo? Esistono già più programmi di gestione password che lo fanno. Generano una chiave di crittografia dalla password principale con una funzione di derivazione della chiave (come PBKDF2, bcrypt o scrypt), quindi crittografare le password con questa chiave (ad esempio con AES).

Ora, qual è il problema specifico con il tuo schema? È facile alla forza bruta. Presumo che un utente malintenzionato conosca il nome utente, quindi l'utilizzo non aggiunge sicurezza. Quello che ti rimane è la password che viene utilizzata come offset nel file. L'entropia della password non sarà più lunga della lunghezza del file (chiamiamola N ), dal momento che jumpig dice 2N + 5 caratteri sarà uguale a saltare semplicemente 5 caratteri (sto assumendo che ti avvolgi quando raggiungi la fine del file). Se si desidera che un utente malintenzionato debba provare un miliardo di password, è necessario un file da 1 GB.

Un KDF è progettato per rallentare la forza bruta, ma accettabilmente veloce se lo si esegue solo una volta. L'unico modo per rallentare lo schema è rendere il file sempre più grande. Questo non è pratico, dal momento che aggiungerà la stessa quantità di spese generali, non importa se si prova solo una password o se si tenta milioni.

Questo schema non è in alcun modo più sicuro dell'approccio provato e testato. Usa quello.

    
risposta data 10.05.2016 - 08:16
fonte

Leggi altre domande sui tag