aWallet Password Manager (Norsk)

MERK: Dette spørsmålet er en underdel av originale spørsmål på aWallet Password Manager lagt ut på Cryptography.StackExchange. Som foreslått av @SEJPM , legger jeg det ut her siden emnet på spørsmålet er bedre egnet for InformationSecurity.StackExchange.


Etter å ha lest mange artikler om å øke sikkerheten til webkontiene mine, begynte jeg å bruke aWallet Password Manager for Android til backup passordene mine. Jeg liker det av følgende grunner:

  • Jeg kan ha ganske passord med god entropi : Jeg kan kaste inn en blanding av små bokstaver & OPPERCASE-alfabet, sifre, spesialtegn (inkludert mellomrom) og har rimelig lange passord (10+ tegn )
  • Når jeg lagrer passordene mine, kan jeg ha forskjellige passord for hver nettkonto som ellers ville være umulig. Dette ville avverge en kaskadeffekt (å gi legitimasjon fra alle kontoer) som ville være ted hvis en av kontoene mine, hvis påloggingsinformasjon jeg deler med flere kontoer, blir kompromittert.

Det er unødvendig å si at det andre punktet er diskutabelt fordi du har alle legitimasjonene lagret på ett sted introduserer et feilpunkt og utgjør en like stor risiko for kjedereaksjonen nevnt tidligere.


Gitt min begrensede kunnskap om kryptografi og tvil om personvern (gitt nylige hendelser med online tyverier), vil jeg vitne om sikkerheten til aWallet Password Manager før jeg lagrer Bank- / kortdetaljer i den. Her er hva de hevder på Google PlayStore-siden :

SIKKERHETSFUNKSJONER

• Alle data er kryptert, inkludert oppføringsnavn, kategoridefinisjoner og selve dataene.

• Krypterer data ved hjelp av AES- og Blowfish-algoritmer med nøkkelstørrelser på 256, 192 og 128 bits.

• Når datafilen dekrypteres, blir opp til alle kombinasjoner av algoritme, nøkkelstørrelse og krypteringsmodus (CBC, CFB, OFB og ECB) forsøkt med hovedpassordet for å låse opp datafilen. gjør brute force-angrep lenger. Selve appen lagrer ikke noe hint til den faktiske kryptering, nøkkelstørrelse eller krypteringsmodus.

• Bruker et tilfeldig generert «salt» kombinert med hovedpassordet. for å beskytte mot offline-ordbokangrep.

• Nøkkelen til å åpne datafilen opprettes ved å kombinere hovedpassordet ditt med 512-biters «salt». Resultatet blir haset 1000 ganger av SHA-256 Gjentatt hashing gjør en brutal kraft ved tack vanskeligere.

Selv om ingen av disse punktene gir mye mening for meg, forteller den lille biten jeg vet om kryptografi meg at [rett meg hvis jeg har feil] Gjentakelse av en krypteringsteknikk flere ganger, forbedrer ikke sikkerheten ; det kan bare gi en et feilaktig inntrykk av ekstra sikkerhet.


Og på grunn av denne inkonsekvensen begynte jeg å tvile på gyldigheten av deres andre påstander. Mine spørsmål er: –

  1. Er det et verktøy / teknikk som jeg kan bruke til å forsøke å dekryptere data.crypt -filen som brukes av aWallet-appen for å test det er sikkerhet?
  2. aWallet tilbyr ikke noe skylagring for seg selv og lar oss (valgfritt) sikkerhetskopiere data.crypt -filen til Google Drive eller Dropbox. Hvor trygt ville det blitt gitt at jeg bruker 2-faktor-autentisering for Google-kontoen min?
  3. Er det generelt trygt å lagre påloggingsinformasjon eller bankopplysninger eller begge deler i en passordbehandling?

Kommentarer

  • Er den repeterende hashingen som gjorde deg mistenksom? Det er ikke det samme som repeterende kryptering, og det er faktisk vanlig praksis. Se dette .
  • Is it safe to store login credentials or banking details or both in a password manager Det gjør det ikke ‘ t må være perfekt sikkerhet, det må være bedre enn å lage ditt eget passord og huske det.
  • » alle kombinasjoner av algoritme, nøkkelstørrelse og krypteringsmodus (CBC, CFB, OFB og ECB) blir prøvd » Dette høres idiotisk ut … hvorfor ikke bruke en riktig nøkkelavledningsfunksjon?Det at de tilsynelatende tillater deg å bruke ECB, er et stort rødt flagg (og hvis de ikke ‘ ikke tillater deg å bruke ECB, så prøver ikke å dekryptere med det ‘ t gjør noe for å bremse angriperen uansett)
  • Jeg ‘ vil påpeke alle som vil kommentere de kryptografiske detaljene av dette » passordbehandling » til koblet innlegg på Crypto.SE , der disse problemene evakueres og diskuteres.

Svar

Merk: Dette innlegget svarer faktisk på spørsmålene i spørsmålet og kommenterer ikke (mye) sikkerheten til aWallet. Jeg foreslår at du besøker Crypto.SE-versjon av dette spørsmålet for en gjennomgang av kryptografiske detaljer.

