Perché l'hash MD5 inizia da $ 1 $ e SHA-512 da $ 6 $? Non è la debolezza in sé stessa? [duplicare]

Innanzitutto, c'è principio di Kerckhoffs che è sempre auspicabile:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

dove in questo caso la password è la chiave. Quindi non è un obiettivo mantenere segreto il cryptosystem.

In secondo luogo, ti sbagli su quelli che sono hash md5 o sha512; i valori memorizzati nel /etc/shadow sono md5crypt o sha512crypt, che implica una procedura di potenziamento (molti round di un hash md5 o sha512).

Ora se le tue quattro scelte sono MD5crypt, sha256crypt, sha512crypt e bcrypt (le scelte più popolari nei sistemi Linux), ecco quattro hash generati con $saltsalt$ (o equivalente) come salt e hashing della password not my real password :

>>> import crypt
>>> crypt.crypt('not my real password','$1$saltsalt')
'$1$saltsalt$4iXfpnrgHRXkrDbPymCE4/'

>>> crypt.crypt('not my real password','$5$saltsalt')
'$5$saltsalt$E0bMpsLR71z8LIvd6p2tD4LZ984JxyD7B9lPLhq4vY7'

>>> crypt.crypt('not my real password','$6$saltsalt')
'$6$saltsalt$KnqiStSM0GULvZdkTBbiPUhoHemQ7Q06YnvuJ0PWWZbjzx3m0RCc/hCfq54Ro3fOwaJdEAliX9igT9DD2oN1u/'

>>> import bcrypt
>>> bcrypt.hashpw('not my real password', "$2a$12$saltsaltsaltsaltsalt..")
'$2a$12$saltsaltsaltsaltsalt..FW/kWpMA84AQoIE.Qg1Tk5.FKGpxBNC'

Anche senza l'annotazione, è abbastanza semplice capire quale schema usano (md5crypt, sha256crypt, sha512crypt e bcrypt sono 34,55,98 e 60 caratteri rispettivamente lungo (nella codifica base64 con annotazione e salt). Quindi, a meno che tu non suggerisca di troncare l'hash, o di alterare le proprietà hash, l'annotazione per coerenza non perda alcuna sicurezza.Inoltre ti dà un metodo per aggiornare con garbo le password degli utenti.Se decidi che md5crypt non è più sicuro, puoi cambiare utente 'hash to bcrypt al prossimo login (e dopo un periodo di tempo disattiva tutti i conti lasciati su md5crypt) o se il tuo algoritmo come bcrypt (quando era $ 2 $) deve essere aggiornato, a causa di un difetto nella progettazione puoi facilmente identificare schemi difettosi quando lo schema fisso è andato a $ 2a $.

Peggio ancora, potresti provare a dire, ho intenzione di modificare sha512 con nuove costanti e chiavi rotonde. Ciò renderebbe superhard da rompere - giusto? No, rende semplicemente super difficile per te sapere che non hai introdotto accidentalmente una vulnerabilità principale. Se riescono a raggiungere il tuo / etc / shadow, probabilmente possono anche accedere alla libreria utilizzata per accedere e con il passare del tempo potrebbero decodificare il tuo schema di hashing e questo sarà MOLTO MOLTO più semplice di una password complessa.

Ancora una volta, il tempo previsto per la forza bruta di una frase segreta molto strong memorizzata nell'hash sha256 è O (2 ^ 256), ad esempio un miliardo di computer che fanno un miliardo di sha256critti per nanosecondo (ognuno dei quali ~ 5000 round di sha256), richiederebbero 300000000000000000000000 (3 x 10 ^ 23) volte l'età dell'universo per romperlo. E con sha512crypt, se ognuno degli atomi ~ 10 ^ 80 nell'universo osservabile facesse ciascuno un miliardo di cricche sha512 ogni nanosecondo, ci vorrebbe ancora 10 ^ 38 volte l'età dell'universo. (Questo presuppone che tu abbia una passphrase di entropia a 256-bit e 512-bit o superiore).

Oscurare quale hash è usato rende impossibile per il sistema autenticare la password per un utente legittimo.

Quando l'autenticazione della password tramite hashing in Unix è stata inventata per la prima volta, la funzione di hash della password è stata codificata per l'utilizzo di DES (ora non aggiornato). Se l'hash della password è derivato da qualsiasi altra funzione, deve esserci un identificatore per consentire al sistema di riconoscere quale algoritmo è stato utilizzato per generare l'hash.

Questo perché l'hashing della password è una funzione a senso unico. Ho sentito dire che aspettarsi di eseguire una funzione unidirezionale al contrario è come aspettarsi di gestire una fabbrica di salsicce all'indietro e far uscire i maiali dall'altra parte. Quindi, quando si va ad autenticare qualcuno che accede al sistema, è possibile solo eseguire la funzione di hashing in avanti e confrontare i risultati con ciò che è memorizzato in / etc / shadow.

Quindi quegli identificatori devono rimanere in chiaro, altrimenti verrà utilizzata la funzione di hashing errata, gli hash non corrisponderanno e nessuno potrà entrare nel sistema.

Il tentativo di oscurare l'implementazione dell'hash non fa altro che spostare il problema da

• Riesco a vedere per protocollo la funzione di hash è X ()

a

• Guardando il codice **, posso dire che la funzione di hash è X ()

** (o altro canale laterale di informazioni)

Se il tuo attaccante ha un modo per sondare il sistema, sarà quasi sicuramente in grado di capire l'algoritmo che stai usando. Il più semplice è semplicemente guardare il codice (codice sorgente o codice macchina), i metodi più complicati implicano l'uso di misurazioni temporali per differenziare la funzione utilizzata. Per usare l'analogia con il "nascondiglio" - basta prendere un po 'di attrezzatura sonora & Posso dire che prima ancora di entrare nell'edificio ci sono stanze sotterranee.

So che non volevi ascoltarlo, ma la realtà è "La sicurezza attraverso l'oscurità" fallisce inevitabilmente a causa dell'incapacità di oscurare sufficientemente, da ogni possibile approccio, entrambi gli approcci conosciuti oggi, o qualche approccio futuro.