Innlogging: passord, tofaktorautentisering og brute force

Modul 7: Sikkerhet · Lesetid: 9 minutter

Læringsmål: Etter denne leksjonen kan du beskytte innloggingen til nettstedet ditt med sterke passord, tofaktorautentisering og begrensning av innloggingsforsøk, og du vet hva xmlrpc.php er.

Nøkkelbegreper: passordbehandler, passordfrase, unikt passord, tofaktorautentisering (2FA, TOTP), passkey, brute force, begrense innloggingsforsøk, wp-login.php på IP-adresse, xmlrpc.php, brukernavn som lekker (REST, ?author=), applikasjonspassord

Passordet: langt og unikt

Et godt passord har to egenskaper:

1. Langt: lengde teller mer enn rare tegn. En passordfrase med fire eller fem tilfeldige ord (sil-pingvin-oktober-lykt) er sterkere og lettere å huske enn W8w00rd!. Nederlandske myndigheters kampanje Veilig Internetten anbefaler et unikt passord på minst 12 tegn, helst en passordfrase.
2. Unikt: brukes ikke andre steder. Credential stuffing (leksjon 7.1) fungerer bare hvis du gjenbruker et passord.

Ingen husker titalls lange unike passord. Bruk derfor en passordbehandler: et program som lager, lagrer og fyller dem inn for deg. Da trenger du bare å huske ett: passordet til selve behandleren, og det sikrer du også med tofaktorautentisering.

Om et passord finnes i et kjent datainnbrudd, kan du sjekke på haveibeenpwned.com. Står e-postadressen din i et innbrudd, bytt passordet hos alle tjenester der du brukte det samme passordet.

Tofaktorautentisering

Med tofaktorautentisering (2FA) trenger du ved innlogging noe mer enn passordet: vanligvis en kode på seks sifre fra en app på telefonen (en autentiseringsapp, etter standarden TOTP). En inntrenger med passordet ditt kommer da likevel ikke inn.

WordPress har ikke innebygd tofaktorautentisering. Du legger det til med en utvidelse. Det finnes mange; en enkel er Two Factor, laget av bidragsytere til WordPress selv. Også sikkerhetsutvidelser har det ofte innebygd. Vær oppmerksom på følgende når du velger:

• TOTP-apper og backup-koder (for når du mister telefonen); koder på e-post er svakere, fordi postkassen din også kan bli hacket;
• mulighet til å kreve det for administratorer og redaktører;
• passkeys: logg inn med fingeravtrykk, ansikt eller en sikkerhetsnøkkel, uten passord. Det finnes utvidelser for dette også. Passkeys er motstandsdyktige mot phishing, fordi de bare fungerer på det ekte nettstedet.

Skru på tofaktorautentisering også på alt som ligger rundt nettstedet ditt: kontrollpanelet for webhotellet, e-posten din, registraren din og passordbehandleren din. En inntrenger som overtar kontrollpanelet ditt, trenger ikke WordPress-passordet ditt.

Brute force og begrensning av innloggingsforsøk

Et åpent WordPress-nettsted får innloggingsforsøk på wp-login.php hele dagen, ofte med admin og lister med vanlige passord. Med et langt passord og 2FA kommer de ikke inn, men hvert forsøk koster serveren din regnekraft (en full WordPress-oppstart). Ved en stor bølge blir nettstedet ditt tregt.

WordPress selv begrenser ikke antall forsøk. Det som hjelper, i rekkefølge etter «stoppe tidligst mulig»:

1. På serveren: mange webhotell blokkerer en IP-adresse som gjør mange mislykkede forsøk på kort tid, allerede før WordPress starter (med en brannmur eller en webserverfunksjon). Spør webhotellet ditt hva som skjer.
2. wp-login.php bare for din egen IP-adresse: med noen linjer i .htaccess (hos LiteSpeed og Apache):

<Files wp-login.php>
Require ip 192.0.2.10
</Files>

Dette fungerer bra hvis du har en fast IP-adresse. Har du ikke det (hjemmefra, på telefonen), stenger du deg selv ute når adressen endres. Et alternativ er et ekstra passord på innloggingssiden (en «beskyttet mappe», basic authentication) med et annet passord enn WordPress-passordet ditt.

3. En utvidelse som begrenser forsøk: etter fem mislykkede forsøk blokkeres IP-adressen en stund. Fungerer, men først etter at WordPress allerede kjører, så regnekraften brukes likevel.

Å skjule eller gi nytt navn til innloggingssiden (for eksempel /min-login i stedet for /wp-login.php) reduserer støyen i loggen din. Det er ikke ekte sikkerhet, og enkelte utvidelser og temaer forventer standardadressen. Fint som ekstra tiltak, aldri i stedet for et godt passord og 2FA.

xmlrpc.php

xmlrpc.php er en gammel kobling fra tiden før REST API, som apper og andre nettsteder bruker for å snakke med WordPress. Den brukes fortsatt av noen apper, av Jetpack og av noen koblinger. For de fleste nettsteder er den overflødig.

Inntrengere liker xmlrpc.php, fordi du kan prøve hundrevis av passord samtidig i én forespørsel (med funksjonen system.multicall), og fordi den kan misbrukes til angrep på andre nettsteder (pingbacks). Det du gjør:

• Bruker du den ikke: blokker den. Noen webhotell, inkludert WebOké, blokkerer xmlrpc.php som standard på serveren. Ellers med en linje i .htaccess eller med en sikkerhetsutvidelse.
• Bruker du den (for eksempel til en app som trenger det): la den være åpen, men sørg for sterke passord, 2FA og begrensning av forsøk. Moderne apper bruker som regel REST API med et applikasjonspassord (leksjon 3.3).

Brukernavn som lekker

I leksjon 3.3 så du at WordPress viser en avledning av brukernavn:

• https://example.com/?author=1 sender videre til /author/<navn>/;
• https://example.com/wp-json/wp/v2/users viser en liste med slugene til alle som har publisert noe.

Er det ille? Et brukernavn er ikke et passord. Med et langt unikt passord og 2FA betyr det lite. Men det gir en inntrenger halvparten av innloggingsopplysningene og gjør målrettet phishing lettere. Rimelige tiltak:

• gi administratorer et brukernavn som ikke er deres offentlige navn, og publiser ikke med en administratorkonto (leksjon 3.3);
• begrens brukerlisten i REST API med en sikkerhetsutvidelse eller noen linjer kode, hvis du ikke trenger den. Steng ikke REST API helt: blokkredigereren og mange utvidelser trenger den.

Applikasjonspassord

Applikasjonspassord (leksjon 3.3) er en trygg måte å gi en app eller et system tilgang på, men de omgår tofaktorautentiseringen din: en app med et applikasjonspassord trenger ingen kode. Lag dem bare når det er nødvendig, på en konto med en lav rolle, og trekk dem tilbake når du ikke lenger bruker koblingen.

Oppsummering

• Bruk lange, unike passord (passordfraser) i en passordbehandler.
• Skru på tofaktorautentisering, med en utvidelse i WordPress og også på kontrollpanelet for webhotellet, e-posten og registraren din.
• Stopp innloggingsforsøk så tidlig som mulig: på serveren, med en IP-regel eller et ekstra passord, eller med en utvidelse.
• Blokker xmlrpc.php hvis du ikke bruker den.
• Lekkede brukernavn er ingen katastrofe, men et signal: ikke publiser som administrator, og begrens REST-brukerlisten hvis du ikke trenger den.

Quiz

Oppgave

Oppgave A7.3: Hva avslører nettstedet ditt ved innlogging? Fyll inn adressen til nettstedet ditt og bevis at det er ditt eget nettsted (med kontrollkoden for oppgaven, som TXT-post eller som fil). Programmet sjekker tre ting: om xmlrpc.php returnerer en liste med funksjoner (åpen) eller er blokkert, om /wp-json/wp/v2/users viser brukernavn (slugs), og hvor /?author=1 sender deg videre til. Fyll inn om du trenger xmlrpc.php; hvis ikke, er en åpen xmlrpc.php rød. Lekkede slugs er oransje med forklaring.

Oppgave D7.3: Slå på tofaktorautentisering. Skru på tofaktorautentisering for alle administratorer av WordPress-nettstedet ditt, og også på kontrollpanelet for webhotellet og e-posten din. Lagre backup-kodene i passordbehandleren din. Kryss av for hver del at den er aktivert, og noter hvilken metode du bruker (app, passkey, e-post) og hvor backup-kodene oppbevares. Noter også hvordan du beskytter wp-login.php ekstra, og hvorfor du velger den metoden.

Les mer

Disse artiklene beskriver trinnene i kontrollpanelene til WebOké; i andre kontrollpaneler fungerer de på lignende måte.

• DirectAdmin-veiledning 3.7: Sikre passord og hva du gjør hvis et passord er lekket
• To-faktor-autentisering i Mitt WebOké og sette opp en autentiseringsapp
• Tilgang til WordPress xmlrpc.php fungerer ikke
• Sikre wp-login.php i WordPress
• DirectAdmin-veiledning 15.9: Passordbeskyttede mapper
• Sikker innlogging (Veilig Internetten, nederlandske myndigheter): https://veiliginternetten.nl/veilig-inloggen/
• Brute force-angrep (developer.wordpress.org, engelsk): https://developer.wordpress.org/advanced-administration/security/brute-force/