aWallet Password Manager

OPMERKING: Deze vraag is een subdeel van de oorspronkelijke vraag op aWallet Password Manager gepost op Cryptography.StackExchange. Zoals suggereert door @SEJPM , plaats ik het hier omdat het onderwerp van de vraag beter geschikt is voor InformationSecurity.StackExchange.


Na het lezen van veel artikelen over het verbeteren van de beveiliging van mijn webaccounts, begon ik aWallet Password Manager voor Android te gebruiken voor back-up mijn wachtwoorden. Ik vind het leuk om de volgende redenen:

  • Ik “kan redelijk wachtwoorden voor goede entropie hebben : ik” kan een mix van kleine & HOOFDLETTERS alfabetten, cijfers, speciale tekens (inclusief spaties) invoeren en redelijk lange wachtwoorden hebben (10+ tekens )
  • Door mijn wachtwoorden veilig op te slaan, heb ik verschillende wachtwoorden voor elk webaccount wat anders zou zijn onmogelijk. Dit zou een trapsgewijs effect (het weggeven van inloggegevens van alle accounts) voorkomen dat ted als een van mijn accounts, waarvan ik de inloggegevens deel met meerdere accounts, wordt gehackt.

Onnodig te zeggen dat dat tweede punt discutabel is omdat het hebben van alle inloggegevens opgeslagen op één plaats introduceert een single-point of failure en vormt een gelijk risico op de kettingreactie eerder genoemd.


Gezien mijn beperkte kennis van cryptografie en twijfels rond privacy (gezien recente incidenten van online diefstallen), wil ik de veiligheid van aWallet Password Manager bevestigen voordat ik mijn Bank- / kaartgegevens erin. Dit is wat ze beweren op hun Google PlayStore-pagina :

VEILIGHEIDSFUNCTIES

• Alle gegevens zijn versleuteld, inclusief toegangsnamen, categoriedefinities en de gegevens zelf.

• Versleutelt gegevens met behulp van AES- en Blowfish-algoritmen met sleutelgroottes van 256, 192 en 128 bits.

• Wanneer het gegevensbestand wordt gedecodeerd, worden tot alle combinaties van algoritme, sleutelgrootte en coderingsmodus (CBC, CFB, OFB en ECB) geprobeerd met het hoofdwachtwoord om het gegevensbestand te ontgrendelen. maakt brute force-aanvallen langer. De app zelf slaat geen enkele hint op naar het daadwerkelijke cijfer, de sleutelgrootte of de coderingsmodus.

• Gebruikt een willekeurig gegenereerd “salt” in combinatie met het hoofdwachtwoord. Salt helpt ter bescherming tegen offline woordenboekaanvallen.

• De sleutel om het gegevensbestand te openen wordt gemaakt door uw hoofdwachtwoord te combineren met het 512-bits “salt”. Het resultaat wordt 1000 keer gehasht door SHA-256 Repetitieve hashing maakt een brute kracht op overstag gaan moeilijker.

Hoewel geen van deze punten voor mij erg logisch is, zegt het kleine beetje dat ik over cryptografie weet dat [corrigeer alstublieft me if I “m” m wrong] het meerdere keren herhalen van een coderingstechniek levert geen “wiskundige verbetering van de beveiliging” ; het geeft misschien alleen maar een verkeerde indruk van extra veiligheid.


En vanwege deze inconsistentie begon ik te twijfelen aan de geldigheid van hun andere claims. Mijn vragen zijn: –

  1. Is er een tool / techniek die ik zou kunnen gebruiken om te proberen het data.crypt -bestand dat door de aWallet-app wordt gebruikt, te decoderen om de veiligheid testen?
  2. aWallet biedt geen eigen cloudopslag en stelt ons in staat (optioneel) een back-up te maken van het data.crypt -bestand op Google Drive of Dropbox. Hoe veilig zou dat zijn als ik 2-factorenauthenticatie gebruik voor mijn Google-account?
  3. Is het in het algemeen veilig om inloggegevens of bankgegevens of beide op te slaan in een wachtwoordbeheerder?

Reacties

  • Is de repetitieve hashing die je achterdochtig maakte? Dat is niet hetzelfde als repetitieve versleuteling, en het is inderdaad de standaardpraktijk. Zie dit .
  • Is it safe to store login credentials or banking details or both in a password manager Het doet niet ‘ t moet perfecte beveiliging zijn, het moet beter zijn dan je eigen wachtwoord aanmaken en onthouden.
  • ” alle combinaties van algoritme, sleutelgrootte en versleutelingsmodus (CBC, CFB, OFB en ECB) wordt geprobeerd ” Dit klinkt idioot … waarom zou u geen goede sleutelafleidingsfunctie gebruiken?Het feit dat ze u blijkbaar toestaan om ECB te gebruiken, is een enorme rode vlag (en als ze u niet toestaan om ECB te gebruiken ‘, dan is het niet ‘ doe sowieso niets om de aanvaller te vertragen)
  • Ik ‘ zou iedereen willen wijzen die wil reageren op de cryptografische details van deze ” wachtwoordbeheerder ” naar de gekoppelde post op Crypto.SE , waar deze kwesties worden geëvalueerd en besproken.

Antwoord

Let op: dit bericht beantwoordt eigenlijk de vraag (en) in de vraag en geeft niet (veel) commentaar op de beveiliging van aWallet. Ik raad je aan om de Crypto.SE-versie van deze vraag voor een beoordeling van de cryptografische details.

Is er een tool / techniek die ik zou kunnen gebruiken om te proberen het data.crypt-bestand dat door de aWallet-app wordt gebruikt te decoderen om de veiligheid ervan te testen?

