È un problema che ho seguito, nel senso che ho seguito la discussione, fin dall’inizio. Non ne ho postato nulla su Le Alternative perché mi sembrava troppo tecnico da spiegare ma è comunque interessante quanto successo. È interessante anche il fatto che Signal ha un po’ ignorato il tutto fino a che la cosa non è montata eccessivamente, il che non depone troppo a favore di Signal. Non tanto per quel che riguarda la sicurezza ma, come troppo spesso accade, su quanto poco seguano la comunità e le richieste della stessa.

L’articolo di Il Software

Ci sono voluti diversi anni prima che Signal si attivasse per proteggere il database dei messaggi della versione desktop. Molti lo consideravano un problema non da poco perché la chiave di decodifica era salvata in chiaro sui sistemi Windows e macOS.

Fino ad oggi gli sviluppatori dell’apprezzata app di messaggistica Signal, in passato consigliata anche dalla Commissione Europea ai suoi dipendenti, hanno sempre gettato acqua sul fuoco su un problema che emerse addirittura nel 2018. Il client desktop per Windows e macOS si appoggia a un database SQLite, utilizzato per memorizzare i messaggi dell’utente.

Il contenuto di tale database è decodificabile soltanto con un’apposita chiave che però, ed è questo che ha fatto sobbalzare molti esperti, è conservata in un semplice file di testo, senza alcuna protezione. Si chiama %appdata%\Signal\config.json su Windows e ~/Library/Application Support/Signal/config.json su macOS.

Se Signal può accedere a questa chiave, può farlo anche qualsiasi altro utente o programma in esecuzione sul computer, rendendo il database cifrato praticamente inutile. Una soluzione proposta dal ricercatore Nathaniel Suchy era di cifrare il database locale con una password fornita dall’utente, che non sarebbe stata memorizzata da nessuna parte, come avviene con i software di backup cloud, i browser Web, i gestori di password e i portafogli di criptovalute.

Continua su Il Software

  • skariko@feddit.itOPM
    link
    fedilink
    Italiano
    arrow-up
    3
    ·
    edit-2
    6 months ago

    Ma il punto 3 secondo me sarebbe estremamente corretto se non stessimo parlando di una issue di GitHub del 2018.