Er det et verktøy / teknikk som jeg kunne bruke for å prøve å dekryptere data.crypt-filen som brukes av aWallet-appen for å teste den? S sikkerhet?

Et raskt søk viste ingenting, så jeg anta at denne passordbehandleren ikke er stor nok / ikke har sett nok forskning til å ha fått noen andre til å skrive et verktøy for å angripe denne passordadministratoren.

aWallet tilbyr ikke noe skylagring og lar oss (valgfritt) sikkerhetskopiere data.crypt-filen til Google Drive eller Dropbox. Hvor trygt ville det blitt gitt at jeg bruker 2-faktor-autentisering for Google-kontoen min?

Dette avhenger veldig mye.
Forutsatt at aWallet «s sikkerhetstiltak er faktisk bra og du bruker et sterkt passord og / eller en lokal nøkkelfil, så kan ikke opplasting av den krypterte passorddatabasen til en skytjeneste skade sikkerheten, ettersom passordet og / eller nøkkelfilen fortsatt beskytt passordene. Selvfølgelig betyr den ekstra autentiseringen og tilgangskontrollen for disse skytjenestene at sjansen er at bare du og leverandøren har tilgang, og det er vanligvis i leverandørens beste å ikke lekke brukerfiler.

Er det generelt trygt å lagre påloggingsinformasjon eller bankopplysninger eller begge deler i en passordbehandling?

Ja, veldig mye, hvis passordbehandleren er anstendig.
Ved å bruke en passordbehandling kan du enkelt ha unik, sterke passord per nettsted, noe som betyr at det kreves et kompromiss mellom passorddatabasen eller den lokale klienten. Som vi allerede har etablert, forhindres et kompromiss med sikkerhetskopien av det sterke passordet, så dette etterlater klienten kompromiss som vektor for å lære seg passordet. Men så snart klienten din er kompromittert, er alle spill uansett, fordi angriperen bare kan snuse på tastaturet eller overvåke / avskjære nettverksdataene dine! Så alt i alt er det lite å tape og mye å tjene på å bruke (gode) passowrd-ledere.

Hvorvidt aWallet er en god passordbehandling er et annet spørsmål om (og besvart på Crypto.SE).

Svar

aWallet spesifikt: ikke bruk den. Skaperen vet tydeligvis ikke hva de gjør. Jeg velger bare en bekymring (det er flere som sannsynligvis vil være mer åpenbare for People Smarter Than Me): det kan kryptere databasen din i ECB-modus (noen ganger, men ikke alltid).

ECB-modus er spesielt ikke sikker fordi den samme klarteksten alltid krypteres til den samme cypher-teksten. Derfor skjuler ikke ECB-modus «datamønstrene godt … det gir ikke alvorlig beskjed om konfidensialitet , og det anbefales ikke bruk i kryptografiske protokoller i det hele tatt «.

Passordadministratorer generelt: bruk en. Men velg en kjent med godt omdømme som 1Password, LastPass, KeePass, Dashlane, etc. Eller i det minste bruk en som er opprettet eller anbefalt av et kjent sikkerhetsfirma eller sikkerhetsforsker hvis du ikke vet hvor du skal lete annet. En god passordbehandling med kompetent kryptering ( ikke aWallet tilsynelatende) er helt trygg å ha på skylagring, forutsatt at hovedpassordet ditt er sterkt.


Rediger: OK, jeg kan ikke motstå å plukke noen andre punkter som hopper ut på meg for å skrike» hold deg borte «:

  • Angående transformering av hovedpassordet til en krypteringsnøkkel: «Resultatet blir hash 1000 ganger av SHA-256.» Dette er latterlig utilstrekkelig. Gjort riktig ville de i det minste bruke PBKDF med 10 000 runder eller mer i stedet for en skreddersydd hash-løkke på bare 1000. Selv det ville knapt være tilstrekkelig, og ville sammenligne dårlig med riktig implementerte passordadministratorer. Hundretusener eller flere runder vil være mer like det. Eller forlat SHA-basert passordhashing og bruk noe som bcrypt eller argon2. Denne programvaren kan ikke sammenlignes med moderne verktøy.
  • «Støtter automatisk ødeleggelse av datafilen etter at et forhåndsdefinert antall mislykkede opplåsinger er prøvd.» Dette påvirker ikke en angriper i det hele tatt. Den eneste personen dette kan skade er den legitime brukeren. En angriper vil lage en kopi av databasen eller bruke modifisert programvare for å fjerne gjetningsgrensen. Du på annen hånd kan ved et uhell miste alle passordene dine, for aldri å bli sett igjen, ved å slå på capslock, eller en død nøkkel, eller noe sånt.

Svar

Spesielt svar på spørsmålet ditt:

Er det et verktøy / teknikk som jeg kan bruke til å prøve å dekryptere data.crypt-filen som brukes av aWallet-appen for å teste den? S sikkerhet?

Her er et lite skript i python som dekrypterer data.crypt filer og skriver ut innholdet til stdout. Merk at det ikke er sikkert siden alt er synlig i ren tekst, så bare gjør dette på en sikker maskin eller med en dummy datafil.

Skriptet ble bygget med teknisk dokumentasjon på awallet.org.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *