Vad kan man lära sig av #sdgate?

När det första lugnet efter #sdgate-stormen börjar infinna sig i olika medier så finns det ett par saker man kan lära sig:

  • Lösenordssäkerhet. Lösenordssäkerhet. Lösenordssäkerhet.
    Att vara försiktig med sitt lösenord är något som många kanske tänker att de borde vara, men inte efterlever i praktiken. I det här fallet så är det två uppenbara saker som orsakat problem.

    Först och främst är det ett stort problem att folk använder samma lösenord på flera olika tjänster. Bloggtoppen hackades, och i samband med det spreds lösenorden. De som då har haft samma lösenord på sitt Bloggtoppen-konto som på t.ex. Twitter, sin e-post eller sin blogg kan redan ha fått sina andra konton hackade, utan att de vet om det. Det lutar ju mot att det var så de tog sig in på Petzälls konto, för att han använde samma lösenord där, som på sitt Twitter- eller e-postkonto.

    Man borde VERKLIGEN ha olika lösenord på olika tjänster, eller i alla fall se till att man har unika och säkra lösenord på de viktigaste kontona (främst e-posten då det kan användas för att ta över andra konton). Det finns flera olika lösningar som kan hjälpa användaren att ha säkra lösenord, och personligen så gillar jag programmet KeePass som finns för ”alla” operativsystem och mobiltelefoner.

    MEN, det är inte bara användarna som behöver tänka på lösenordssäkerhet, utan även utvecklare och webbtjänster måste ta det seriöst. När man utvecklar en tjänst där användarna ska kunna logga in måste man kunna autenticera dem på något sätt. Antingen använder man en tredjepartstjänst (t.ex. att man loggar in via sitt Google- eller Facebook-konto), eller att användaren får ett eget konto och lösenord tjänsten. Om man får ett eget konto på webbplatsen, så måste de spara användarnamn och lösenord i någon form. I värsta fall sparas de direkt i klartext, vilket gör att sajtägaren eller någon hackare kan se lösenorden på gång.

    Man kan även välja att spara lösenorden antingen krypterade, eller, något som är ännu säkrare, hashade. Då sparas istället för själva lösenordet, en checksumma av lösenordet. Hos Bloggtoppen sparades lösenorden med ett MD5-hash. Problemet med det är att med just MD5 så går det rätt snabbt att räkna ut vilket lösenord det är baserat på checksumman, och att det går att få ännu bättre säkerhet genom att använda ett så kallat ”salt”. Mer information om hash och salt finns på wikipedia. Istället för bara MD5, så kan man spara lösenordet hashat med ett salt, eller en säkrare algoritm, såsom Bcrypt.

  • Säkerhet vid utveckling
    Utöver problemet med att spara lösenord ”rätt”, så är det också viktigt att man ”programmerar säkert” för att minska risken att bli hackad. Bloggtoppen hackades via en så kallad SQL-injektion, vilket innebär att hackaren kan påverka det som skickas till databasen där allting sparas. På så sätt kan man hämta ut information om exempelvis lösenord, eller t.ex. skapa nya inlägg på en blogg, utan behörighet.

    Vid utveckling av webbtjänster finns det en sak som är viktigare än allting annat. Kontroll av input! Man måste kontrollera att man får in värden som man förväntar sig. Om du t.ex. har ett fält för ålder, finns det ingen anledning att någon ska skicka annat än siffror, så då ska allting annat än siffror blockeras på serversidan.

Som användare kan man inte alltid lita på att webbplatser man skapar konton på är säkra, men det minsta man kan göra, är att undvika att ha samma lösenord på olika webbtjänster. Det är kritiskt viktigt, något som snabbt visas i fall som dessa.

Det är långt från första eller sista gången som en webbplats hackas, och det är ofta bara en bråkdel av gångerna som sajtägaren vet om det, eller som användarna i sin tur får veta om att deras kontouppgifter kan ha spridits. Enligt uppgift så verkar säkerhetshålet på Bloggtoppen ha varit känt i flera månader. Om någon av de över 90.000 användare som hade konto där, hade samma (eller liknande) lösenord på sin e-post, sin Facebook eller sin Twitter, borde man faktiskt räkna med att någon okänd redan har loggat in där, och gått igenom allting. När sådana listor sprids publikt så brukar det inte ta lång tid innan alla konton testats, även om det är tiotusentals användare.

Missa inget!

Prenumerera på Säkerhetsbloggen via e-post!

Comments: 2

Your email address will not be published.

  • Christopher, Permalink

    Jag vet inte om mig fråga är rätt att ställe här men jag gör det ändå
    Bitdefender labs har just släppt det verktyget som heter USBImmunizer
    har eset tänk att släppa något liknade för deras konsumenter?

    på tal om det så ska jag utvärdera ESET NOD32 – Bästa antivirusprogram för spelande och spelare är som sagt en inbiten gamer och gillar att testa nya spel men antivirus program brukar tyvärr bråka ibland med vissa spel

    • Anders Nilsson, Permalink

      Hej!

      Vi har inga planer på att släppa något liknande verktyg. Det den gör är att den försöker förhindra skadlig kod från att skapa en ”autorun.inf”-fil. I många fall går detta att göra enkelt manuellt också (t.ex. genom att skapa en mapp som heter ”autorun.inf” så borde den mesta skadliga koden misslyckas med att ta bort den för att sätta sig själv att starta automatiskt). Det viktigaste dock är att söka igenom USB-minnet igen när du är vid en dator som har ett uppdaterat antivirusprogram installerat. Även om autostart-funktionerna inte fungerar så kan den ju fortfarande ha infekterat befintliga filer på USB-minnet.

      Hoppas du kommer gilla programmet när du utvärderar det! Hör gärna av dig och berätta hur det gått!

      /Anders