Inloggning: lösenord, tvåfaktorsautentisering och brute force

Modul 7: Säkerhet · Lästid: 9 minuter

Lärandemål: Efter den här lektionen kan du skydda inloggningen till din webbplats med starka lösenord, tvåfaktorsautentisering och begränsning av inloggningsförsök, och du vet vad xmlrpc.php är.

Nyckelbegrepp: lösenordshanterare, lösenfras, unikt lösenord, tvåfaktorsautentisering (2FA, TOTP), passkey, brute force, begränsa inloggningsförsök, wp-login.php på IP-adress, xmlrpc.php, användarnamn som läcker ut (REST, ?author=), applikationslösenord

Lösenordet: långt och unikt

Ett bra lösenord har två egenskaper:

1. Långt: längd väger tyngre än udda tecken. En lösenfras på fyra eller fem slumpmässiga ord (zeef-pinguin-oktober-lantaarn) är starkare och lättare att komma ihåg än W8w00rd!. Den nederländska statliga kampanjen Veilig Internetten rekommenderar ett unikt lösenord på minst 12 tecken, helst en lösenordsfras.
2. Unikt: används ingen annanstans. Credential stuffing (lektion 7.1) fungerar bara om du återanvänder ett lösenord.

Ingen kommer ihåg tiotals långa unika lösenord. Använd därför en lösenordshanterare: ett program som skapar, sparar och fyller i dem åt dig. Då behöver du bara komma ihåg ett enda lösenord: det till hanteraren själv, och det skyddar du också med tvåfaktorsautentisering.

Om ett lösenord finns med i ett känt dataintrång kan du kontrollera på haveibeenpwned.com. Finns din e-postadress med i ett läckage, byt då lösenordet hos alla tjänster där du använde samma lösenord.

Tvåfaktorsautentisering

Med tvåfaktorsautentisering (2FA) behöver du förutom ditt lösenord ytterligare något vid inloggning: oftast en sexsiffrig kod från en app på din telefon (en autentiseringsapp, enligt standarden TOTP). En inkräktare med ditt lösenord kommer då ändå inte in.

WordPress har ingen inbyggd tvåfaktorsautentisering. Du lägger till det med ett tillägg. Det finns många; ett enkelt alternativ är Two Factor, skapat av bidragsgivare till WordPress själv. Även säkerhetstillägg har det ofta inbyggt. Tänk på följande när du väljer:

• TOTP-appar och reservkoder (för när du tappar bort telefonen); koder via e-post är svagare, eftersom din e-postbrevlåda också kan bli hackad;
• möjlighet att göra det obligatoriskt för administratörer och redaktörer;
• passkeys: logga in med fingeravtryck, ansikte eller en säkerhetsnyckel, utan lösenord. Det finns också tillägg för detta. Passkeys är motståndskraftiga mot phishing, eftersom de bara fungerar på den äkta webbplatsen.

Aktivera tvåfaktorsautentisering även på allt som finns runt din webbplats: din adminpanel för webbhotellet, din e-post, din registrator och din lösenordshanterare. En inkräktare som tar över din adminpanel behöver inte ditt WordPress-lösenord.

Brute force och begränsning av inloggningsförsök

En öppen WordPress-webbplats får inloggningsförsök på wp-login.php hela dagen, ofta med admin och listor med vanliga lösenord. Med ett långt lösenord och 2FA kommer de inte in, men varje försök kostar din server beräkningskraft (en fullständig WordPress-start). Vid en stor våg blir din webbplats långsam.

WordPress självt begränsar inte antalet försök. Vad som hjälper, i ordning efter "tidigast stopp":

1. På servern: många webbhotell blockerar en IP-adress som gör många misslyckade försök på kort tid, redan innan WordPress startar (med en brandvägg eller en webbserverfunktion). Fråga ditt webbhotell vad som händer.
2. wp-login.php endast för din IP-adress: med ett par rader i .htaccess (hos LiteSpeed och Apache):

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

Det fungerar bra om du har en fast IP-adress. Har du inte det (hemma, på telefonen), stänger du ute dig själv om adressen ändras. Ett alternativ är ett extra lösenord på inloggningssidan (en "skyddad mapp", basic authentication) med ett annat lösenord än ditt WordPress-lösenord.

3. Ett tillägg som begränsar försök: efter fem misslyckade försök blockeras IP-adressen en tid. Fungerar, men först efter att WordPress redan har startat, så beräkningsarbetet kvarstår.

Att dölja eller byta namn på inloggningssidan (till exempel /mijn-login i stället för /wp-login.php) minskar bruset i din logg. Det är inget riktigt säkerhetsskydd, och vissa tillägg och teman förväntar sig standardadressen. Bra som extra skydd, aldrig i stället för ett bra lösenord och 2FA.