Een snelle zoekopdracht leverde niets op, dus ik veronderstel dat deze wachtwoordbeheerder niet “groot genoeg / niet genoeg onderzoek heeft gezien om iemand anders een tool te laten schrijven om deze wachtwoordbeheerder aan te vallen.

aWallet biedt geen eigen cloudopslag en stelt ons in staat om (optioneel) een back-up te maken van het data.crypt-bestand op Google Drive of Dropbox. Hoe veilig zou dat zijn als ik 2-Factor-Authentication gebruik voor mijn Google-account?

Dit hangt er sterk van af.
Ervan uitgaande dat aWallet “s beveiligingsmaatregelen zijn eigenlijk goed en je gebruikt een sterk wachtwoord en / of een lokaal sleutelbestand, en het uploaden van de versleutelde wachtwoorddatabase naar een cloudservice doet geen afbreuk aan de beveiliging, omdat je wachtwoord en / of sleutelbestand nog steeds bescherm de wachtwoorden. Natuurlijk betekent de toegevoegde authenticatie en toegangscontrole van deze cloudservices dat de kans groot is dat alleen jij en de provider toegang hebben en het is meestal in het belang van de provider om geen gebruikersbestanden te lekken.

Is het in het algemeen veilig om inloggegevens of bankgegevens of beide op te slaan in een wachtwoordbeheerder?

Ja, zeker als de wachtwoordbeheerder fatsoenlijk is.
Door een wachtwoordbeheerder te gebruiken, kunt u gemakkelijk unieke, sterke wachtwoorden per website, wat betekent dat uw wachtwoorddatabase of uw lokale client moet worden gecompromitteerd. Zoals we al hebben vastgesteld, wordt een compromis van de back-up voorkomen door het sterke wachtwoord, dus dit laat de client compromitteren als de vector om het wachtwoord te leren. Maar zodra uw cliënt gecompromitteerd is, zijn alle weddenschappen sowieso uitgeschakeld, omdat de aanvaller gewoon aan uw toetsenbord kan ruiken of uw netwerkgegevens kan controleren / onderscheppen! Dus al met al heb je weinig te verliezen en veel te winnen door (goede) passowrd managers te gebruiken.

Of aWallet een goede wachtwoordmanager is, is echter een andere vraag (en beantwoord op Crypto.SE).

Antwoord

aWallet specifiek: gebruik het niet. De maker weet duidelijk niet wat hij doet. Ik kies maar één probleem uit (er zijn er meerdere die waarschijnlijk duidelijker zullen zijn voor People Smarter Than Me): het kan uw database versleutelen in de ECB-modus (soms, maar niet altijd).

ECB-modus is met name niet veilig omdat dezelfde platte tekst altijd versleutelt naar dezelfde cypher-tekst. Daarom verbergt de ECB-modus “datapatronen niet goed … het biedt geen serieuze vertrouwelijkheid van berichten , en het wordt helemaal niet aanbevolen voor gebruik in cryptografische protocollen “.

Wachtwoordmanagers in het algemeen: gebruik er een. Maar kies een bekende met een goede reputatie, zoals 1Password, LastPass, KeePass, Dashlane, enz. Of gebruik er in ieder geval een die is gemaakt of aanbevolen door een bekend beveiligingsbedrijf of beveiligingsonderzoeker als je niet weet waar je anders moet zoeken. Een goede wachtwoordbeheerder met competente versleuteling ( niet aWallet blijkbaar) is volkomen veilig om in de cloud te bewaren, op voorwaarde dat je hoofdwachtwoord sterk is.


Bewerken: OK ik kan het niet laten om een paar andere punten te kiezen die naar me uitspringen om te schreeuwen” blijf weg “:

  • Met betrekking tot het omzetten van het hoofdwachtwoord in een coderingssleutel: “Het resultaat wordt 1000 keer gehasht door SHA-256.” Dit is belachelijk onvoldoende. Goed gedaan, zouden ze op zijn minst PBKDF gebruiken met 10.000 ronden of meer in plaats van een op maat gemaakte hash-lus van slechts 1000. Zelfs dat zou nauwelijks voldoende zijn en slecht te vergelijken zijn met correct geïmplementeerde wachtwoordbeheerders. Honderdduizenden of meer rondes zouden er meer op lijken. Of verlaat SHA-gebaseerde wachtwoordhashing en gebruik zoiets als bcrypt of argon2. Deze software is niet te vergelijken met moderne tools.
  • “Ondersteunt automatische vernietiging van het gegevensbestand nadat een vooraf gedefinieerd aantal mislukte ontgrendelingen is geprobeerd.” Dit heeft geen enkele invloed op een aanvaller. De enige persoon die dit kan schaden is de legitieme gebruiker. Een aanvaller maakt een kopie van de database of gebruikt aangepaste software om de goklimiet te verwijderen. Jij op de andere kant kan per ongeluk al uw wachtwoorden verliezen, om nooit meer te worden gezien, door per ongeluk capslock aan te zetten, of een dode sleutel, of iets dergelijks.

Antwoord

Specifiek uw vraag beantwoorden:

Is er een tool / techniek die ik zou kunnen gebruiken om te proberen het data.crypt-bestand ontsleutelen dat wordt gebruikt door de aWallet-app om de veiligheid ervan te testen?

Hier is een klein script in python dat data.crypt bestanden decodeert en de inhoud afdrukt naar stdout. Merk op dat het niet veilig is omdat alles zichtbaar is in platte tekst, dus doe dit alleen dit op een beveiligde machine of met een dummy gegevensbestand.

Het script is gebouwd met de technische documentatie op awallet.org.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *