1. Location:
  2. / Computer learning >> Datamaskin læring >> Kunnskap om programmering >> andre >>

Passord Authentication

passord autentisering brukes i mange systemer for autentisering av identiteten til en eller begge jevnaldrende med en tilkobling. Denne oppgaven vil hjelpe deg å designe mer sikker godkjenning av passord ordninger bruker symmetriske kryptografiske teknikker. Godkjenning av passord ved hjelp Symmetriske Teknikker
@ Page {size: 21cm 29.7cm; margin: 2cm} P {margin-bottom: 0.21cm} H1 {margin-bottom: 0.21cm} H1.western {font-family: "Arial", sans-serif; font-size: 16pt} H1.cjk {font-family: "Lucida Sans Unicode"; font-size: 16pt} H1.ctl {font-family: "Tahoma"; font-size: 16pt} H2 {margin-bottom: 0.21cm} H2.western {font-family: "Arial", sans-serif; font-size: 14 pkt; font-style: italic} H2.cjk {font-size: 14 pkt; font-style: italic} H2.ctl {font-size: 14 pkt; font-style: italic} H3 {margin-bottom: 0.21cm} H3.western {font-family: "Arial", sans-serif} H4 {margin-bottom: 0.21cm} H4.western {font-family: "Arial ", sans serif; font-size: 11pt; font-style: italic} H4.cjk {font-size: 11pt; font-style: italic} H4.ctl {font-size: 11pt; font-style: italic} - > PasswordAuthentication

av Henrick Hellström, StreamSec, 2004. Alle rettigheter reservert.

Passord godkjenning brukes i mange systemer for autentisering av identiteten til en eller begge jevnaldrende med en tilkobling. De fleste ordninger som brukes i dag er trivielt usikker, selv om de benytter kryptografiske algoritmer som hash-funksjoner og krypteringsfunksjoner. Denne oppgaven vil hjelpe deg å oppdage noen vanlige svakheter og design sikrere passord godkjenningsordninger som bruker symmetrisk kryptografisk techniques.General Råd

