Blog

i et tidligere indlæg diskuterede AppRiver, hvordan de ansvarlige for Solvindangrebet havde misbrugt tokens og certifikater som en del af deres infektionskæde. De ondsindede aktører fortsatte med at misbruge de samme typer aktiver i yderligere kampagner rettet mod andre enheder. Dette resulterede i en bekræftet certifikatsikkerhedshændelse hos en e-mail-sikkerhedsudbyder.

ved at anerkende disse ondsindede aktiviteter følte AppRiver det nødvendigt at give sine kunder en række artikler, der diskuterer de berørte typer godkendelsesmetoder, og hvordan de fungerer. Vi begynder med tokenbaseret godkendelse.

tokenbaseret godkendelse: en oversigt

tokenbaseret godkendelse adresserer nogle af begrænsningerne ved sessionsbaseret godkendelse. I sidstnævnte opretter en server en session for en bruger, når de logger ind. Den gemmer sessions-ID ‘ et i en cookie, som ledsager alle efterfølgende anmodninger, hvis brugeren forbliver logget ind. Serveren verificerer derefter en brugers identitet ved at sammenligne cookien med de sessionsdata, der er gemt i hukommelsen.

problemet her er, at sessionsbaseret godkendelse lider af visse ulemper. For det første kræver det, at serveren gemmer sessioner i sin hukommelse. Der er også spørgsmålet om cookies, der fungerer på tværs af flere enheder af forskellige medier (f.eks.

det er her token-baseret godkendelse kommer ind. Denne form for godkendelse involverer en applikation, der leverer et underskrevet token til klienten ved validering af et sæt brugeroplysninger. Klienten gemmer det token og sender det med hver anmodning, på hvilket tidspunkt serveren verificerer token og sender information.

i denne forstand adskiller tokenbaseret godkendelse sig fra sessionsbaseret godkendelse, idet den er statsløs. Det indebærer ikke lagring af oplysninger om en bruger på en server eller i en session. Det gemmer disse data i token på klientsiden.

fordele og udfordringer ved tokenbaseret godkendelse

tokenbaseret godkendelse kommer med mange fordele. Chop-Chop bemærker, at tokens også fungerer på forskellige hjemmesider og medier, hvilket skaber en mulighed for en større mangfoldighed af brugere—især dem, der bruger mobile enheder. Oven i alt dette står tokens ind for en brugers legitimationsoplysninger i processen med at give adgang til data; en person, der kompromitterede et token, ville ikke automatisk få adgang til den berørte brugers kontooplysninger.

når det er sagt, er tokenbaseret godkendelse ikke uden udfordringer. Devbridge Group bemærker, at nogle session tokens ikke genereres på en sikker måde, for eksempel. Dette gør det muligt for en angriber med en stor nok prøve af sessions-id ‘ er at finde ud af et mønster og gætte tokens for en større pulje af brugere. Der er også spørgsmålet om angribere, der udnytter usikre tokenlagre, flere logins og/eller lange token valideringstider for at stjæle godkendelseshemmeligheder.

Sådan bruges sikkert tokenbaseret godkendelse

anerkendelse af de risici, der er diskuteret ovenfor, her er et par bedste fremgangsmåder til sikker brug af tokenbaseret godkendelse:

1. Generer stærke tokens. Devbridge anbefaler især, at tokens har et stort sæt mulige værdier, inkorporerer en grad af pseudorandomness og består af mindst 16 bytes i længden.
2. Giv tokens en udløb. Det er vigtigt at indstille betingelser for, hvor længe et token forbliver gyldigt, bemærker Auth0. Selvfølgelig, hvis en bruger stadig er aktiv, kan token automatisk fornyes. Men der er også visdom i at lade et token udløbe, når brugeren logger ud og afslutter tokenet, uanset hvad efter en vis periode er gået.
3. Tillad flere logins. Som bemærket af Devbridge er det muligt at bruge nøgleattributter til at forhindre parallelle godkendelser, hvor mere end en person interagerer med den samme brugerkonto samtidigt.
4. sikkert gemme tokens. Lokal opbevaring er ikke vejen at gå her. DEV Community anbefaler brugen af en cookiepolitik kaldet SameSite til at specificere betingelserne for, at en cookie kan overføres i en anmodning på tværs af domæner. En streng SameSite-politik sammen med kravet om, at folk skal have en bro.serversion, der understøtter denne funktionalitet, hjælper med at holde session-tokens sikre.