Stribevis af sikkerhedsproblemer i kodeords-huskere på Android

Forskere har gennemgået sikkerheden i flere kodeordshuskere på Android, og det ser skidt ud.

Forskere har ved en gennemgang af i alt ni kodeordshuskere fundet 26 sikkerhedsproblemer. Forskerne kalder sig TeamSIK og er fra Fraunhofer Instituttet i Darmstadt, Tyskland.

Det fortæller The Register på baggrund af forskernes netop offentliggjorte undersøgelse.

Programmer som Lastpass og 1Password håndterer kodeord til forskellige tjenester, så brugere får nemmere ved at anvende forskellige og i udgangspunktet stærke kodeord til tjenesterne.

Forudsætningen for, at programmer til kodeordshåndtering kan bruges til noget, er naturligvis, at de i sig selv er sikkerhedsmæssigt forsvarligt skruet sammen. Og det står, jævnfør forskernes arbejde, umiddelbart sløjt til.

»De overordnede resultater var dybt bekymrende og afslørede, at password-manager-apps, modsat deres påstande, ikke leverede tilstrækkelige beskyttelsesmekanismer i forhold til de lagrede kodeord og credentials,« oplyser forskergruppen og fortsætter:

»I stedet misbruger de brugernes tillid og eksponerer dem for høj risici.«

Forskerne har kigger på sikkerheden i My Passwords, Informaticore Password Manager, LastPass, Keeper, F-Secure KEY, Dashlane, Hide Pictures Keep Safe Vault, Avast Passwords og 1Password.

I alle apps har forskerne identificeret en eller flere sårbarheder. Alle de problemer, forskerne har peget på, er blevet fikset af virksomhederne bag de forskellige apps.

Blandt problemerne er lagringen af det såkaldte master-password, som låser op for, at de huskede kodeord i programmet kan frigives i forbindelse med login til forskellige tjenester.

I flere tilfælde viste master-passwordet sig således at være lagret i klartekst på Android-enheden. Det var blandt andet tilfældet i F-Secure KEY Password Manager.

Og i Hide Pictures Keep Safe Vault lå alle lagrede kodeord gemt i klartekst, blandt andet i forbindelse med konfigurationsfilen com.kii.safe_preferences.xml

Hardcoded kryptonøgle

Udover klartekst-kodeord, plagede flere andre sikkerhedsproblemer kodeords-programmerne. Eksempelvis indeholdt LastPass-app'en en hardcoded nøgle.

Så mens master-passwordet (alternativt en pin-kode) har ligget krypteret i på enheden, så har nøglen til dekryptering af kodeord/pin været hardcoded ind i LastPass.

Forskerne beskriver i detaljer, hvordan den hardcodede krypteringsnøgle i forhold til LastPass ville kunne misbruges.

Leverandørerne bag de testede apps har dog nu fikset problemerne, som forskerne har identificeret.

»Eftersom alle leverandører har fikset deres sikkerhedsproblemer, så er vores råd til kunderne altid at opdatere deres apps,« siger Siegfried Rasthofer, en sikkerhedsforsker fra Fraunhofer, i en mail til The Register.

Annonce:
Kom gratis med til Danmarks største IT-sikkerhedsevent!

Infosecurity, Europas mest populære IT-sikkerhedsevent, afholdes i Danmark den 3. og 4. maj 2017. 60 udstillere, 5 konferencesale og mere end 80 seminarer og caseoplæg fra ind- og udland. Læs mere her.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Cederberg

