Domanda

Devo archiviare le password del database in un file di configurazione. Per ovvi motivi, voglio crittografarli (preferibilmente con AES). Qualcuno conosce un'implementazione di Delphi che è facile da introdurre in un progetto esistente con > 10.000 righe di codice sorgente storicamente sviluppato (URGH!)?

Chiarimento: facile significa aggiungere l'unità al progetto, aggiungendo max. 5 righe di codice in cui viene letto il file di configurazione ed è fatto con esso. Non dovrebbe richiedere più di 15 minuti.

Un altro chiarimento: la password è necessaria per creare una connessione al db, non per supportare uno schema di gestione degli utenti per l'applicazione. Quindi usare gli hash non aiuta. Il motore db verifica se la password è valida, non l'app.

È stato utile?

Soluzione

Seguo la raccomandazione per la libreria DCPCrypt di David Barton . L'ho usato con successo in diversi progetti e non ci vorranno più di 15 minuti dopo aver letto gli esempi di utilizzo. Utilizza la licenza MIT, quindi puoi usarla liberamente in progetti commerciali e altro. DCPCrypt implementa una serie di algoritmi, incluso Rijndael, che è AES.

Esistono anche molte implementazioni autonome (singole unità) googlable - la domanda è di quale ti fidi, a meno che tu non sia disposto a verificare tu stesso la correttezza di una particolare biblioteca.

Altri suggerimenti

Ai fini tipici dell'autenticazione, non è necessario archiviare le password, è necessario solo verificare se la password immessa dall'utente è corretta. In tal caso, puoi semplicemente archiviare una firma hash (ad esempio MD5) e confrontarla con la firma della password inserita. Se le due firme corrispondono alla password inserita è corretta.

La memorizzazione di password crittografate può essere pericolosa perché se qualcuno ottiene il tuo "master" password possono recuperare le password di tutti i tuoi utenti.

Se decidi di usare MD5 puoi usare MessageDigest_5.pas che viene fornito con Delphi (almeno è incluso nella mia copia di Delphi 2007). Esistono anche altre implementazioni con il codice sorgente di Delphi tra cui scegliere.

Penso che Turbopower LockBox sia una libreria eccellente per la crittografia:

http://sourceforge.net/projects/tplockbox/

Non so se è troppo grande per i tuoi usi, ma è molto facile da usare e puoi crittografare una stringa con 5 righe di codice. È tutto negli esempi.

TOndrej ha l'approccio giusto. Non si dovrebbe mai archiviare una password usando un cifrario reversibile. Come è stato correttamente sottolineato, se il tuo "maestro" la chiave è stata mai compromessa, l'intero sistema è compromesso. L'uso di un hash non reversibile, come MD5, è molto più sicuro e puoi archiviare il valore di hash come testo in chiaro. È sufficiente eseguire l'hashing della password immessa e confrontarla con l'hash memorizzato.

Ho sempre usato Turbopower Lockbox. Funziona bene e molto facile da usare. In realtà lo uso esattamente per la stessa cosa, memorizzando una password in un file di testo di configurazione.

http://sourceforge.net/projects/tplockbox/

