Un sale può mantenere la pseudo-casualità dopo essere stato modificato?

Question

Un sale può mantenere la pseudo-casualità dopo essere stato modificato?

#1 da (1 voti)

1

TL; DR: Quanto può una funzione (come quella in basso) modificare una stringa inizialmente casuale prima che quella stringa diventi inutile come sale per l'hashing della password? C'è una regola generale?

# Function generates a random string of characters using urandom(), then converts each
# character to its hexadecimal equivalent, and then converts *those* digits back to characters.
# Each hexadecimal character-string is then concatenated into a super-string, excluding the '0x' 
# prefixes. The function returns the first 64 characters of the super-string.

def hex_salt():
    raw_salt = os.urandom(500)
    hex_salt = ""
    trimmed_salt = ""

    for i in range(len(raw_salt)):
        dec_num = ord(raw_salt[i])
        hex_substring = str(hex(dec_num))
        hex_salt += hex_substring


    j=0
    while(len(trimmed_salt) < 64):
        if (hex_salt[j]=='0' and hex_salt[j+1]=='x') or (hex_salt[j]=='x'):
            j+=1
            continue

        trimmed_salt+=hex_salt[j]
        j+=1

    return trimmed_salt

Il motivo per cui chiedo è che sto usando il modulo hashlib di python per configurare un servizio di login per il mio sito web. Poiché i caratteri esadecimali sono più facili da gestire, voglio creare un sale casuale (usando os.urandom) e ricavarne un sale ugualmente casuale contenente solo caratteri esadecimali. Questo è il mio primo post qui, quindi mi scuso per tutti i peccati che ho senza dubbio commesso.

random salt sha256

posta AG Boling 02.07.2015 - 00:25

fonte

1 risposta

Leggi altre domande sui tag random salt sha256

Nuovo certificato SSL non affidabile su tutti i client Qual è il ruolo di RSA ed ECC in TLS 1.2? [duplicare]

score 1 · Accepted Answer

Cambiare semplicemente la rappresentazione del messaggio non dovrebbe ridurre l'entropia dato il significato sottostante dei dati non dovrebbe essere alterato. Ad esempio, potresti codificarlo in Base64 o ASCII senza problemi.

Tuttavia, per rispondere a questa domanda in generale:

How much can a function (such as the one below) modify an initially random string before that string

È più preoccupante come si modificano i dati piuttosto che quanto i dati sono cambiati. Se fai qualcosa che rende i dati più prevedibili, comprometterai la sicurezza del valore casuale. Ad esempio, è possibile invertire in modo sicuro i bit della stringa, ma se si sono rimosse tutte le sequenze di bit che non corrispondevano a un carattere ASCII A-Z, lo si renderebbe meno sicuro.

Nel tuo caso, non implementerei il mio schema di codifica personale: userei solo Base64 .