"Eftersom alle leverandører har fikset deres sikkerhedsproblemer,"
ja så er artiklen spild af tid :-(

På ingen måde. Reelt siger artiklen at vi ikke skal have tillid til ovenstående apps, når de ikke kan finde ud af basal sikkerhed. Hvad med alle de sikkerhedsproblemer som forskerne ikke fandt men som stadigvæk er i de apps?

Sikkerhedsproblemer skal man selv identificere!

  • 7
  • 0
Bo Zachariasen

Sikkerhedsproblemer skal man selv identificere!

Tror at det er uhyre svært at udføre i den virkelige verden. Den bedste måde at opdage dette er selv at udvikle en avanceret løsning, det kunne fx være en passwordmaneger, som over 10 år ikke bliver afsløret med sårbarheder. Så opdager man at "Sikkerhedsproblemer skal man selv identificere", det smuttede bare denne gang fordi at....< Her kan man selv sætte en god bortforklaring ind>

  • 0
  • 0
Michael Cederberg

Tror at det er uhyre svært at udføre i den virkelige verden. Den bedste måde at opdage dette er selv at udvikle en avanceret løsning, det kunne fx være en passwordmaneger, som over 10 år ikke bliver afsløret med sårbarheder.

Sikkerhed kommer ikke ved at teste efter man har designet og skrevet koden. Sikkerhed er en del af designet. Man overvejer mulige angreb. Man vurderer hvad der sker såfremt dele af designet kompromiteres. Man diskuterer designet med andre der ved noget om security. Når man skriver ny kode så overvejer man om det påvirker sikkerheden. etc. etc.

Det er kun amatører der beder folk som ikke har set sourcekoden om at lave penetrationtests og forventer at få noget ud af det. Det er uendeligt meget sværere at finde sikkerhedsproblemer når man blot har en blackbox at undersøge. Det er ikke en fornuftig udnyttelse af ressourcer.

Og ja, engang imellem laver man fejl. Det sker for alle. Men de fejl som er beskrevet her er simple og nogen udviklerne skulle have fundet selv.

  • 0
  • 1
Bo Zachariasen

Det er kun amatører der beder folk som ikke har set sourcekoden om at lave penetrationtests og forventer at få noget ud af det. Det er uendeligt meget sværere at finde sikkerhedsproblemer når man blot har en blackbox at undersøge. Det er ikke en fornuftig udnyttelse af ressourcer.

Jeg ser ikke at "amatørerne" har bedt team-sik.org om sikkerhedsvurdering:

...we performed a security analysis on the most popular Android password manager applications from the Google Play Store based on download count.

Det tolker jeg som at de på eget initiativ har udvalgt og sikkerhedsanalyseret de mest benyttede PWM.
Det fremgår ikke om keePass, som er open source, har været omfattet af analysen men fundet fejlfri.

Det er normalt at sw udvikling foregår i dedikerede team, særligt når produktets omsætning afhænger af omdømmet.

Men hvad siger du til at udvikle en fuldstændig fejlfri passwordmaneger og som er fejlfri i 10 år? Det er der et behov for!

  • 1
  • 1
Bo Zachariasen

Det fremgår ikke om keePass, som er open source, har været omfattet af analysen men fundet fejlfri.

Har modtaget mail hvor det fremgår at keePass ikke var inkluderet i denne omgang:

Rasthofer, Siegfried <s***@sit.fraunhofer.de>

Hello,

Thanks for your message.
Unfortunately, it was not included. We will maybe look into it in the near future.

Best regards,
Siegfried

>
> Message Body:
> Was keepass (open source) included in you test but bug free?

  • 0
  • 0
Michael Cederberg

Men hvad siger du til at udvikle en fuldstændig fejlfri passwordmaneger og som er fejlfri i 10 år? Det er der et behov for!

Jeg mener at hele ideen om en sikker passwordmanager der kører på min computer er broken. Selv hvis jeg lavede en fejlfri passwordmanager, så er alt hvad der kræves for at bryde den en keylogger på maskinen (der opsnapper mit master password næste gang jeg bruger det) og en kopi af passwordfilen.

En passwordmanager bør ligge på et stykke separat hardware - helst uden forbindelse til nogen computer. Alternativt kunne den plugges ind i en USB port og så sende keystrokes til computeren når jeg trykker på en fysisk knap på dimsen (og så må den i øvrigt ikke reagere på andet fra computeren; ingen tilgang til lager eller settings).

Her er en god start (selvom jeg synes den er lidt for integreret med PC'en): https://www.kickstarter.com/projects/limpkin/mooltipass-mini-your-passwo...

Men jeg har såmænd i tidernes morgen designet et kryptografisk sikkerhedssystem der sikrede softwarelicenser for adskillige milliarder kroner i 10 år, uden at det nogensinde blev kompromitteret.

  • 0
  • 1
Bo Zachariasen
  • 0
  • 0
Michael Cederberg

Det er nu ikke lige sådan at det fungere hvis man vil bruge PWM sikkert. Det er ikke nok med en keylogger og databasefilen. LP og andre har flere kneb mod denne trussel . Her er der 10 - 14 stykker at vælge mellem.

Du bliver nok nødt til at skrive lidt mere. Jeg ser ikke noget nyt.

Når jeg skrev passwordfilen så skal det forstås i overført betydning. Det betyder tage det nødvendige på computeren.

Og det er ret banalt: Hvis du kan få fat i et givent password på din computer ved at taste et masterpassword ind, så kan en hacker gøre det samme.

Uden en eller anden hardwaredims der gemmer noget der er nødvendigt for dekode "passwordfilen" så kan systemet hackes første gang du taster dit masterpassword ind.

  • 1
  • 2
Kenn Nielsen

Når jeg skrev passwordfilen så skal det forstås i overført betydning. Det betyder tage det nødvendige på computeren.

Og det er ret banalt: Hvis du kan få fat i et givent password på din computer ved at taste et masterpassword ind, så kan en hacker gøre det samme.

Uden en eller anden hardwaredims der gemmer noget der er nødvendigt for dekode "passwordfilen" så kan systemet hackes første gang du taster dit masterpassword ind.

Joo, men hvis du definerer trusselsbilledet som sikring mod genbrug af passwords
fordi sites og services er usikre, så kan du godt få øget sikkerhed ud af en pwm som har et master password..

Til eget brug , vil jeg under ingen omstændigheder benytte mig af "services" som tilbyder mig at passe på mine adgangskoder.
Dértil rækker min tillid til "andre mennesker i almindelighed" og "tilfældige firmaer i særdeleshed" ikke en millimeter.

K

  • 0
  • 0
Michael Cederberg

Joo, men hvis du definerer trusselsbilledet som sikring mod genbrug af passwords
fordi sites og services er usikre, så kan du godt få øget sikkerhed ud af en pwm som har et master password..

Og min pointe er at ved at vælge en pwm som blot er software på din computer, så har du blot skabt et andet problem for dig selv. Et som kan blive meget seriøst fordi det reelt giver adgang til alle dine passwords.

En mere sikker metode er at skrive dine passwords på et stykke papir og gemme det i din pung. For at hacke dig i den situation så skal man fysisk stjæle din pung - dvs. der er langt færre personer som har mulighed for at hacke dig og du ved hvis det er sket.

Lidt mere avanceret kan du appende et par ekstra tegn som du holder i hovedet til de passwords du har på papiret. Så er du endnu bedre beskyttet. Helt godt bliver det dog ikke indtil du har noget der skifter hver gang du logger ind - fx. en af de der nøglevisere der viser et nummer der skifter hvert minut eller numre fra et papkort der kun bruges en gang. På den måde kan en hacker ikke opsnappe dit password og så genbruge det i uendelighed. Det virker dog ikke til almindelige username+password websites.

  • 0
  • 1
Bo Zachariasen

En mere sikker metode er at skrive dine passwords på et stykke papir og gemme det i din pung. For at hacke dig i den situation så skal man fysisk stjæle din pung - dvs. der er langt færre personer som har mulighed for at hacke dig og du ved hvis det er sket.

Det er nu ikke helt korrekt. Er din enhed hacket på app, OS eller HW niveau vil der være risiko for at passwordet som står på papiret bliver stjålet 1. gang det bliver brugt efter indbruddet. Og det hjælper helt og aldeles selvfølgelig ikke på det problem at kun noget af pwd står på papiret. Og heller at det står med citronsaft.

En dims som generer en ny kode hver gang gør det sværere - men også denne dims kan være fake uden at producenten nødvendigvis ved dette da angrebet kan være foretaget i en af de chips han anvender eller er foretaget efter at dimsen sendes til slutbrugeren. Ved at bruge en dims til fx 2FA eller som pwm eller som rnd key FLYTTES brugeres afhængighed af trust men det fjernes ikke.

Der findes med andre ord ingen løsning der er 100% sikkerhed - men man kan komme tæt på. Hvis skærmdump og keylogs og udvalgt USB data sendes til hackeren er der høj sikkerhedsrisiko og hvis hackeren har fysisk adgang til enheden, fx PC, er det rigtigt rigtigt skidt. HD kan da udskiftes mhp på installation af fake BIOS m.v.

Hvis det var affyringskodener til atommislierne ville jeg ikke bruge LP eller noget som helst andet for den sags skyld. Men da det bare er mine login til diverse og kreditkort oplysninger m.v. er LP rigelig sikkert fordi: Selvom en anden har den mail adresse som er knyttet til brugerens LP konto OG marsterpassworded kan han IKKE få adgang til data med mindre han har pwd til den mailkonto som er brugt som brugernavn. Det har han nok ikke for den pågældende mail konto logger jeg aldrig ind på fordi jeg aldrig bruger mail kontoen til at sende mails. Måske, men jeg ved det ikke, ville en fake version af LP kunne deaktivere denne forhindring.

Er der anvendt 2FA kræver det at angriberen har adgang til den valgte fysiske enhed og selvfølgeligt ikke er faked.

An attacker could try to guess your master password, then use your per-user-salt and authentication hash to determine if their guess was correct. Typically, an attacker would try a list of commonly-used passwords or dictionary words (such as 12345678, password1, mustang, robert42, iloveyou). They would have to do this for you specifically, since your “per-user” salt is unique to your account . Because your password is hashed thousands of times locally, and this hashed value is again hashed 100,000 times before being stored server-side, guesses will be very slow. If your master password is weak or if your password reminder makes it easy-to-guess, then the attacker could significantly reduce the number of attempts needed to guess it correctly. Then the attacker would have your master password, but not your data, since your data vault was not exposed. If the attacker attempted to get access to your data by using these credentials to log into your LastPass account, they’d be stopped by a notification asking them to first verify their email address. We require this security measure for any attempt to access your vault from a new device/location, unless you have multifactor authentication enabled.

https://blog.lastpass.com/2015/06/lastpass-security-notice.html/

  • 0
  • 0
Log ind eller Opret konto for at kommentere