L'aggiunta di testo in chiaro a sale è altrettanto sicura di quando si aggiunge sale a testo in chiaro

Sì, fondamentalmente non vi è alcuna differenza di sicurezza rispetto a ciò che si sta facendo in quanto il risultato avrà la stessa "forza" dell'hash.

Operativamente, sebbene i due metodi restituiscano hash completamente diversi, il che potrebbe costituire un problema se si userà questo per autenticarsi su un sistema diverso. Aggiungere il sale è il modo convenzionale per farlo, se lo si inverte si avranno problemi di compatibilità.

Se hai a che fare con questa domanda, è più probabile che tu non stia sbagliando: stai facendo ruotare il tuo codice di hashing della password . Questo è male, perché:

1. L'hashing della password è un argomento complicato che la maggior parte delle persone sbaglia;
2. Avresti reinventato la ruota, invece di usare una ben nota e studiata funzione di hashing della password dedicata come PBKDF2 o bcrypt .

Queste ultime funzioni di solito hanno interfacce che assomigliano a questo:

• Argomenti:
  • Password testo in chiaro
  • Salt
  • Fattore di costo
• Ritorno:
  • Un tag di verifica password

Prendono la password e salgono come argomenti separati, quindi non è necessario aggiungerne uno all'altro in qualsiasi ordine. In effetti, nessuno dei due aggiunge la password e il sale in entrambi i modi che suggerisci.

È, supponendo che l'hash sia della stringa completa . Guarda cosa succede quando usi una password hasher che usa solo i primi 8 caratteri del suo input (questa è la 'tradizionale' (salata) funzione hash della password Unix):

$ mkpasswd -s -S 00 <<<salt.password
002y63GMEzTFg
$ mkpasswd -s -S 00 <<<salt2.password
00OHzu67zQp/Q

Bene: questi due sono diversi.

$ mkpasswd -s -S 00 <<<password.salt
00xQPHYlVDIw6
$ mkpasswd -s -S 00 <<<password.salt2
00xQPHYlVDIw6

Spiacenti.

Nota sopra che sto passando un sale fisso a mkpasswd ; questo è così che il suo sale generato a caso non interferisce con il principio che sto dimostrando con salt e salt2 anteposto o aggiunto alla password.

NB. Non sto suggerendo che qualcuno usi effettivamente la vecchia funzione crypt() per le password di hashing - in parte per il problema di troncamento mostrato qui, ma anche perché il sale è troppo corto, l'hash risultante è troppo corto e l'algoritmo è molto troppo veloce per l'hardware di oggi (una funzione di hash della password deve essere lenta, per ostacolare il cracking, ma non così lentamente da frustrare gli utenti legittimi).