Memorizza le password come numeri interi

0

Mi è venuta in mente questa idea di poter memorizzare password come numeri interi che occupano 4 o 8 byte anziché un hash che richiede 150 byte o qualcosa del genere. Ho scritto questa funzione che converte una stringa in un intero basato su alcuni calcoli elementari

function pass($pass) {
    $value = 0;

    for ($i = 0, $l = strlen($pass); $i < $l; $i++) {
        $value += pow(ord(~$pass[$i]), 1/2);
    }

    return (int)round(pow($value, (int)('1.' . $value)) * 10000000000);
}

var_dump(pass('M'));
var_dump(pass('m'));

int(133416640641)
int(120830459736)

Per come la vedo io per essere hackerato prima, l'hacker deve conoscere il valore int memorizzato per la password e l'algoritmo. Possono ottenere il valore sia se hackerano il mio database o prendiamo un vecchio file di backup che è noto per essere l'exploit più comune (immagino) ma ancora se non conoscono l'algoritmo non sarebbero in grado di romperlo?

Non penso sia possibile riportare un valore convertito alla stringa originale in quanto sarebbe un problema con la complessità di molti caratteri contenuti nella stringa, giusto?

L'altra possibilità è che inseriscano accidentalmente un valore che si converte allo stesso valore della password originale, teoricamente suppongo che ci dovrebbe essere una quantità infinita di stringhe che possono essere convertite allo stesso valore ma non sono sicuro riguardo le reali possibilità che ciò accada, così come questo problema è presente anche negli algoritmi di hashing noti come collisione.

Come probabilmente hai già intuito sono molto lontano da un esperto di sicurezza e suppongo che questo sia tutto spazzatura di cui sto parlando adesso, ma voglio sapere perché?

    
posta php_nub_qq 24.06.2016 - 10:58
fonte

2 risposte

3

Questa è sicurezza attraverso l'oscurità e in violazione di principio di kerchoffs .

if they don't know the algorithm they wouldn't be able to crack it?

Forse. E forse l'analisi delle voci porta alla rivelazione dell'algoritmo.

E una volta che un utente malintenzionato ottiene l'algoritmo - tramite l'analisi, accedendo al tuo server, perché lo hai postato qui - hanno accesso automatico a tutte le password.

Questo non è il caso dell'hashing, perché una delle proprietà importanti dell'hash crittografico è che sono lenti .

The other possibility is if they accidentally input a value that converts to the same value of the original password, theoretically I suppose there should be an infinite amount of strings that can get converted to the same value but I'm not sure about the real chances of this happening, as well as this problem is also present in hashing algorithms known as collision.
[...]
integers which take up 4 or 8 bytes as opposed to a hash that takes like 150 bytes or something

Se riduci le dimensioni, le collisioni diventano più probabili, dato che hai ancora le stesse dimensioni dell'input, ma un'area di destinazione più piccola.

As you probably guessed already I'm very far from a security expert

Ecco perché non dovresti mai lanciare il tuo (ma io Suppongo che questa sia più una questione teorica da imparare, non qualcosa che si vuole effettivamente usare nella pratica).

    
risposta data 24.06.2016 - 11:12
fonte
1

Se utilizzi 4 o 8 byte di numeri interi per memorizzare le tue password, stai rendendo molto più semplici i lavori dei forzuti. Perché, se capisco la tua situazione correttamente, un utente malintenzionato dovrebbe semplicemente creare una stringa in modo che il suo valore convertito (convertito per verificare con i valori nel DB) corrisponda al valore della password memorizzata.

Considerando la potenza di calcolo nei computer di oggi, si potrebbe trovare molto rapidamente una stringa di confronto rispetto alla propria password da 8 byte, non sto nemmeno parlando di quanto sia facile controllare il valore a 32 bit (4 byte).

    
risposta data 24.06.2016 - 11:14
fonte

Leggi altre domande sui tag