Questo sarebbe abbastanza sicuro? (Modulo ZF3 e Doctrine usando halite)

Question

Questo sarebbe abbastanza sicuro? (Modulo ZF3 e Doctrine usando halite)

#1 da (1 voti)

0

Recentemente PHP7.2 è stato rilasciato con la libreria Sodium inclusa per la crittografia.

Naturalmente c'erano già dei moduli di crittografia disponibili, anche lavorando con Zend Framework 2 o Symfony. Avevamo bisogno di un'implementazione per Zend Framework 3 e non volevamo affidarci alle nostre idee sui metodi di crittografia, abbiamo creato una ZF3 & Doctrine 2 module che usa implementazione della crittografia di paragonie .

Lo scopo, al momento, è di essere in grado di crittografare e decodificare automaticamente su lettura / scrittura di determinate proprietà, rilevate tramite un listener collegato a Doctrine ORM.

Il modo in cui lo abbiamo impostato è il seguente:

default

Ricevi una stringa (non crittografare null )
Aggiungi in-code (config) salt alla stringa
Utilizza la chiave privata in-code (config) per la crittografia

Ovviamente, non è il metodo più efficace per estendere una stringa, ma per assicurarsi di poter crittografare i dati contrassegnati con un tag utilizzando le impostazioni predefinite. Dati come il nome di una strada.

Opzioni

Ricevi una stringa (non crittografare null )
Aggiungi 32 salmastra e / o pepe prima (e dopo) stringa (memorizzata in una tabella db separata, anche se i record sono collegati tramite chiave esterna)
Aggiungi in-code (config) salt alla stringa
Utilizza la chiave privata in-code (config) per la crittografia

Questo è il modulo che noi, in realtà solo io, abbiamo creato. L'effettiva implementazione della crittografia / decrittografia inizia su qui .

processFields funzione - decide se cripta / decodifica, passa valori e, in decrittografia, prova un cast di tipi (per supportare il valore tipi ) per restituire il tipo di valore originale
encrypt funzione - decide se sale e / o pepe devono essere aggiunti in base alle opzioni passate. Quindi chiama " encrypt " sull'adattatore.
decrypt funzione - decide se sale e / o pepe sono stati aggiunti in base alle opzioni passate. Rimuove dalla stringa per restituire la stringa originale da crittografare.
Adattatore Halite - Questa è la crittografia / decrittografia predefinita adattatore

Perché sto chiedendo?

Perché spero di aver capito tutto di più e di aver creato qualcosa di fantastico. Tuttavia, poiché non sono un esperto di crittologia e non abbiamo una tale persona in-house, ho pensato di chiedere qui, sperando di ottenere un feedback.

Il codice è fornito così com'è e open source. È estensibile e riutilizzabile in modo che altri utenti possano utilizzare lo stesso servizio, ma possono utilizzare il proprio adattatore di crittografia. Tuttavia, non vorrei che usassero qualcosa di sub-par.

php encryption

posta rkeet 10.04.2018 - 12:02

fonte

1 risposta

Leggi altre domande sui tag php encryption

SMTU AUTH e utente compromesso Disabilita l'accesso ospite in / directory Ubuntu [duplicato]

score 1 · Accepted Answer

Cosa hai fatto bene

Stai utilizzando una libreria

Hai scelto di usare una libreria per fare la crittografia per te. Buon lavoro! In qualche modo le persone continuano a rovinare tutto. Non essere un Dave , non eseguire mai la tua crittografia personale (a meno che tu non sia veramente veramente) cosa stai facendo).

Cosa hai sbagliato

Ti stai abusando della terminologia

Un sale viene utilizzato quando si eseguono le password di hashing. Deve essere univoco per password e quindi non può essere posizionato in una configurazione. Un pepe è simile a un sale, ma è lo stesso per ogni password, quindi può trovarsi in una configurazione. Nessuno di questi ha nulla a che fare con la crittografia.

Stai provando a "migliorare" la crittografia senza comprenderla

L'aggiunta di un valore univoco a ogni stringa non è necessaria perché gli algoritmi di crittografia (buoni) utilizzano i vettori di inizializzazione o gli strumenti necessari per randomizzare i loro uscita quando si crittografa dati duplicati. Halite utilizza XSalsa20 MACed con un hash BLAKE2b con chiave. Non cercare di renderlo migliore, semplicemente aggiungerai complessità alla tua implementazione senza motivo.

C'è una ragione legittima per tamponare i dati prima della crittografia, e cioè nascondere la lunghezza dei dati. Alcuni algoritmi di crittografia consentono a un utente malintenzionato di determinare la lunghezza del testo in chiaro arrotondato a un numero di byte, mentre altri consentono di determinare la lunghezza esatta del testo in chiaro. In questo caso, tuttavia, è necessario eseguire il rilievo di tutti i dati sulla stessa lunghezza (o un multiplo della stessa lunghezza) e il padding non deve essere casuale.