Visste du att de säkra webbtjänster som du loggar in på med ett lösenord faktiskt inte känner till det lösenord som du använder för att logga in med? Varför är det så? Och hur är det ens möjligt? Med kunskapen från vår artikel om Hash-funktioner och informationssäkerhet kan vi ge svar på dessa frågor.
En enkel inloggningsprocedur
Låt oss först titta på hur en enkel inloggningsprocedur skulle se ut. Vi loggar in på en webbtjänst på vanligt sätt med ett kontonamn och lösenord:
Vår enkla webbtjänst har en tabell i sin databas med alla kontonamn och tillhörande lösenord:
Webbtjänsten letar först upp kontonamnet från det ifyllda inloggningsformuläret i sin databas. Om namnet finns i databasen jämför tjänsten också lösenordet från inloggningsformuläret med det tillhörande lösenordet i databasen. Om lösenorden matchar varandra genomförs registreringen. I annat fall nekas registreringen. Vid första anblicken är detta ett säkert inloggningsförfarande. Endast den som har ett giltigt kontonamn och känner till det tillhörande lösenordet kan få tillgång till det aktuella kontot. Alla andra nekas tillträde. Så långt, så bra! Men vad är det egentligen som är så osofistikerat med det här förfarandet?
Problemet är att lösenorden lagras i en databas. Det innebär att de potentiellt är kända för alla som har tillgång till databasen, inklusive webbtjänstoperatörerna och deras anställda. Dessutom är det numera vanligt att många företag lägger ut den faktiska driften av de webbtjänster de erbjuder på amerikanska molntjänstleverantörer som Amazon Web Services eller Google Cloud. Därför kan vi anta att operatörerna och medarbetarna hos dessa molnleverantörer i princip också har tillgång till databasen och därmed till vårt lösenord. Dessutom kan brottslingar naturligtvis också få obehörig åtkomst till uppgifterna i databasen.
Dessutom är det ingen hemlighet att de flesta användare av webbtjänster återanvänder samma lösenord för flera tjänster. Den som har lyckats få tag på lösenordet för en målpersons Facebook/Twitter-konto eller onlineresebyrå kommer därför, med lite tur, också att ha lösenordet för dennes e-post, internetbank, personliga organisation, en dejtingplattform och intranätet för det företag där målpersonen arbetar. Det ekonomiska incitamentet att stjäla lösenord från databasen för vilken webbtjänst som helst är motsvarande högt, även om denna webbtjänst i sig inte är ett lukrativt mål! Frågan är: Hur löser vi detta problem?
En mer sofistikerad inloggningsprocedur
Låt oss komma ihåg följande: Webbtjänsten som beskrivs ovan har en tabell i sin databas med alla kontonamn och tillhörande lösenord:
Vi anpassar denna tabell på följande sätt. Istället för att lagra lösenorden använder vi en valfri kryptografisk hashfunktion för lösenorden:
Vad en kryptografisk hashfunktion är har beskrivits i artikeln Hashfunktioner och informationssäkerhet. Istället för lösenorden lagrar vi sedan de resulterande hashvärdena i databasen:
Detta ändrar inloggningsförfarandet endast något. Vi loggar fortfarande in på vanligt sätt med ett kontonamn och lösenord:
Webbtjänsten letar först upp kontonamnet från det ifyllda inloggningsformuläret i sin databas igen. Men i nästa steg skiljer sig den nya proceduren. Om namnet finns i databasen tillämpas hashfunktionen på lösenordet från inloggningsskärmen. Först därefter jämförs det resulterande hashvärdet med motsvarande hashvärde i databasen. Återigen jämförs inte lösenorden med varandra, utan endast med deras hashvärden. Om hashvärdena matchar varandra utförs inloggningen. I annat fall nekas inloggningen.
Förutom användningen av hashfunktionen har ingenting förändrats i inloggningsförfarandet. Av egenskaperna hos kryptografiska hashfunktioner följer att en jämförelse av hashvärdena är lika bra som en direkt jämförelse av lösenorden. Men nu lagras inte längre själva lösenorden i webbtjänstens databas. Den som får tillgång till databasen - behörig eller obehörig - har inte längre tillgång till lösenorden utan bara till deras hashvärden. Det ekonomiska incitament som beskrivs ovan för att stjäla lösenorden från en webbtjänsts databas elimineras därmed eftersom lösenorden nu inte längre finns i databasen.
Hur fungerar detta i praktiken?
Vi hoppas att vi har kunnat förklara bättre hur det är möjligt och varför det är vanligt att säkra webbtjänster inte ens känner till de lösenord som vi använder när vi loggar in. I praktiken ökar säkerheten i detta förfarande ytterligare genom att hashvärdena genereras med en specialiserad kryptografisk hashfunktion (bcrypt) och dessutom länkas till en databasomfattande hemlig teckensträng (salt) innan denna hashfunktion appliceras. Vi vill dock inte gå in på detta här.
Har du glömt ditt lösenord?
Om du har glömt ditt lösenord för en webbtjänst kan du begära en återställning av lösenordet från de flesta webbtjänster. Du får då ett e-postmeddelande med en länk som tar dig till ett formulär där du kan ange ett nytt lösenord. Vi vet nu varför detta hanteras så besvärligt: webbtjänsten känner inte till ditt gamla lösenord. Tyvärr följer inte alla företag denna etablerade säkerhetspraxis ännu. Om du via e-post eller i ett telefonsamtal med ett supportteam anger att du har glömt ditt lösenord och sedan faktiskt får veta ditt lösenord, kan du dra slutsatsen att detta företag inte följer moderna standarder för informationssäkerhet. Senast då bör du definitivt se till att du inte använder detta lösenord i något annat sammanhang. För att konsekvent använda ett separat lösenord för varje webbtjänst bör du använda en lösenordshanterare. Då behöver du inte längre komma ihåg massor av individuella lösenord och har den extra bonusen att kunna skapa slumpmässiga lösenord av hög kvalitet istället. Det finns plug-ins för populära lösenordshanterare som till och med fyller i inloggningsskärmarna för dina webbtjänster åt dig. Sällan möts bekvämlighet och säkerhet så vackert.
