Dovresti rendere pubblico l'algoritmo?

Cercare di nascondere i dettagli dell'implementazione (come l'algoritmo di hashing che usi) per preservare la sicurezza è la definizione stessa di sicurezza attraverso l'oscurità . Vi è ampio consenso sul fatto che l'oscurità non dovrebbe essere l'unica linea di difesa.

Se hai bisogno di mantenere segreto l'algoritmo hash, stai sbagliando e devi scegliere un algoritmo di hashing migliore. Quando usi un buon algoritmo, non c'è motivo di non dirlo al mondo perché non saranno in grado di rompere gli hash in ogni caso.

Nota anche che nel tuo caso il sale ti darà via. Se qualcuno si impossessa del tuo database, sarà in grado di leggere quale algoritmo è stato usato da quello. Quindi l'oscurità non fa forzare brutalmente più strong qui. La pubblicità di uno schema debole, tuttavia, potrebbe incoraggiare gli aggressori. Un strong potrebbe avere l'effetto opposto. Il punto che Mike Goodwin fa in la sua risposta dovrebbe anche essere preso in considerazione.

Crypt () è sicuro?

La domanda pertinente da porsi è quindi se crypt() è abbastanza sicuro. Diamo un'occhiata al manuale PHP :

password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and compatible with existing password hashes. Use of password_hash() is encouraged.

Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

La funzione utilizza algoritmi diversi a seconda di come si formatta il sale. Alcuni algoritmi sono molto deboli e quelli forti potrebbero non essere disponibili su tutti i sistemi. Quindi, a seconda dell'algoritmo utilizzato, ci sono un certo numero di problemi qui:

• Per alcuni algoritmi crypt() applica solo un round di hashing. È troppo veloce e consentirà un attacco di forza bruta.
• In alcune circostanze crypt() utilizzerà MD5, che è noto per essere debole.
• Solo l'utilizzo dei primi otto caratteri annulla completamente i vantaggi delle password lunghe.

Pertanto suggerisco di passare a password_hash() . Ti permette di usare bcrypt - un algoritmo collaudato. Quindi puoi dire con orgoglio al mondo del tuo piano di hashing.

@Anders è corretto che la sicurezza attraverso l'oscurità non sia affatto una sicurezza.

Detto questo, la pubblicazione dei dettagli di implementazione fornisce informazioni agli aggressori che potrebbero utilizzare se vengono rilevate vulnerabilità nell'implementazione in futuro o se l'utente malintenzionato presenta vulnerabilità zero-day.

Pensaci in questo modo: molti test di penetrazione iniziano con una fase di ricognizione che scopre protocolli, tecnologie e versioni in uso. Queste informazioni vengono quindi utilizzate per tentare exploit noti, se ce ne sono.

Se questo tipo di informazioni è utile ai pen-tester, allora è anche utile per gli aggressori. Perché rendere le loro vite più facili facendo parte del loro lavoro per loro? A parità di condizioni, è probabile che si concentrino sui sistemi che rendono le cose più facili per loro prima di quelli che li rendono più difficili da lavorare.

Nel complesso, a meno che non vi sia un chiaro beneficio per voi o il vostro datore di lavoro nella pubblicazione dei dettagli tecnici, li terrei privati. Lavora su una base di necessità di conoscenza.

Giusto per ripetere però, per evitare downvotes - Sono completamente d'accordo sul fatto che la sicurezza attraverso l'oscurità non è affatto una sicurezza ;-p

Non solo puoi , devi assolutamente .

Il principio di Kerckhoff impone che l'unica cosa valida per la sicurezza del tuo sistema su cui poggiare è la chiave segreta e che qualsiasi sistema sicuro dovrebbe essere progettato con l'idea che "il nemico conosce il sistema" si presume che sia vero in anticipo.

Quindi, secondo il principio di Kerckhoff, condividere i dettagli del sistema non può renderlo meno sicuro, perché devi assumere in anticipo che il nemico conosce già il sistema, perché i cattivi sono disposti a hackerare e commettere spionaggio per accedere al funzionamento di esso. Ciò che la condivisione può fare, tuttavia, aiuta a rendere il tuo più sicuro, condividendolo con i buoni, esperti che sarebbero in grado di analizzarlo e rivederlo. Se ci sono vulnerabilità, bravi ragazzi e cattivi li troveranno entrambi, ma i cattivi non li condivideranno con voi in modo da poterli aggiustare.

Pertanto, se vuoi che il tuo sistema sia sicuro, non puoi permetterti non di condividere come funziona.