[RISOLTO] Transmission

[Stemby]

Da qui:

rpc-username e rpc-password definiscono le credenziali che l'utente dovrà inserire quando tenterà di usare il demone (qualora si sia abilitata l'autenticazione all'accesso). La nuova password va semplicemente scritta in chiaro tra virgolette; al primo avvio del demone, verrà automaticamente criptata via SHA-1 (iniziarà con una graffa).

Non sono riuscito a trovare riferimenti tecnici sull'algoritmo usato da Transmission per criptare la password. Qualcuno sa aiutarmi?

In particolare non credo che sia solo SHA-1, dato che la password di default è sempre "transmission", mentre la versione criptata è diversa da installazione a installazione. Immagino quindi che di mezzo ci sia un sale. La mia ipotesi trova un riscontro anche nella domanda di un altro utente qui.

Ritengo che sarebbe utile documentare più precisamente la cosa, visto che se si prova a fare un sha1sum di "transmission" non si ottiene la stringa proposta, e quindi chi legge la guida rimane per lo meno perplesso. Il massimo sarebbe fornire un esempio di ricostruzione da "transmission" all'hash trovato nel file di configurazione, usando strumenti esterni (sha1sum, altro?).

Grazie!

[Aki]

Qui il codice sorgente: http://sources.debian.net/src/transmiss ... l=953#L953, mentre la funzione che genera l'hash è http://sources.debian.net/src/transmiss ... l=126#L126.

Come puoi notare dal codice sorgente, è utilizzato un "salt" casuale.

[Stemby]

Grazie mille Aki, ma non essendo programmatore professionista ho difficoltà a cogliere il funzionamento. Riusciresti a spiegare l'algoritmo usato in termini semplici? Prometto poi di integrare la guida con queste nozioni.

Grazie!

[HAL 9000]

La funzione utilizza sha1 con un salt casuale di 8 byte in base64.

In sostanza la stringa rpc-password è composta dalla concatenazione del carattere "{" (che segnala che si tratta di un hash), l'hash in SHA1 della password e del salt, e poi il salt casuale utilizzato.

Ignoro sinceramente come si comporti nel dettaglio la libreria openssl. Nel codice ci sono due invocazioni separate (inizializzazione e poi un update per la password e uno per il salt), quindi il risultato potrebbe non essere lo stesso di calcolare l'hash direttamente sulla stringa risultante dalla concatenazione di password e salt.

Può essere testato molto facilmente, creando la stringa in un file (senza "a capo" finale):

Codice: Seleziona tutto

$ echo -n "transmissionSALT" > prova.txt
$ sha1sum prova.txt

dove "transmission" è la password di default (se non l'hai cambiata) e al posto di "SALT" usi gli ultimi 8 caratteri della stringa rpc-password nel file di configurazione di transmission.

E posso confermare che l'hash risultante è quello riportato nella stringa rpc_password prima del salt.

[Stemby]

Grazie, HAL 9000!

Fatto. Ovviamente ogni contributo ulteriore, se qualcosa non risultasse chiaro, è benvenuto.

Ciao!

[marcomg]

Non vorrei dire una cavolata ma non mi sembra che il salt sia codificato in base64, ma sono semplicemente 8 caratteri estratti dalla seguente stringa: "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ./" (che di fatto il "." non fa perte della codifica base64).

[HAL 9000]

No, non dici una cavolata. Sono stato impreciso: il salt utilizza sì un alfabeto di 64 caratteri, ma non segue nessuno standard "base64".

Comunque se invece usasse l'alfabeto corretto, generare 6 byte qualsiasi e convertirli in base64 o generare 8 caratteri casualmente appartenenti all'alfabeto base64 sarebbe equivalente, almeno per lo scopo usato e visto che la lunghezza non richiederebbe alcun padding.

Si potrebbe semplicemente sostituire nella guida "8 byte in base64" con "8 caratteri", "8 caratteri alfanumerici più '.' e '/'" o "8 caratteri in una base 64 (non standard)".

[Stemby]

Precisazione aggiunta.

Grazie di nuovo a tutti!