Autentisering eller autentisering [ 1 ] er handlingen eller prosessen for å bekrefte at noe (eller noen) er den det utgir seg for å være . Den delen som er identifisert kalles en tester . Parten som verifiserer identiteten kalles en verifikator . Det er vanlig at testeren er en bruker som ønsker å få tilgang til visse ressurser, og at verifikatoren er et system som beskytter tilgangen til nevnte ressurser og må verifisere at personen som får tilgang til er en bruker som har tilgang til disse ressursene. For å ha autentisering er det nødvendig, som en tidligere betingelse, at det eksisterer toentydig identifiserte identiteter på en slik måte at oppgaven tillates utført
Autentisering eller autentisering (ord foretrukket av RAE [ 2 ] ) eller bedre sagt akkreditering, når det gjelder datanettverkssikkerhet , kan betraktes som ett av de tre grunnleggende trinnene ( AAA ). Hver av dem er, i rekkefølge:
Ofte er autorisasjonsproblemet identisk med autentiseringsproblemet; mange bredt vedtatte standard sikkerhetsprotokoller, obligatoriske forskrifter og til og med vedtekter er basert på denne antakelsen. Imidlertid beskriver mer nøyaktig bruk autentisering som prosessen med å verifisere en persons identitet, mens autorisasjon er prosessen med å bekrefte at en kjent person har autoritet til å utføre en bestemt operasjon. Autentisering må derfor gå foran autorisasjon. [ referanse nødvendig ]
For å skille autentisering fra det nært beslektede begrepet autorisasjon, er det noen få stenografiske notasjoner , A1 for autentisering og A2 for autorisasjon, som brukes med en viss frekvens. Det er også begrepene AuthN og AuthZ, som brukes i noen samfunn. [ referanse nødvendig ]
Det garanterer at deltakerne i en kommunikasjon er den de sier de er. Det vil si at det er en prosess for å demonstrere identiteten til en part før de andre, på en pålitelig måte.
DataopprinnelsesautentiseringDet garanterer ektheten av opprinnelsen til dataene, det vil si at de kommer fra der de skal komme fra.
Autentiseringsmetodene som brukes avhenger av de som brukes for verifisering, og disse faller inn i fem kategorier:
kan også være
direkteI autentiseringsprosessen er bare interesserte parter eller parter som skal autentiseres involvert.
HintEn pålitelig tredjepart griper inn i prosessen, fungerer som en myndighet eller dommer, som garanterer identiteten til de involverte partene.
EnsidigBare den ene delen er autentisk for den andre. Den andre parten er ikke autentisk før den første.
GjensidigBegge parter må autentisere hverandre.
Ethvert identifikasjonssystem må ha visse egenskaper for å være levedyktig:
For å autentisere er det nødvendig å etablere en kommunikasjonsprotokoll mellom partene, slik at den verifisere parten vanligvis verifiserer at parten som identifiserer seg (vanligvis en bruker ) faktisk er den den sier den er. Generelt består autentiseringsprosessen av følgende trinn:
Et kjent eksempel er adgangskontroll. Et datasystem som kun er ment å brukes av autoriserte, må søke å oppdage og ekskludere uautoriserte. Tilgang til den kontrolleres derfor generelt ved å insistere på en autentiseringsprosedyre for å etablere med en viss grad av tillit identiteten til brukeren, og dermed gi de rettighetene som kan være autorisert til denne identiteten. Vanlige eksempler på tilgangskontroll som involverer autentisering inkluderer:
For å forsøke å bevise identiteten til et emne eller objekt er det mulig å ta en eller flere prøver som, hvis bestått, tidligere er erklært tilstrekkelige til å fortsette. Problemet er å avgjøre hvilke tester som er tilstrekkelige, og mange slike er utilstrekkelige. Det har vært mange tilfeller av at slike tester har blitt lurt; de har ved sin påviste, uunngåelige feil å være utilstrekkelig. Mange mennesker fortsetter å se på tester - og beslutningen om å se på suksess i forbifarten - som akseptabelt, og å skylde på feilen deres på "forsiktighet" eller "inkompetanse" fra andres side. Problemet er at testen skulle fungere i praksis -- ikke under ideelle forhold med uforsiktighet eller inkompetanse.
Autentiseringsfaktorer for mennesker er generelt klassifisert i fire tilfeller:
Noen ganger brukes en kombinasjon av metoder, for eksempel et bankkort og en PIN-kode, i dette tilfellet brukes begrepet "tofaktorautentisering". Historisk sett har fingeravtrykk blitt brukt som den mest autoritative metoden for autentisering, men nyere rettslige prosesser i USA og andre steder har reist grunnleggende spørsmål om pålitelighet av fingeravtrykk. Andre biometriske metoder viser lovende (netthinne- og fingeravtrykkskanning er ett eksempel), men har vist seg å være lett å lure i praksis. I en kontekst med datadata er det utviklet utfordring-svar-protokoller som gir tilgang hvis den som skal autentiseres korrekt svarer på en utfordring foreslått av verifikatoren. Det er utfordring-respons-protokoller basert på kryptografiske algoritmer kalt "kryptografiske utfordring-respons-protokoller" . Sikkerheten til kryptografiske utfordring-respons-protokoller er basert på sikkerheten til kryptografiske algoritmer den bruker.
Autentisering ble definert av Arnnei Speiser i 2003, mens den nettbaserte tjenesten som gir autentisering av sluttbrukere som har tilgang (Logg inn) til en Internett-tjeneste. Autentisering ligner på kredittkortverifisering for e - handelsnettsteder . Verifisering gjøres av en dedikert tjeneste som mottar input og returnerer suksess eller fiasko. For eksempel vil en sluttbruker gå inn på nettstedet ditt. Han klarer å gå inn på en nettside fra tilkoblingen som krever tilgang, hans identifikasjon som bruker og et passord for de sikrede sidene og passordet hans samtidig. Informasjonen overføres til eAuthentication-tjenesten som en spørring. Hvis tjenesten svarer vellykket, har sluttbrukeren lov til å gå inn i tjenesten fra den nettsiden med sine brukerrettigheter.
I et vanlig Unix-system har hver bruker et systemoppføringsnavn eller pålogging og en nøkkel eller passord; begge dataene er vanligvis lagret i filen /etc/passwd. Denne filen inneholder en linje per bruker hvor nødvendig informasjon er angitt slik at brukere kan koble seg til systemet og jobbe med det, og skille de forskjellige feltene ved hjelp av ':'.
I motsetning til hva mange tror, er Unix ikke i stand til å skille brukerne med påloggingsnavnet. For operativsystemet er det som virkelig skiller en person fra en annen (eller i det minste en bruker fra en annen) UID-en til den aktuelle brukeren; påloggingen er noe som hovedsakelig brukes for å gjøre det lettere for folk (selvfølgelig er det lettere å huske et påloggingsnavn som toni enn en UID som 2643 , spesielt hvis du har kontoer på flere maskiner, hver med en annen UID) .
For å kryptere tilgangsnøklene til brukerne, bruker Unix-operativsystemet et irreversibelt kryptosystem som bruker standard C-krypteringsfunksjonen, basert på DES-algoritmen. For en utfyllende beskrivelse av hvordan krypten fungerer. Denne funksjonen tar som nøkkel de åtte første tegnene i passordet som er valgt av brukeren (hvis lengden er mindre, fylles den ut med nuller) for å kryptere en blokk med 64-bits klartekst satt til null; For å forhindre at to identiske passord resulterer i samme krypterte tekst, utføres en permutasjon under krypteringsprosessen, valgt automatisk og tilfeldig for hver bruker, basert på et felt dannet av et 12-bits tall (som vi får 4096 forskjellige permutasjoner med) kalt salt. Den resulterende chifferen krypteres på nytt ved å bruke brukerens passord igjen som nøkkel, og byttes med det samme saltet, og gjentar prosessen 25 ganger. Den siste 64-bits krypterte blokken er sammenkoblet med to nullbiter, og oppnår 66 biter som kan representeres i 11 tegn på 6 biter hver, og som sammen med saltet blir passordfeltet til passordfilen . vanligvis /etc/passwd . Dermed vil de to første tegnene i dette feltet bestå av saltet og de resterende 11 av det krypterte passordet.
Klassiske modellproblemerValgte chiffertekstangrep er hovedtrusselen mot Unix-autentiseringssystemet; I motsetning til hva mange tror, er det ikke mulig å knekke et passord, men det er veldig enkelt å kryptere et ord ved siden av et bestemt salt, og sammenligne resultatet med strengen som er lagret i passordfilen. På denne måten vil en angriper lese filen /etc/passwd (denne filen må ha lesetillatelse for alle brukere hvis vi vil at systemet skal fungere riktig), og ved å bruke et gjetteprogram (eller cracker) krypteres alle ordene til en fil kalt ordbok (en ASCII -fil med et stort antall ord fra ethvert språk eller samfunnsfelt: klassisk historie, sport, sangere ...), sammenligner resultatet oppnådd i denne prosessen med den krypterte nøkkelen til passordfilen; hvis begge stemmer, har du allerede fått en nøkkel for å få tilgang til systemet på en uautorisert måte.
En annen metode som i økende grad brukes til å beskytte brukerpassord kalles Shadow Password eller passordobscuration. Den grunnleggende ideen med denne mekanismen er å hindre brukere uten privilegier fra å lese filen der de krypterte nøklene er lagret.
Nesten alle nåværende Shadow Password-implementeringer inkluderer vanligvis implementering for en annen nøkkelbeskyttelsesmekanisme kalt Password Aging. Den grunnleggende ideen med denne mekanismen er å beskytte brukerpassord ved å gi dem en viss levetid: et passord vil bare være gyldig i en viss tid, hvoretter det utløper og brukeren må endre det.
Faktisk forhindrer aldring, mer enn problemer med nøklene, problemer med overføringen av disse over nettverket: når vi kobler oss gjennom mekanismer som telnet , ftp eller rlogin til et Unix-system, kan enhver datamaskin mellom vår og serveren lese pakkene som vi sender over nettverket, inkludert de som inneholder vårt brukernavn og passord.
Noe som Unix-brukerautentiseringsskjemaet har blitt kritisert for, er lengden, for høysikkerhetsformål, på nøklene som er for korte; Det som for år siden var lite mer enn en teoretisk tilnærming, er for tiden noe mulig: uten engang å gå inn i dedikerte maskinvareproblemer, sannsynligvis for dyrt for de fleste angripere, er det med en superdatamaskin mulig å bryte Unix-nøkler på mindre enn to dager.
En metode som øker sikkerheten til nøklene våre mot inntrengerangrep er kryptering ved hjelp av funksjonen kjent som bigcrypt() eller crypt16(), som tillater lengder for nøkler og salter som er lengre enn krypt, og likevel, selv om det øker sikkerheten til nøklene, problemet som oppstår her er inkompatibiliteten med nøklene til resten av Unices som fortsetter å bruke krypt; dette er et vanlig problem med andre tilnærminger som også er basert på å modifisere krypteringsalgoritmen, hvis du ikke bruker en ny.
PAM (Pluggable Authentication Module) er ikke en autentiseringsmodell i seg selv, men snarere en mekanisme som gir et grensesnitt mellom brukerapplikasjoner og ulike autentiseringsmetoder, og prøver dermed å løse et av de klassiske problemene med brukerautentisering: det faktum at en gang en viss mekanisme har blitt definert og implementert i et miljø, er det vanskelig å endre det. Gjennom PAM kan vi kommunisere med applikasjonene våre med autentiseringsmetodene vi ønsker på en gjennomsiktig måte, som lar oss integrere verktøyene til et klassisk Unix-system (pålogging, ftp, telnet...) med skjemaer som er forskjellige fra det vanlige passordet: nøkler til engangsbruk, biometri, smartkort...
De aller fleste linux-applikasjoner bruker disse metodene (PAM) for å autentisere mot systemet, siden en PAM-bevisst applikasjon kan endre autentiseringsmekanismen den bruker uten å rekompilere kildene. Du kan til og med endre det lokale autentiseringssystemet uten å berøre eksisterende applikasjoner.
PAM kommer "som standard" på forskjellige Unix-systemer, både gratis og kommersielle, og abstraksjonsnivået det gir tillater ting så interessante som å kerberisere autentiseringen vår (i det minste serverdelen) uten mer enn å endre PAM-konfigurasjonen, som enten er i filen /etc/pam.conf eller i forskjellige filer i katalogen /etc/pam.d/
PAM fungerer med fire separate typer administrasjonsoppgaver: autentisering, konto, økt og passord. Å knytte det foretrukne administrasjonsskjemaet til applikasjonsatferd gjøres gjennom konfigurasjonsfiler. Administrasjonsfunksjoner utføres av moduler som er spesifisert i konfigurasjonsfilen. Syntaksen for konfigurasjonsfilen vil bli kort forklart senere, da den er utenfor rammen av denne artikkelen.
Når en PAM-aktivert applikasjon starter, aktiveres kommunikasjonen med PAM API. Dette tvinger blant annet frem lesingen av konfigurasjonsfilen: /etc/pam.conf. Alternativt kan den begynne å lese konfigurasjonsfilene under /etc/pam.d/ (når en riktig konfigurasjonsfil finnes i denne katalogen, ignoreres filen /etc/pam.conf)
Filen (/etc/pam.conf) består av en liste med regler (vanligvis én per linje). Hver regel er et sett med felt atskilt med mellomrom (de tre første skiller mellom store og små bokstaver):
tjenestetype kontrollmodul-banemodul-argumenter
Syntaksen til filene under /etc/pam.d/ er den samme bortsett fra at det ikke er noe "service"-felt. I dette tilfellet er "tjeneste" navnet på filen i /etc/pam.d/-katalogen (filnavnet må være med små bokstaver) Vanligvis er tjeneste navnet på en ofte brukt tjeneste eller applikasjon, eksempler på dette er pålogging , su og ssh.
type angir hvilken ledergruppe regelen er knyttet til. Gyldige oppføringer er:
Det tredje kontrollfeltet angir hva som skal gjøres hvis den brukte kontrollen mislykkes. Det er to syntakser for dette feltet, en enkel ettfelts syntaks og en som spesifiserer mer enn ett felt innenfor hakeparenteser [] For den grunnleggende er alternativene:
Det fjerde modulbanefeltet spesifiserer banen til PAM-modulen knyttet til regelen. Modulene er plassert i /lib/security.
Det femte modulargumentfeltet er et sett med null eller flere argumenter som sendes til modulen under påkallingen. Argumentene varierer avhengig av modulen.
Å konfigurere konfigurasjonsfilene under /etc/pam.d/ viser seg å være mer fleksibel (unngå å ha en eneste stor fil). Under denne katalogen kan du finne den personlige konfigurasjonsfilen for en bestemt tjeneste som ssh. Den eneste forskjellen mellom /etc/pam.conf-filsyntaksen er at det ikke er noe tjenestefelt.