Hver passordbasert autentisering system er, uten unntak, sårbare for visse angrep hvis du bruker svake passord. Motsatt, ved hjelp av et sterkt passord, eller rettere sagt pass setning, vil ikke gjøre deg noe godt hvis du bruker den for svak eller alvorlig kompromittert autentiseringssystemer. Noen generelle råd er:


    Bruk passord og passordfraser du kan huske. Å måtte skrive ned passordet ditt, eller lagre den i en fil et sted, er sjelden en god ting.

  • Bruk lang passere setninger med flere setninger i stedet for korte obskure passord med ikke-alfabetiske tegn. Huske et sikkert passord med 20 bokstaver inkludert tall og spesialtegn er for de fleste en mye hardere enn å huske en 128 brev passfrase som bare består av intelligiblesentences.

  • Bruk samme favoritt passord for hver tjeneste du vet sysselsetter et sikkert passord autentisering ordningen. Å måtte huske en rekke passord for ulike tjenester er dårlig. Du bør bruke hjernen din til noe mer produktivt.

  • Samtidig, må du huske på at de fleste tjenester dessverre ikke benytter sikker godkjenning av passord ordninger. Hvis du bruker samme passord for både service A og service B, kan din tilgang til tjenesten A bli svekket hvis tjeneste B er eller blir kompromittert. Hvis begge tjenestene hadde brukt sikker godkjenning av passord ordninger ville ikke dette ha vært en bekymring.

    Problem

    Alice ønsker å bevise for noen hun mener er Bob at hun er Alice. Alice ønsker å gjøre det uten å oppgi noen hemmelig informasjon til Eve (som tyvlytting på samtalen) eller Mallory (som har en tendens til å etterligne Bob og Alice for å lure dem til å avsløre sine hemmeligheter). Videre ønsker Alice å bruke samme metode for autentisering for å bevise sin identitet til Sue, og hun ønsker ikke å sette sitt eget, Bob eller Sue sikkerhet i fare i tilfelle enten Bob eller Sue blir compromised.Cryptographic PrimitivesHash funksjoner

    En Cryptographically Secure Hash Function vil forvandle innspill uansett lengde til en fast størrelse utgang kode, kjent som Digest av input. Spredefunksjonen har følgende egenskaper:

    1. Det er beregningsmessig umulig å finne noen data som hasher til en gitt vilkårlig fordøye. Med andre ord en kryptografisk sikre hashfunksjon ikke lett kan snus, men er beregnings One-Way. Denne egenskapen er også kjent som Primary Preimage Resistance.

    2. Det er beregningsmessig umulig å finne to forskjellige innganger som hasj til samme fordøye verdi. En kryptografisk sikre hashfunksjon er Kollisjon Free. Denne egenskapen er også kjent som sekundær Preimage Resistance

      Som en konsekvens av disse to eiendommene en hash-funksjon kan brukes til følgende formål:.

      (*) La T A og T B være to innganger og la D A og D B være det respektive fordøye verdier av disse to innganger. Hvis D A = D B så itis sikre å antyde at T A = T B.StreamSec Tools Bruk

      Følgende kode beregner SHA-1 digest av innholdet i AnsiString aText. SHA-1 digest er en 20 tegnstreng muligens bestående av ikke-utskrivbare 8-bits tegn bruker
      stSecUtils, stSHA1; ... lDigest:. = DigestString (haSHA1, aText), eksempel 1 (Fair men usikret bruk)

      Alice sender digest D En av hennes hemmelige passord T A til Bob. Bob ser opp Alice i sin brukerdatatable, blir den lagrede verdien D A 'og bekrefter at D A = D A'. Den faktiske verdien av T A er ikke avdekket under denne proceess.Example 2 (angrep)

      Eve erkjenner verdien D En sendt av Alice i eksempel 1. Eve kobles til Bob og sender D EN. Bob blir lurt i å tro at Eva er Alice. Dette er kjent som en Replay Attack.Example 3 (angrep)

      Harry registrerer et stort antall personligheter med Bob tjeneste. Senere Harry er i stand til å stjele Bob brukerdatatable. Harry utfører et søk på datatable og finner ut at verdien D A for Alice er identisk med verdien D B for en av Harrys falske personligheter. Harry er i stand til å antyde at Alice hemmelige passord T A er identisk med passordet T B for sin tilsvarende falske personality.Example 4 (Begrensninger)

      Det er ikke uvanlig at distributører av Open Source programvare er publisering MD5-sammendrag av hver fil sammen med selve filen. Denne ordningen gir svært lite sikkerhet på grunn av de generelle egenskapene til hash funksjoner. Hvis du får et par A, D A > du er i stand til å verifisere at D A er faktisk en gyldig sammendrag av T A, men det er ingen måte for deg å kontrollere at T A og D En havenot både blitt erstattet av noen annet enn distributøren. Anyoneis stand til å generere en gyldig MD5-sammendrag av anything.Keyed hash funksjoner

      En tastet hash funksjon er en hash-funksjon med ekstra eiendom som en gyldig digest (også kjent som en meldingsautentiseringskode eller MAC) kan bare beregnes av noen som kjenner en bestemt hemmelig nøkkel. Den vanligste typen Tastet hashfunksjon er HMAC. HMAC funksjonen fungerer med alle MD4 typen hash funksjoner, som for eksempel MD5 og RIPEMD og SHA familie av hash funksjoner, og fungerer ved hashing input to ganger og blande i nøkkelen materiale med forskjellige polstringer hver gang.

      Tastet hash funksjoner bruker symmetriske nøkler, noe som betyr at både thesender og mottakeren av en melding må etablere den samme nøkkelen.

      (*) La T A og T B være to innganger, K A og K < SUB> B to nøkler og la M A og M B være de respektive MAC verdiene av disse to innganger. Hvis M A = M B så er det trygt å antyde at både T A = T B og K A = K B.StreamSec Tools Bruk

      Den følgende kode beregner HMAC SHA-1-verdien for innholdet i AnsiString aText. MAC er høyst en aLength tegnstreng (høyst samme lengde som den digest lengden av den underliggende hash-funksjon) eventuelt bestående av ikke-skriv 8-bits tegn benytter
      stSecUtils, stSHA1;. ... lMAC: = HMACString (haSHA1, aKey, aLength, aText), eksempel 5 (Fair men ikke sikker bruk)

      Alice sender MAC M KA av strengen "Alice" og hennes hemmelige passord T En som nøkkelen til Bob. Bob ser opp Alice i sin brukerdatatable, blir den lagrede verdien M KA "og bekrefter at M KA = M KA '. Den faktiske verdien av T A er ikke avdekket under denne proceess.Example 6 (angrep)

      Eve erkjenner verdien M KA sendt av Alice i eksempel 1. Eve kobles til Bob og sender M KA. Bob blir lurt i å tro at Eva er Alice.Example 7 (Mislykket angrep)

      Harry registrerer et stort antall personligheter med Bob tjeneste. Senere Harry er i stand til å stjele Bob brukerdatatable. Harry utfører et søk på datatable, men er ikke i stand til å finne noen MAC-verdier som er identiske, siden HMAC er kollisjon gratis og Bob håndhever regelen om at brukernavnene må være unique.Example 8 (Begrensning)

      Ved hjelp av en Tastet hashfunksjon for å bevise integritet og autentisitet av offentlige filer er sjelden et alternativ.

      For det første bruker en HMAC en symmetrisk nøkkel. Dette betyr at både avsender og mottaker er i stand til å generere en gyldig MAC av alle typer inngangs tekst. Hvis Alice, Bob og Carol alle deler den samme hemmelige HMAC nøkkel, er det ingen måte for Alice å fortelle om en gitt MAC verdi ble beregnet ved Bob eller av Carol.

      For det andre, en kodede hash-funksjonen vil ikke gi noen sikkerhetsfordeler over en vanlig (unkeyed) hash-funksjon med mindre nøkkelen holdes hemmelig. Hvis du publiserer et par A, M KA > ingen som ikke vet nøkkelen K vil være i stand til å bekrefte at M KA er faktisk en gyldig MAC av T A.Other ConceptsSalt og nNår

      Skillet mellom en Salt og et nonce flyter , men er nevnt her for klarhet:


        Begge er generert på en måte som er designet for å gjøre dem unike i sammenheng, for eksempel av en kryptografisk sikre Random Generator som Yarrow.

      • Begge brukes på en slik måte at de ikke trenger å holdes hemmelig, men kan overføres over ubeskyttede kanaler.

      • Begge er vanligvis blandet med hemmelig materiale under en slags hash drift.

      • A Salt brukes vanligvis for å generere en Verifier verdi som består av hash av Salt og passord. Salt og Verifier lagres sammen hos mottakeren (server) side for levetiden av passord. Hvis ikke tilfeldig Salt kan være sammensetning av brukernavnet mottaker og avsender brukernavn.

      • Et salt er mer presist vanligvis brukt for å lage passord-hasher er lagret i serversiden bruker datatables unike. Konferere eksempel 4 og eksempel 8 ovenfor.

      • En nNår brukes vanligvis bare én gang for en enkelt økt håndtrykk eller for enkeltmeldinger. Hvis det ikke er generert tilfeldig kan det være en tidsstempel eller en auto inkrementert vedvarende telleren. Nonces brukes vanligvis i challenge-response protokoller for å hindre angrep av den art som er beskrevet i eksempel 2 og eksempel 6 ovenfor.
        Challenge-response Protocols

        En vanlig måte for å unngå noen av angrepene er skissert i det foregå seksjoner er å bruke Challenge-Response Protokoller. Disse protokollene bland i tilfeldig materiale med passordene. Gjort riktig dette gjør det umulig å generere gyldige protokoll meldinger uten hemmelig informasjon som bare de legitime parter antas å ha

        Disse protokollene vil bare utgangs en binær Ja eller nei på spørsmålet. Var innkommende protokoll meldinger autentisk? Mer forseggjorte protokoller vil i tillegg sende ut en sesjonsnøkkel som brukes for å beskytte konfidensialiteten og meldingsintegritet av følgende bulk meldinger. Sikkerhets fordelene ved bruk av slike protokoller bør ikke undervurderes, siden de innebærer at konfidensialitet og integritet bulk innholdet er nært knyttet til den Entity Authentication etablert under autentiseringsfasen av protokollen.

        Challenge-Response protokoller er tradisjonelt utformet å være enten to-pass eller Tre-Pass. To-Pass Challenge-Response-protokoller brukes til å autentisere klienten til serveren, men ikke serveren til klienten. Dette avsnittet skisserer to Tre-Pass protokoller som skal godkjenne både klienten og serveren til hver other.Protocol # 1

        Denne protokollen er designet for situasjoner der hastigheten på thenetwork er den største flaske neck.Preparations:

        Hver klientforetaket Carol registrerer seg med serveren entitySue. Enten Carol eller Sue genererer følgende verdier:

        Salt [Carol]: = HMACString (haSHA1, realname [Carol], 20, realname [Sue]);

        Verifier [Carol]: = HMACString (haSHA1, Salt [ ,,,0],Carol], 20, passord [Carol]);

        Sue registrerer realname [Carol] og bekreft [Carol]

        • Det er ikke viktig for driften av selve protokollen hvis Carol eller Sue. genererer bekreft [Carol] verdi, ettersom Sue ikke vil bruke passord [Carol] på noe tidspunkt under selve protokollen. Det er imidlertid viktig at verdiene som sendes mellom Carol og Sue under registreringsfasen er garantert å være både fortrolig og autentisk. Videre bør Carol sende Verifier [Carol] i stedet for passord [Carol] hvis hun har til hensikt å bruke det samme passordet til andre formål. Det er beregningsmessig umulig å utlede Passord [Carol] fra Verifier [Carol].

        • Verdien av Salt [Carol] må være unik. Særlig bør realname [Sue] settes til enhver informasjon som fullt ut identifisere particul tjenesten betegnet "Sue" her, for eksempel en full URI inkludert protokollen, vertsnavn og bane, eventuelt blandet med statisk informasjon fra Sue Server Hei melding. Alternativt Salt [Carol] kan genereres tilfeldig, men det ville kreve at Salt [Carol] lagres av Sue og sendes tilbake til Carol under protokollen. Det antas at hvis Salt [Carol] blir generert i henhold til definisjonen ovenfor, kan både Carol og Sue uavhengig regenerere verdien på et senere tidspunkt.

        • Sue må
          holde bekreft [Carol] verdi konfidensielt. Det vil typisk være lagret i en brukerdatatable, og hvis dette datatable er kompromittert hver bruker blir nødt til å generere nye Verifier verdier. Det er viktig
          tonote at det er umulig å generere nye Verifier verdier hvis ingen av verdiene realname [Sue], realname [Carol] eller passord [Carol] endres, siden Verifier [Carol] er en deterministisk funksjon av disse verdiene. Sue må
          dermed endre realname [Sue] hvis funksjonene beskrevet ovenfor brukes og brukeren Datatable er kompromittert. Et alternativ er å bruke tilfeldig genererte Salt verdier
          Trappen og meldinger:.

          1. Sue genererer en tilfeldig nonce Nonce_S.

          2. Sue - > Carol:

            Nonce_S

          3. Carol genererer en tilfeldig Nonce_C.

          4. Carol beregner Verifier [Carol] som beskrevet ovenfor.

          5. Carol beregner Temp1: = HMACString (haSHA1, Verifier [Carol], 20, Nonce_S);

          6. Carol beregner Response_C: = HMACString (haSHA1, Temp1,20, Nonce_C);

          7. Carol - > Sue:
            realname [Carol], Nonce_C, Response_C

          8. Sue ser opp realname [Carol] i brukerdatatable og får Verifier [Carol].

          9. Sue beregner Response_C som beskrevet ovenfor, og sammenligner det med den fikk fra Carol verdi. Hvis verdiene ikke sams Sue avbryter, noe som resulterer i protokollen output "Nei".

          10. Sue beregner Temp2: = HMACString (haSHA1, Verifier [Carol], 20, Nonce_C);

          11. Sue beregner Response_S: = HMACString (haSHA1, Temp2,20, Nonce_S);

          12. Sue - > Carol:
            Response_S

          13. Carol beregner Response_S som beskrevet ovenfor, og sammenligner det med den fikk fra Sue verdi. Hvis verdiene ikke sams Carol avbryter, noe som resulterer i protokollen output "Nei".

          14. Output "Ja".
            Protocol # 2

            Denne protokollen er en variant av protokoll # 1 med den forskjellen at Salt [Carol] verdi genereres tilfeldig og er lagres i Sue brukerdatatable. Implikasjonene av dette har allerede vært discussed.Steps og meldinger:

            1. Carol genererer en tilfeldig Nonce_C.

            2. Carol - > Sue:
              realname [Carol], Nonce_C

            3. Sue ser opp realname [Carol] i brukerdatatable og får Salt [Carol], Verifier [Carol].

            4. Sue genererer en tilfeldig verdi Challenge

            5. Sue beregner Nonce_S: = HMACString (haSHA1, Challenge, 20, realname [Sue]);

            6. Sue beregner Temp1: = HMACString (haSHA1, Verifier [Carol], 20, Nonce_C);

            7. Sue beregner Response_S: = HMACString (haSHA1, Temp1, Nonce_S);

            8. Sue - > Carol:

              Challenge, Salt [Carol], Response_S

            9. Carol beregner Verifier [Carol]: = HMACString (haSHA1, Salt [Carol], 20, passord [Carol ]);

            10. Carol beregner Nonce_S som beskrevet ovenfor.

            11. Carol beregner Response_S som beskrevet ovenfor, og sammenligner det med den fikk fra Sue verdi. Hvis verdiene ikke sams Carol avbryter, noe som resulterer i protokollen output "Nei".

            12. Carol beregner Temp2: = HMACString (haSHA1, Verifier [Carol], 20, Nonce_S);

            13. Carol beregner Response_C: = HMACString (haSHA1, Temp2,20, Nonce_C);

            14. Carol - > Sue:
              Response_C

            15. Sue beregner Response_C som beskrevet ovenfor, og sammenligner det med den fikk fra Carol verdi. Hvis verdiene ikke sams Sue avbryter, noe som resulterer i protokollen output "Nei".

            16. Output "Ja".
              Andre hensyn

              Et fellestrekk ved både protokoll # 1 og protokoll # 2 er at den eksklusive bruken av symmetriske kryptografiske primitiver (HMAC) gjør brukerdatatable ekstremt følsomme for kompromiss. Protokollene vil bare
              gi foretaket autentisering hvis Sue klarer å holde brukeren datatable både fortrolig og autentisk. Ved hjelp av en Salt i beregningen av de Verifier verdier vil
              beskytte konfidensialiteten av passordene, men det vil ikke
              hindre en angriper som henter Verifier verdier fra simulere trinnene og meldinger av Carol i enten protokoll # 1 og # 2 protokoll. Dersom en slik beskyttelse er nødvendig med en annen protokoll som anvender Asymmetic kryptografisk primitiver, slik som SRP, bør benyttes.

              Et annet hensyn er at både protokoll # 1 og protokoll # 2 vil bare sende ut et binært Ja eller nei, noe som betyr at Utgangen fra protokollen er ikke nødvendigvis knyttet til konfidensialitet og integritet til bulk innholdet i sesjonen. Særlig bør det bemerkes at Nonces som brukes som en del av protokollene vil beskytte mot Replay angrep av den typen som er beskrevet i eksempel 2 og eksempel 6, men de vil ikke beskytte mot man-in-the-middle-angrep: Eksempel 9 (angrep)

              Dette er et eksempel på hvordan et man-in-the-middle (Mallory) kan angripe Protocol # 2. Det finnes en tilsvarende angrep mot Protocol # 1.

              1. Mallory triks Carol til å tro at Mallory er Sue. Vanskeligheten med denne bedrag avhenger av et stort antall faktorer, som integriteten av nettverk samt mulige feil implementering i mekanismen Carol bruker for å knytte realname [Sue] med en bestemt tjeneste.

              2. Carol - > Mallory:
                realname [Carol], Nonce_C

              3. Mallory - > Sue:
                realname [Carol], Nonce_C

              4. Sue - > Mallory:

                Challenge, Salt [Carol], Response_S

              5. Mallory - > Carol:

                Challenge, Salt [Carol], Response_S

              6. Carol - > Mallory:
                Response_C

              7. Mallory - > Sue:
                Response_C

              8. Sue utganger "Ekte". Carol utganger "Ekte".

                Det siste trinnet kan medføre at Carol tror hun har bekreftet at Mallory er Sue, eller at Sue tror hun har bekreftet at Mallory er Carol. Det er viktig å merke seg at verken Protocol # 1 eller protokoll # 2 vil gi slike garantier. De vil bare
                bevise at meldingene stammer fra autentisert enhet, men ikke anbefale at dette vesenet nødvendigvis identisk med den andre peer. Vær også oppmerksom på at dette ikke nødvendigvis er en dårlig ting (tror Proxy, Midt-Tier og Load Balancing), men at sikkerhets implikasjoner ofte gjør det ekstremt vanskelig å bruke disse protokollene appropriately.Asymmetric Challenge-Response Protokoller

                Dette avsnittet skisserer en enkelt protokoll som er onlined etter theSecure Remote Password Authentication Protocol (SRP) av Thomas Wu fra Stanford University. Protokollen er relativt komplisert, men gir en rekke sikkerhetstjenester som gjør det interessant å investere tid i å implementere det. Sitert fra den opprinnelige papir:


                  En angriper med verken brukerens passord eller vertens passordfilen kan ikke montere en ordbok angrep på passordet. Gjensidig godkjenning er oppnådd i dette scenariet.

                  • En angriper som fanger vertens passordfilen kan ikke direkte kompromiss bruker-til-vert autentisering og få tilgang til verten uten en kostbar ordbok søk.

                    • En angriper som kompromitterer verten ikke skaffe passordet fra en legitim godkjenning forsøk.

                      • En angriper som fanger sesjonsnøkkel kan ikke bruke den til å montere en ordbok angrep på passordet.

                        • En angriper som fanger brukerens passord kan ikke bruke den til å gå på akkord med øktnøkler av tidligere økter.
                          Eksempel

                          Nedenfor er klientsiden SRP kode, tatt fra SRP demo i Varianter mappen Var
                          LA, LB, IX, LV, LS: Variant; lAPriv: Variant; lSalt: string
                          ; LK: OctetString; LM1, LM2: string
                          ; begynne
                          Connect; //en, er A klienten flyktig nøkkelen, Diffie-Hellman stil
                          lAPriv: = RandomPrivateKey; lA: = VarMPIntegerExpMod (2, lAPriv, P); //C - > S: bruker, A
                          Send ('bruker', edtUsername.Text); Send ('A', LA); //S - C: salt, B
                          lSalt: = Read ('salt'); LB: = Read ('B'); //B er serveren offentlig nøkkel flyktig, Diffie-Hellman stil, blandet
                          //med klienten V verdi som er lagret i serveren brukerdatatable
                          //sammen med salt og brukervennlig.
                          //klienten må avbryte hvis B = 0
                          hvis
                          (LB mod
                          P) = 0 deretter
                          begynne
                          Error (misbrukt autorisasjon '); end
                          ; //X er klienten langsiktig privat nøkkel og er avledet fra passord
                          IX: = HashPassword (lSalt, edtUsername.Text, edtPassword.Text); //V er kundens kontrolløren 'eller lang sikt offentlige nøkkel.
                          //den brukes i SRP-protokollen på en slik måte at det ikke kan utledes av
                          //en angriper fra protokoll meldinger. Dette gjør en ordbok angrep
                          //mot brukerpassord like hardt som løse Discrete Logg Problem
                          lV: = VarMPIntegerExpMod (2, IX, P); //The 'faktiske' server offentlig flyktig Nøkkelen er B-V. Det er hevet av klienten
                          //til en strøm (a + u * X) som også skjuler verdien av X bak hardhet
                          //Discrete Log problem. S er den delte hemmeligheten utgangen av denne operasjonen
                          LS: = VarMPIntegerExpMod (LB-LV, lAPriv + IX * CalculateU (LB), P); //K er den delte nøkkelen som er avledet fra den delte hemmeligheten S
                          LK: = SHA_Interleave (LS); //M1 er klienten ferdig meldingen. Det kan bare beregnes av klienten
                          //og av serveren. Formålet med denne meldingen er å bevise at klienten
                          //avledet den samme verdien av K som server, og dermed at kunden vet
                          //passordet
                          LM1: = FinishHashClient (edtUserName.Text, lSalt, LA, LB, LK); //C - > S: M1
                          Send ('M1', LM1); //S - > C: M2
                          LM2: = Read ('M2'); //M2 er serveren ferdig meldingen. Det kan bare beregnes av serveren
                          //og av klienten. Formålet med denne meldingen er å bevise at serveren
                          //avledet den samme verdien av K som klient, og dermed at serveren vet
                          //V bekreft verdi Anmeldelser hvis
                          LM2 < > FinishHashServer (LA, LM1, LK) deretter
                          begynne
                          Error (misbrukt autorisasjon '); end annet
                          SetKey (LK); Anmeldelser