aWallet Password Manager (Dansk)

BEMÆRK: Dette spørgsmål er en underdel af originale spørgsmål på enWallet Password Manager, der blev offentliggjort på Cryptography.StackExchange. Som foreslået af @SEJPM , sender jeg det her, da emnet for spørgsmålet er bedre egnet til InformationSecurity.StackExchange.


Efter at have læst mange artikler om forbedring af sikkerheden på mine webkonti begyndte jeg at bruge aWallet Password Manager til Android til backup mine adgangskoder. Jeg kan godt lide det af følgende grunde:

  • Jeg er i stand til at have ret god entropi-adgangskoder : Jeg kan kaste en blanding af små bogstaver & HOVEDOPLADSER, bogstaver, cifre, specialtegn (inklusive mellemrum) og har rimeligt lange adgangskoder (10+ tegn )
  • Hvis jeg gemmer mine adgangskoder sikkert, kan jeg have forskellige adgangskoder for hver webkonto som ellers ville være umuligt. Dette ville forhindre en kaskadevirkning (at give legitimationsoplysninger fra alle konti væk), der ville være ted hvis en af mine konti, hvis loginoplysninger jeg deler med flere konti, bliver kompromitteret.

Det er overflødigt at sige, at det andet punkt er diskutabelt fordi det har alle legitimationsoplysninger lagret på et enkelt sted introducerer et fejlpunkt og udgør en lige risiko for kædereaktion nævnt tidligere.


I betragtning af min begrænsede viden om kryptografi og tvivl om privatlivets fred (i betragtning af nylige hændelser med online-tyveri) vil jeg vidne om sikkerheden ved aWallet Password Manager, før jeg gemmer min Bank- / kortoplysninger i den. Her er hvad de hævder på deres Google PlayStore-side :

SIKKERHEDSFUNKTIONER

• Alle data er krypteret, inklusive indtastningsnavne, kategoridefinitioner og selve dataene.

• Krypterer data ved hjælp af AES- og Blowfish-algoritmer med nøglestørrelser på 256, 192 og 128 bits.

• Når datafilen dekrypteres, forsøges op til alle kombinationer af algoritme, nøglestørrelse og krypteringstilstand (CBC, CFB, OFB og ECB) med hovedadgangskoden for at låse datafilen op. gør brute force-angreb længere. Selve appen gemmer ikke noget antydning til den faktiske chiffer, nøglestørrelse eller chiffreringstilstand.

• Bruger et tilfældigt genereret “salt” kombineret med masteradgangskoden. Salt hjælper for at beskytte mod off-line ordbogangreb.

• Nøglen til at åbne datafilen oprettes ved at kombinere din hovedadgangskode med 512-bit “salt”. Resultatet er hashet 1000 gange af SHA-256 Gentagen hashing skaber en brutal kraft ved tack sværere.

