Ciao ragazzi, perdonate il titolo fantasioso e il fatto che questa discussione è stata già postata, ma sfortunatamente negli ambienti in cui l'ho fatto non mi è stato fornito un supporto adeguato.
Ho inventato un nuovo tipo di implementazione logica per lo storage delle password, invece della solita combinazione user/password.
Volevo dei consigli da voi, sia perchè lo possiate confutare e solo nel caso fosse effettivamente più sicuro, vorrei implementarlo nel kernel UNIX al posto di quello attuale (solo che non posso leggermi tutto il kernel, perciò se avete articoli utili per ciò che riguarda l'astrazione del login linkatemi pure per favore).
Cominciamo con una premessa: è ovvio che il server deve essere sicuro, l'implementazione è solo una soluzione aggiuntiva nel quale l'attaccante è riuscito a bypassare le misure precedenti: come lo può essere criptare una password, o disabilitare eventuali direttive, .
Ho creato un POC in MySQL/MariaDB, perchè secondo me rende bene il concetto ma si può ovviamente implementare anche in NoSQL, o addirittura modificando la struttura della gestione delle password in /etc/shadow utilizzando il nono campo come indice del file che contiene delle password randomiche, fra cui quella dell'utente (.
File .SQL (Ho semplificato il più possibile il codice per rendere il tutto il più comprensibile possibile: se non volete incorrere in concorrenze se effettuate un inserimento massivo di utenti deve essere applicato il LOCK)
Nella teoria se l'attaccante accede ai dati privati a volte si ritrova a dover decriptare la password dell'utente interessato (e ogni tanto lo fa come ultima spiaggia nel caso il server sia ben configurato e protetto), mentre così si ritrova con n passwords non sapendo quale è quella che deve decriptare.
Per esempio in sistemi amministrativi o login root potrebbero auto-generare nMila password hash "fake".
Ma rimando ad un altro utente che spiega benissimo il suo funzionamento:
MItaly ha scritto:
Mm al di là del codice specifico, se ho ben capito la tua idea sarebbe non associare esplicitamente l'hash di salt+password all'utente, ma tenerli "alla rinfusa" in un'unica tabella, e usare il salt per evitare collisioni (oltre agli usuali problemi di sicurezza che risolve il salt).
Il miglioramento di sicurezza dovrebbe derivare dal fatto che, mancando l'associazione utente-password, dovrebbe essere più complesso cercare di craccare una password di un utente specifico, dato che non sai qual è l'hash corrispondente, ed è inoltre possibile aggiungere degli hash aggiuntivi "per depistaggio" alla tabella.
Confutazione del mio modello da parte di un utente:
Scara95 ha scritto:
Qualsiasi password restituisca uno degli hash presenti nella tua tabella hashes viene accettata, quindi invece di rendere il tutto più sicuro l'hai reso meno sicuro perché ci sono più possibilità fra cui scegliere
Non credo, hai letto il mio codice?
Contando che viene generate anche un salt (che possiamo, perchè no, rendere univoco), in questo caso non esisterà mai una combinazione salt+password che dia il risultato di un'altra chiave UNIVOCA della hash.
Mentre quanto è probabile la collisione di 255 chars di salt + [numero di stringhe che fanno da brute force per trovare una password qualsiasi], possa trovare una correlazione?
Googlando un pò ho anche
trovato questo
Dove dice:
A hash function accepts inputs of arbitrary (or at least very high) length, and produces a fixed-length output. There are more possible inputs than possible outputs, so collisions must exist. The whole point of a secure hash function is that it is "collision resistant", which means that while collisions must mathematically exist, it is very very hard to actually compute one. Thus, there is no known collision for SHA-256 and SHA-512, and the best known methods for computing one (by doing it on purpose) are so ludicrously expensive that they will not be applied soon (the whole US federal budget for a century would buy only a ridiculously small part of the task).
Il rischio di questa collisione di cui parli, teoricamente, è attualmente, fortemente improbabile per non dire impossibile.
Però siccome vogliamo fare le cose per bene, ipotizziamo di voler scongiurare l'improbabile:
Se io imponessi input di lunghezza fissa (password+salt = [sempre stesso numero di caratteri]) potrei prevenire la (im)probabilità matematica di collisione, se si, quale è questa lunghezza?
Grazie a chiunque dimostrerà interessamento.
========================================================================================================
Si può chiudere.
Il metodo si può essere utile per non rilevare la password in chiaro (siccome bisognerebbe cercarla fra tante), però come una doppia lama fornisce nHash con cui cercare di collidere, quindi direi che il metodo è
decisamente da buttare .
Ringrazio,
minomic,
Scara95 e
MItaly ancora per il tempo speso, mi hanno permesso di evitare di buttare tempo in una implementazione seria dell'algoritmo.