xmlrpc.php

xmlrpc.php är en gammal koppling från tiden före REST API, som appar och andra webbplatser använder för att kommunicera med WordPress. Den används fortfarande av vissa appar, av Jetpack och av ett fåtal kopplingar. För de flesta webbplatser är den överflödig.

Inkräktare gillar xmlrpc.php, eftersom du i en enda förfrågan kan prova hundratals lösenord samtidigt (med funktionen system.multicall), och eftersom den kan missbrukas för attacker mot andra webbplatser (pingbacks). Vad du gör:

• Använder du den inte: blockera den. Vissa webbhotell, bland annat WebOké, blockerar xmlrpc.php som standard på servern. Annars med en rad i .htaccess eller med ett säkerhetstillägg.
• Använder du den (till exempel för en app som behöver det): låt den vara öppen, men se till att ha starka lösenord, 2FA och en begränsning av försök. Moderna appar använder oftast REST API med ett applikationslösenord (lektion 3.3).

Användarnamn som läcker ut

I lektion 3.3 såg du att WordPress visar en avledning av användarnamn:

• https://example.com/?author=1 omdirigerar till /author/<namn>/;
• https://example.com/wp-json/wp/v2/users visar en lista med slugs för alla som har publicerat något.

Är det allvarligt? Ett användarnamn är inget lösenord. Med ett långt unikt lösenord och 2FA spelar det liten roll. Men det ger en inkräktare hälften av inloggningsuppgifterna och gör riktad phishing lättare. Rimliga åtgärder:

• ge administratörer ett användarnamn som inte är deras publika namn, och publicera inte med ett administratörskonto (lektion 3.3);
• begränsa användarlistan i REST API med ett säkerhetstillägg eller några rader kod, om du inte behöver den. Stäng inte REST API helt: blockredigeraren och många tillägg behöver den.

Applikationslösenord

Applikationslösenord (lektion 3.3) är ett säkert sätt att ge en app eller ett system åtkomst, men de kringgår din tvåfaktorsautentisering: en app med ett applikationslösenord behöver ingen kod. Skapa dem bara vid behov, för ett konto med en låg roll, och återkalla dem när du inte längre använder kopplingen.

Sammanfattning

• Använd långa, unika lösenord (lösenfraser) i en lösenordshanterare.
• Aktivera tvåfaktorsautentisering, med ett tillägg i WordPress och även i din adminpanel för webbhotellet, e-post och hos din registrator.
• Stoppa inloggningsförsök så tidigt som möjligt: på servern, med en IP-regel eller extra lösenord, eller med ett tillägg.
• Blockera xmlrpc.php om du inte använder den.
• Läckta användarnamn är ingen katastrof, men en varningssignal: publicera inte som administratör och begränsa REST-användarlistan om du inte behöver den.

Quiz

Uppgift

Uppgift A7.3: Vad avslöjar din webbplats vid inloggning? Ange adressen till din webbplats och bevisa att det är din egen webbplats (med uppgiftens kod, som TXT-post eller som fil). Programmet kontrollerar tre saker: om xmlrpc.php returnerar en lista med funktioner (öppen) eller är blockerad, om /wp-json/wp/v2/users visar användarnamn (slugs), och vart /?author=1 omdirigerar. Ange om du behöver xmlrpc.php; om inte, är en öppen xmlrpc.php röd. Läckta slugs är orange med förklaring.

Uppgift D7.3: Aktivera tvåfaktorsautentisering. Aktivera tvåfaktorsautentisering för alla administratörer av din WordPress-webbplats, och även i din adminpanel för webbhotellet och din e-post. Spara reservkoderna i din lösenordshanterare. Bocka av för varje del att den är aktiverad och notera vilken metod du använder (app, passkey, e-post) och var reservkoderna finns. Notera också hur du extra skyddar wp-login.php och varför du valde det sättet.

Läs mer

Dessa artiklar beskriver stegen i WebOkés adminpaneler; i andra paneler fungerar det på liknande sätt.

• DirectAdmin-guide 3.7: Säkra lösenord och vad du gör vid ett läckt lösenord
• Ställ in tvåstegsverifiering i Mitt WebOké och en autentiseringsapp
• WordPress: åtkomst till xmlrpc.php fungerar inte
• Skydda wp-login.php i WordPress
• DirectAdmin-guide 15.9: Lösenordsskyddade kataloger
• Veilig inloggen (Veilig Internetten, nederländska staten): https://veiliginternetten.nl/veilig-inloggen/
• Brute force-attacker (developer.wordpress.org, engelska): https://developer.wordpress.org/advanced-administration/security/brute-force/