TurboPower LockBox 3 (http://lockbox.seanbdurkin.id.au/) utilizza la salatura automatica. Consiglio contro il DCPCrypt di Barton perché gli IV non sono salati. In alcune situazioni questo è un grave difetto di sicurezza.

Contrariamente a un inizio precedente, l'implementazione di AES di LB3 è pienamente conforme allo standard.

Ho usato questa libreria , molto veloce da aggiungere. Ma wiki mostra alcune altre soluzioni.

Anche se esegui la crittografia, mi sembra che la tua chiave di decrittazione e la password crittografata saranno entrambe nell'eseguibile, il che significa che in nessun modo è solo la sicurezza dell'oscurità. Chiunque può prendere la chiave di decrittazione e le password crittografate e generare le password non elaborate.

Quello che vuoi è un hash unidirezionale.

Solo un promemoria.

Se non hai bisogno di interagire con altri crypt libs, DCP o LockBox farebbero il lavoro.

MA

se ne hai bisogno per essere pienamente conforme alle specifiche rinjdael, dimentica i componenti gratuiti, sono un po '"schifosi" il più delle volte.

Come altri hanno sottolineato, per scopi di autenticazione dovresti evitare di archiviare le password usando la crittografia reversibile, cioè dovresti solo memorizzare l'hash della password e controllare l'hash della password fornita dall'utente contro l'hash che hai memorizzato. Tuttavia, questo approccio ha uno svantaggio: è vulnerabile agli attacchi arcobaleno , nel caso in cui un attaccante dovesse impadronirsi del database dell'archivio password.

Quello che dovresti fare è memorizzare gli hash di un valore salt prescelto (e segreto) + la password. Ad esempio, concatena il salt e la password, hash il risultato e archivia questo hash. Durante l'autenticazione, fai lo stesso: concatena il tuo valore salt e la password fornita dall'utente, l'hash, quindi controlla l'uguaglianza. Questo rende gli attacchi da tavolo arcobaleno irrealizzabili.

Naturalmente, se l'utente invia password attraverso la rete (ad esempio, se stai lavorando su un'applicazione web o client-server), non dovresti inviare la password in chiaro, quindi invece di archiviare l'hash (salt + password) è necessario archiviare e verificare l'hash (salt + hash (password)) e fare in modo che il client pre-hash la password fornita dall'utente e inviarla attraverso la rete. Ciò protegge anche la password dell'utente, qualora l'utente (come molti altri) riutilizzi la stessa password per più scopi.

Consiglio di usare un qualche tipo di sale. Non archiviare crypt (password) nel file di configurazione, ma installato in questo store crypt (salt + password). Come "salt" puoi usare qualcosa che è necessario per aprire il database, ad es. db_name + nome_utente. Per la funzione cripta puoi usare un noto algoritmo come AES, Idea, DES o qualcosa di semplice come xoring di ogni byte con byte da qualche altra stringa, quella stringa sarà la tua chiave. Per renderlo più diverso da risolvere è possibile utilizzare alcuni byte casuali e archiviarli.

Quindi, per archiviare:

  1. init_str: = 5 byte casuali
  2. new_password: = salt + password // salt: = nome_db + nome_utente
  3. crypted_password = xor_bytes (init_str + new_password, 'my keyphrase')
  4. crypted_password: = init_str + crypted_password
  5. archivia crypted_password in config, dato che saranno byte che puoi esadecimare o base64

E per connettersi:

  1. dividi i dati letti dalla configurazione in init_str e crypted_password
  2. new_password = xor_bytes (init_str + crypted_password, 'my keyphrase')
  3. password: = rimuovi (nome_db + nome_utente) da new_password

Ovviamente Nick ha ragione: presumo solo che tu sappia cosa stai facendo quando dici che vuoi spendere tutti i 15 minuti per implementare una soluzione di sicurezza. La libreria DCPCrypt implementa anche una serie di algoritmi di hashing se decidi di seguire quella (migliore) rotta.

Un paio di soluzioni:

  • Non archiviare affatto la password. Se il database supporta integrato autenticazione, usala. Il processo può essere impostato per l'esecuzione con uno specifico identità ed essere automaticamente autenticato dal database
  • Utilizza archivi certificati Windows e a certificato per crittografare la password. Se si memorizza la chiave utilizzata per crittografare la tua password nella tua applicazione, hai comunque poca sicurezza, devi proteggere anche la chiave.

Devi memorizzarlo in un posto dove solo l'utente corrente ha accesso.

Fondamentalmente ci sono due modi per farlo:

  1. Conservalo in un File crittografato EFS .
  2. Conservalo nella archiviazione locale sicura .

Internet Explorer utilizza 2. Ma se è possibile ottenere l'accesso locale, è possibile decrittografare sia 1. che 2. se si dispone della chiave master e dell'algoritmo corretti (ad esempio, iepv può accedere alle password di Internet Explorer).

Quindi:
Se possibile, evitare di archiviare le password.
Cerca prima le alternative (come l'autenticazione di Windows, i servizi di directory, ecc.).

- Jeroen

Un demo semplice ma per la maggior parte delle applicazioni è fornito dalla demo di Embarcadero: https://edn.embarcadero.com/article/28325

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top