Alternativa adatta a CryptEncrypt
https://stackoverflow.com/questions/17670
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Nel nostro prodotto abbiamo una situazione in cui per molto tempo alcuni dati sono stati archiviati nel database dell'applicazione come stringa SQL (scelta tra MS SQL server o sybase SQL ovunque) che è stata crittografata tramite la funzione API di Windows CriptaCrittografa. (diretto e decifrabile)
Il problema è che CryptEncrypt può produrre NULL nell'output, il che significa che quando viene archiviato nel database, le manipolazioni delle stringhe ad un certo punto troncheranno il CipherText.
Idealmente vorremmo utilizzare un algoritmo che produca CipherText che non contenga NULL in quanto ciò causerà la minima quantità di modifiche ai database esistenti (modifica di una colonna da stringa a binaria e codice per gestire il binario anziché le stringhe) e semplicemente decrittografare i dati esistenti e crittografarli nuovamente con il nuovo algoritmo al momento dell'aggiornamento del database.
Non è necessario che l'algoritmo sia il più sicuro, poiché il database si trova già in un ambiente ragionevolmente sicuro (non una rete aperta/inter-web) ma deve essere migliore di ROT13 (che riesco quasi a decifrare nella mia testa Ora!)
modificare:a proposito, qualche motivo particolare per cambiare il testo cifrato in testo cifrato?il testo cifrato sembra più ampiamente utilizzato...
Soluzione
Qualsiasi algoritmo semi-decente finirà per avere una forte possibilità di generare un valore NULL da qualche parte nel testo cifrato risultante.
Perché non fare qualcosa del genere codifica base-64 il blob binario risultante prima di persistere nel DB?(implementazione di esempio in C++).
Altri suggerimenti
Memorizzare un hash è una buona idea.Tuttavia, per favore leggi sicuramente quello di Jeff Probabilmente stai memorizzando le password in modo errato.
Questo è un percorso interessante OJ.Stiamo esaminando la fattibilità di un metodo irreversibile (assicurandoci comunque di non recuperare esplicitamente i dati da decrittografare), ad es.basta memorizzare un hash per confrontarlo su un invio
Sembra che lo sviluppatore che si occupa di questo avvolgerà la crittografia esistente yInc per preservare l'integrità della tabella poiché i dati devono essere recuperabili, e questo evita tutto quel disordine con infinite-improbab....uhhh modifica dei tipi di colonne su installazioni trincerate.Saluti ragazzi
