aWallet Password Manager (Italiano)

NOTA: questa domanda è una sottoparte della domanda originale su aWallet Password Manager pubblicata su Cryptography.StackExchange. Come suggerito da @SEJPM , lo sto pubblicando qui poiché largomento della domanda è più adatto per InformationSecurity.StackExchange.


Dopo aver letto molti articoli su come aumentare la sicurezza dei miei account web, ho iniziato a utilizzare aWallet Password Manager per Android per eseguire il backup le mie password. Mi piacciono per i seguenti motivi:

  • Sono in grado di avere password di buona entropia : sono in grado di inserire un mix di lettere minuscole & MAIUSCOLE, cifre, caratteri speciali (spazi inclusi) e password ragionevolmente lunghe (10+ caratteri )
  • Il salvataggio delle mie password in modo sicuro mi consente di avere password distinte per ogni account web che altrimenti sarebbero impossibile. Ciò eviterebbe un effetto a cascata (dando via le credenziali di tutti gli account) che verrebbe creato se uno dei miei account, le cui credenziali di accesso condivido con diversi account, viene compromesso.

Inutile dire che questo secondo punto è discutibile perché avere tutte le credenziali archiviato in un unico posto introduce un singolo punto di errore e pone lo stesso rischio di reazione a catena menzionato in precedenza.


Data la mia conoscenza limitata della crittografia e i dubbi sulla privacy (dati i recenti episodi di furti online), voglio testimoniare la sicurezza di aWallet Password Manager prima di archiviare il mio Dati bancari / carta in esso. Ecco cosa rivendicano sulla loro pagina di Google PlayStore :

FUNZIONI DI SICUREZZA

• Tutti i dati sono crittografati, inclusi i nomi delle voci, le definizioni delle categorie e i dati stessi.

• Crittografa i dati utilizzando algoritmi AES e Blowfish con dimensioni della chiave di 256, 192 e 128 bit.

• Quando il file di dati viene decrittografato, vengono provate fino a tutte le combinazioni di algoritmo, dimensione della chiave e modalità operativa di cifratura (CBC, CFB, OFB e ECB) con la password principale per sbloccare il file di dati. rende gli attacchi di forza bruta più lunghi. Lapp stessa non memorizza alcun suggerimento sulleffettiva cifratura, dimensione della chiave o modalità di funzionamento della cifratura.

• Utilizza un “sale” generato casualmente combinato con la password principale. Salt aiuta per proteggere da attacchi di dizionario offline.

• La chiave per aprire il file di dati viene creata combinando la tua password principale con il “salt” a 512 bit. Il risultato è sottoposto ad hashing 1000 volte da SHA-256 Lhashing ripetitivo crea una forza bruta virare più difficile.

Anche se nessuno di questi punti ha molto senso per me, quel poco che so sulla crittografia mi dice che [per favore correggi io se “sbaglio] ripetere una tecnica di crittografia più volte non” t Matematicamente migliora la sicurezza ; può solo dare una falsa impressione di maggiore sicurezza.


E a causa di questa incoerenza, ho iniziato a dubitare della validità delle loro altre affermazioni. Le mie domande sono: –

  1. Esiste uno strumento / tecnica che potrei usare per tentare di decrittografare il file data.crypt utilizzato da unappWallet in modo da testare la sua sicurezza?
  2. aWallet non offre alcun proprio spazio di archiviazione cloud e ci consente di (facoltativamente) eseguire il backup del file data.crypt su Google Drive o Dropbox. Quanto sarebbe sicuro se utilizzo lautenticazione a due fattori per il mio account Google?
  3. In generale, è sicuro memorizzare le credenziali di accesso, i dettagli bancari o entrambi in un gestore di password?

Commenti

  • Lhashing ripetitivo che ti ha reso sospetto? Non è la stessa cosa della crittografia ripetitiva, ed è effettivamente una pratica standard. Vedere questo .
  • Is it safe to store login credentials or banking details or both in a password manager Non ‘ deve essere una sicurezza perfetta, deve essere meglio che creare la tua password e ricordarla.
  • ” tutte le combinazioni di algoritmo, dimensione della chiave e vengono provate le modalità di operazione di cifratura (CBC, CFB, OFB e ECB) ” Sembra idiota … perché non utilizzare una funzione di derivazione chiave adeguata?Il fatto che apparentemente ti permettano di usare ECB è unenorme bandiera rossa (e se non ‘ ti permettono di usare ECB, allora provare a decrittografare con esso non ‘ non fare nulla per rallentare lattaccante in ogni caso)
  • ‘ vorrei indicare a chiunque voglia commentare i dettagli crittografici di questo ” gestore di password ” al post collegato su Crypto.SE , dove vengono valutati e discussi questi problemi.

Risposta

Nota: questo post risponde effettivamente alle domande nella domanda e non commenta (molto) sulla sicurezza di aWallet. Ti suggerisco di visitare il Versione Crypto.SE di questa domanda per una revisione dei dettagli crittografici.