Selvom ingen af disse punkter giver meget mening for mig, fortæller den lille smule, jeg ved om kryptografi, mig at [rettes mig hvis jeg fejler Gentagelse af en krypteringsteknik flere gange betyder ikke matematisk at forbedre sikkerheden ; det giver muligvis kun et falsk indtryk af ekstra sikkerhed.


Og på grund af denne inkonsekvens begyndte jeg at tvivle på gyldigheden af deres andre påstande. Mine spørgsmål er: –

  1. Er der et værktøj / en teknik, som jeg kunne bruge til at forsøge at dekryptere data.crypt -filen, der bruges af enWallet-app for at test det “sikkerhed?
  2. aWallet tilbyder ikke noget eget cloud-lager og giver os mulighed for (valgfrit) at sikkerhedskopiere data.crypt -filen til Google Drive eller Dropbox. Hvor sikkert ville det blive givet, at jeg bruger 2-faktor-godkendelse til min Google-konto?
  3. Er det generelt sikkert at gemme loginoplysninger eller bankoplysninger eller begge dele i en adgangskodeadministrator?

Kommentarer

  • Er den gentagne hashing, der gjorde dig mistænksom? Det er ikke det samme som gentagen kryptering, og det er faktisk standardpraksis. Se dette .
  • Is it safe to store login credentials or banking details or both in a password manager Det ‘ t skal være perfekt sikkerhed, det skal være bedre end at oprette din egen adgangskode og huske den.
  • ” alle kombinationer af algoritme, nøglestørrelse og chiffreret driftsform (CBC, CFB, OFB og ECB) er afprøvet ” Dette lyder idiotisk … hvorfor ikke bruge en ordentlig nøgleafledningsfunktion?Det faktum, at de tilsyneladende tillader dig at bruge ECB, er et kæmpe rødt flag (og hvis de ikke ‘ ikke tillader dig at bruge ECB, så forsøger du at dekryptere med det ikke ‘ gør ikke noget for at bremse angriberen alligevel)
  • Jeg ‘ vil gerne pege på enhver, der ønsker at kommentere de kryptografiske detaljer af dette ” adgangskodeadministrator ” til linket indlæg på Crypto.SE , hvor disse problemer evakueres og diskuteres.

Svar

Bemærk: Dette indlæg svarer faktisk på spørgsmålene i spørgsmålet og kommenterer ikke (meget) sikkerheden på aWallet. Jeg foreslår, at du besøger Crypto.SE-version af dette spørgsmål til gennemgang af de kryptografiske detaljer.

Er der et værktøj / en teknik, som jeg kunne bruge at forsøge at dekryptere data.crypt-filen, der bruges af aWallet-appen for at teste dens sikkerhed?

En hurtig søgning viste intet, så jeg Antag at denne adgangskodeadministrator ikke er stor nok / ikke har set nok forskning til at have fået en anden til at skrive et værktøj til at angribe denne adgangskodeadministrator.

aWallet tilbyder ikke noget eget cloud-lager og giver os mulighed for (valgfrit) at sikkerhedskopiere data.crypt-filen på Google Drive eller Dropbox. Hvor sikkert ville det blive givet, at jeg bruger 2-faktor-godkendelse til min Google-konto?

Dette afhænger meget.
Antages det, at aWallet “s sikkerhedsforanstaltninger er faktisk gode og du bruger en stærk adgangskode og / eller en lokal nøglefil, så uploader den krypterede adgangskodedatabase til en skytjeneste skader ikke sikkerheden, da din adgangskode og / eller nøglefil stadig beskyt adgangskoder. Selvfølgelig betyder den tilføjede godkendelse og adgangskontrol af disse cloudtjenester, at chancerne kun er, at du og udbyderen har adgang, og det er normalt i udbyderens interesse at ikke lækker brugerfiler.

Er det generelt sikkert at gemme loginoplysninger eller bankoplysninger eller begge dele i en adgangskodeadministrator?

Ja, meget, hvis adgangskodeadministratoren er anstændig.
Brug af en adgangskodeadministrator giver dig mulighed for let at have unik, stærke adgangskoder pr. websted, hvilket betyder, at der kræves et kompromis mellem din adgangskodedatabase eller din lokale klient. Som vi allerede har etableret, forhindres et kompromis af sikkerhedskopien af den stærke adgangskode, så dette efterlader klienten kompromis som vektor for at lære adgangskoden. Men så snart din klient er kompromitteret, er alle væddemål slået fra alligevel, fordi angriberen bare kunne snuse dit tastatur eller overvåge / opfange dine netværksdata! Så alt i alt er du lidt at tabe og meget at vinde ved at bruge (gode) passowrd-ledere.

Om aWallet er en god adgangskodeadministrator er dog et andet spørgsmål (og besvares på Crypto.SE).

Svar

aWallet specifikt: brug det ikke. Skaberen ved selvfølgelig ikke, hvad de laver. Jeg vælger bare en bekymring (der er flere, der sandsynligvis vil være mere åbenlyse for folk, der er smartere end mig): det kunne kryptere din database i ECB-tilstand (nogle gange, men ikke altid).

ECB-tilstand er især ikke sikker, fordi den samme almindelige tekst altid krypteres til den samme cypher-tekst. Derfor skjuler ECB-tilstand “ikke datamønstre godt … det giver ikke seriøs besked fortrolighed , og det anbefales slet ikke til brug i kryptografiske protokoller “.

Adgangskodeadministratorer generelt: brug en. Men vælg en velkendt med godt omdømme som 1Password, LastPass, KeePass, Dashlane osv. Eller brug i det mindste en oprettet eller anbefalet af et velkendt sikkerhedsfirma eller sikkerhedsforsker, hvis du ikke ved, hvor du ellers skal se. En god adgangskodeadministrator med kompetent kryptering ( ikke aWallet tilsyneladende) er helt sikker at gemme i skyopbevaring, forudsat at din hovedadgangskode er stærk.


Rediger: OK, jeg kan ikke modstå at vælge et par andre punkter, der springer ud på mig for at skrige” hold dig væk “:

  • Med hensyn til omdannelse af hovedadgangskoden til en krypteringsnøgle: “Resultatet hashes 1000 gange af SHA-256.” Dette er latterligt utilstrækkeligt. Udført ordentligt ville de i det mindste bruge PBKDF med 10.000 runder eller mere i stedet for en skræddersyet hash-løkke på kun 1000. Selv det ville næppe være tilstrækkeligt og ville sammenligne dårligt med korrekt implementerede adgangskodeadministratorer. Hundredtusinder eller flere runder ville være mere som det. Eller opgive SHA-baseret adgangskode hashing og bruge noget som bcrypt eller argon2. Denne software kan ikke sammenlignes med moderne værktøjer.
  • “Understøtter automatisk destruktion af datafilen, efter at et foruddefineret antal mislykkede låseopgaver er blevet prøvet.” Dette påvirker overhovedet ikke en hacker. Den eneste person, som dette kan skade, er den legitime bruger. En hacker laver en kopi af databasen eller bruger modificeret software til at fjerne gættegrænsen. Du på anden hånd kan ved et uheld miste alle dine adgangskoder for aldrig at blive set igen ved ved et uheld at have slået capslock til eller en død nøgle eller noget lignende.

Svar

Specifikt besvare dit spørgsmål:

Er der et værktøj / en teknik, som jeg kunne bruge til at forsøge at dekryptere data.crypt-filen, der bruges af aWallet-appen for at teste den? S sikkerhed?

Her er et lille script i python, der dekrypterer data.crypt filer og udskriver indholdet til stdout. Bemærk, det er ikke sikkert, da alt er synligt i almindelig tekst, så gør kun dette på en sikker maskine eller med en dummy-datafil.

Scriptet blev bygget ved hjælp af teknisk dokumentation på awallet.org.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *