Blog

in een vorige post besprak Zix | AppRiver hoe degenen die verantwoordelijk zijn voor de SolarWinds-aanval tokens en certificaten hadden misbruikt als onderdeel van hun infectieketen. De kwaadaardige acteurs ging op dezelfde soorten activa te misbruiken in extra campagnes gericht op andere entiteiten. Dit resulteerde in een bevestigd certificaat beveiligingsincident bij een e-mail security provider.

Zix | AppRiver erkende deze kwaadaardige activiteiten en vond het noodzakelijk om zijn klanten een reeks artikelen te verstrekken waarin de betrokken soorten authenticatiemethoden en de werking ervan worden besproken. We beginnen met token-gebaseerde authenticatie.

Tokengebaseerde authenticatie: een overzicht

Tokengebaseerde authenticatie behandelt enkele beperkingen van sessiegebaseerde authenticatie. In de laatste, een server maakt een sessie voor een gebruiker wanneer ze inloggen. Het slaat de sessie-ID op in een cookie, die alle volgende verzoeken vergezelt als de gebruiker ingelogd blijft. De server controleert vervolgens de identiteit van een gebruiker door het cookie te vergelijken met de sessiegegevens die in het geheugen zijn opgeslagen.

het probleem hier is dat sessie-gebaseerde authenticatie lijdt aan bepaalde nadelen. Ten eerste vereist het dat de server sessies in zijn geheugen opslaat. Er is ook het probleem van cookies werken op meerdere apparaten van verschillende media (zoals web en mobiel).

daar komt token-gebaseerde authenticatie bij kijken. Deze vorm van verificatie omvat een toepassing die een ondertekend token aan de client verstrekt bij het valideren van een set gebruikersreferenties. De client slaat dat token op en verzendt het bij elke aanvraag, waarna de server het token verifieert en informatie meestuurt.

in deze zin verschilt token-gebaseerde authenticatie van sessie-gebaseerde authenticatie in die zin dat het statenloos is. Het gaat niet om het opslaan van informatie over een gebruiker op een server of in een sessie. Het slaat die gegevens op in het token aan de kant van de client.

voordelen en uitdagingen van Token-gebaseerde authenticatie

Token-gebaseerde authenticatie heeft vele voordelen. Chop-Chop merkt op dat tokens werken op verschillende websites en media, zo goed, die een kans voor een grotere diversiteit van de gebruikers creëert—vooral die met behulp van mobiele apparaten. Op de top van dat alles, tokens staan in voor de referenties van een gebruiker in het proces van het verlenen van toegang tot gegevens; iemand die een token gecompromitteerd zou niet automatisch toegang krijgen tot de accountgegevens van de getroffen gebruiker.

dat gezegd zijnde, OP token gebaseerde authenticatie is niet zonder zijn uitdagingen. Devbridge Group merkt op dat sommige sessietokens bijvoorbeeld niet op een veilige manier worden gegenereerd. Dit maakt het mogelijk voor een aanvaller met een groot genoeg voorbeeld van sessie-id ‘ s om erachter te komen een patroon en raden de tokens voor een grotere pool van gebruikers. Er is ook het probleem van aanvallers gebruik te maken van onveilige token opslag, meerdere logins en / of lange token validatie tijden om authenticatie geheimen te stelen.

hoe veilig gebruik te maken van op tokens gebaseerde authenticatie

de hierboven besproken risico ‘ s worden erkend, hier zijn een paar best practices voor veilig gebruik van op tokens gebaseerde authenticatie:

1. genereer sterke tokens. Devbridge raadt in het bijzonder aan dat de tokens een grote reeks mogelijke waarden bevatten, een mate van pseudorandomness bevatten en minstens 16 bytes lang zijn.
2. geef tokens een vervaldatum. Het is belangrijk om voorwaarden te stellen voor hoe lang een token geldig blijft, notes Auth0. Uiteraard, als een gebruiker nog actief is, kan het token automatisch vernieuwen. Maar er is ook wijsheid in het toestaan van een token te vervallen wanneer de gebruiker zich afmeldt en het beëindigen van de token ongeacht wat na een bepaalde periode van tijd is verstreken.
3. meerdere aanmeldingen niet toestaan. Zoals Devbridge opmerkt, is het mogelijk om belangrijke attributen te gebruiken om parallelle authenticatie te voorkomen wanneer meer dan één persoon tegelijkertijd met hetzelfde gebruikersaccount communiceert.
4. slaat tokens veilig op. Lokale opslag is niet de manier om hier te gaan. Dev Community raadt het gebruik aan van een cookiebeleid genaamd SameSite voor het specificeren van de voorwaarden waaronder een cookie kan worden doorgegeven in een domeinoverschrijdend verzoek. Een strikte samesite beleid samen met de eis dat mensen moeten een browser versie die deze functionaliteit ondersteunt zal helpen om session tokens veilig te houden.