Cè uno strumento / tecnica che potrei usare per tentare di decrittografare il file data.crypt utilizzato da unappWallet in modo da testarne la sicurezza?

Una rapida ricerca non ha trovato nulla, quindi ho supponiamo che questo gestore di password non sia abbastanza grande / non abbia visto abbastanza ricerche per aver fatto scrivere a qualcun altro uno strumento per attaccare questo gestore di password.

aWallet non offre alcun proprio spazio di archiviazione cloud e ci consente di (facoltativamente) eseguire il backup del file data.crypt su Google Drive o Dropbox. Quanto sarebbe sicuro, dato che utilizzo lautenticazione a 2 fattori per il mio account Google?

Dipende molto.
Supponendo che unWallet “s le misure di sicurezza sono effettivamente buone e usi una password complessa e / o un file di chiave locale, quindi caricare il database delle password crittografate su un servizio cloud non danneggia la sicurezza, poiché la tua password e / o il tuo file di chiavi ancora proteggere le password. Ovviamente, lautenticazione e il controllo degli accessi aggiunti a questi servizi cloud significa che è probabile che solo tu e il provider abbiate accesso e di solito è nellinteresse del provider non perdere i file degli utenti.

In generale, è sicuro memorizzare le credenziali di accesso o i dettagli bancari o entrambi in un gestore di password?

Sì, moltissimo, se il gestore di password è decente.
Luso di un gestore di password ti consente di avere facilmente un unico, password complesse per sito Web, il che significa che è necessaria una compromissione del database delle password o del client locale. Come abbiamo già stabilito, una compromissione del backup è impedita dalla password complessa, quindi questo lascia il client compromesso come vettore per apprendere la password. Ma non appena il tuo client viene compromesso, tutte le scommesse vengono comunque annullate, perché lattaccante potrebbe semplicemente annusare la tua tastiera o monitorare / intercettare i tuoi dati di rete! Quindi, tutto sommato, hai poco da perdere e molto da guadagnare usando (buoni) gestori di password.

Se aWallet sia un buon gestore di password è una domanda diversa (e risolta su Crypto.SE).

Risposta

aWallet nello specifico: non usarlo. Il creatore ovviamente non sa cosa stanno facendo. Sceglierò solo una preoccupazione (ce ne sono diverse che probabilmente saranno più ovvie per People Smarter Than Me): potrebbe crittografare il tuo database in modalità ECB (a volte, ma non sempre).

Modalità ECB in particolare non è sicuro perché lo stesso testo in chiaro viene sempre crittografato con lo stesso testo cifrato. Pertanto, la modalità ECB “non nasconde bene i modelli di dati … non fornisce una seria riservatezza del messaggio , e non è affatto raccomandato per luso nei protocolli crittografici “.

Gestori di password in generale: usane uno. Ma scegline uno noto con una buona reputazione come 1Password, LastPass, KeePass, Dashlane, ecc. O almeno usane uno creato o consigliato da una nota società di sicurezza o da un ricercatore di sicurezza se non sai dove cercare. Un buon gestore di password con crittografia competente ( non aWallet a quanto pare) è perfettamente sicuro da conservare su cloud storage, a condizione che la tua password principale sia forte.


Modifica: OK non posso” resistere alla scelta di alcuni altri punti che mi saltano addosso per gridare “stai lontano”:

  • Per quanto riguarda la trasformazione della password principale in una chiave di crittografia: “Il risultato viene sottoposto ad hashing 1000 volte da SHA-256.” Questo è ridicolmente insufficiente. Se eseguiti correttamente, utilizzerebbero come minimo PBKDF con 10.000 round o più invece di un hash loop personalizzato di soli 1000. Anche questo sarebbe appena sufficiente e si confronterebbe male con i gestori di password correttamente implementati. Centinaia di migliaia o più round sarebbero più simili. Oppure abbandona lhashing della password basato su SHA e usa qualcosa come bcrypt o argon2. Questo software non può essere paragonato agli strumenti moderni.
  • “Supporta la distruzione automatica del file di dati dopo che è stato tentato un numero predefinito di sblocchi non riusciti.” Questo non influisce affatto su un aggressore. Lunica persona che può ferire è lutente legittimo. Un utente malintenzionato creerà una copia del database o utilizzerà un software modificato per rimuovere il limite di ipotesi. Tu sul laltra mano può accidentalmente perdere tutte le tue password, per non essere più vista, per aver attivato accidentalmente il capslock, o una chiave morta, o qualcosa del genere.

Rispondi

Rispondendo in modo specifico alla tua domanda:

Cè uno strumento / tecnica che potrei usare per tentare di decrittografare il file data.crypt utilizzato da unappWallet per testarne la sicurezza?

Ecco un minuscolo script in python che decrittografa i file data.crypt e stampa il contenuto su stdout. Nota che non è sicuro poiché tutto è visibile in testo normale, quindi fallo questo su una macchina sicura o con un file di dati fittizio.

Lo script è stato creato utilizzando documentazione tecnica su awallet.org.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *