Mange bedrifter har nylig erkjent at de lagrer passord i klartekstformat. Dette kan sammenlignes med å lagre et passord i Notisblokk og deretter lagre filen som en .txt-fil. For å sikre god sikkerhet bør passord krypteres ved hjelp av salting og hashing. Spørsmålet er derfor: hvorfor skjer ikke dette i 2019?
Hvorfor lagring av passord i ren tekst er en risikosport
Dersom et firma lagrer passord i ren tekst, vil alle som får tilgang til passorddatabasen, eller andre filer som inneholder passordene, kunne lese dem. En hacker som bryter seg inn i en slik fil, vil ha direkte tilgang til alle passord.
Lagring av passord i ren tekst er en særdeles uheldig praksis. Selskaper bør benytte salting og hashing av passord. Dette innebærer å tilføye ekstra data til passordet og deretter kryptere det på en måte som ikke er reversibel. Dette betyr i praksis at selv om noen skulle stjele passord fra en database, vil disse være ubrukelige. Ved innlogging kan selskapet kontrollere at passordet stemmer overens med den lagrede, krypterte versjonen. Selskapet kan imidlertid ikke «jobbe seg bakover» fra databasen og finne ut det faktiske passordet.
Hvorfor velger da noen bedrifter å lagre passord i klartekst? Dessverre er det tilfeller hvor sikkerhet ikke tas seriøst. Andre ganger velges det å ofre sikkerhet for enkelhets skyld. Det hender også at bedrifter i utgangspunktet lagrer passord på korrekt måte, men så innføres overivrig loggingsfunksjonalitet som registrerer passord i ren tekst.
Flere selskaper har feilaktig lagret passord
Det er ikke usannsynlig at du allerede er berørt av denne dårlige praksisen. Selskaper som Robin Hood, Google, Facebook, GitHub, Twitter og flere andre har lagret passord i ren tekst.
Google brukte i utgangspunktet tilstrekkelig hashing og salting for de fleste brukerpassord. Likevel ble passord for G Suite Enterprise-kontoer lagret i ren tekst. Selskapet forklarte at dette skyldtes eldre praksis fra den tiden da domeneadministratorer fikk verktøy for passordgjenoppretting. Dersom Google hadde lagret passordene korrekt, ville ikke dette vært mulig. En funksjon for tilbakestilling av passord er eneste mulighet for gjenoppretting ved korrekt lagring.
Facebook erkjente også å ha lagret passord i ren tekst, men oppga ikke den eksakte årsaken til problemet. En senere oppdatering gir imidlertid en indikasjon på hva som kan ha skjedd:
«Vi oppdaget flere logger med Instagram-passord som ble lagret i et lesbart format.»
I enkelte tilfeller gjør selskapet alt riktig ved første lagring av passordet, for så å legge til nye funksjoner som skaper problemer. I tillegg til Facebook, har også Robin Hood, Github, og Twitter ved et uhell logget passord i ren tekst.
Logging er nyttig for å spore opp problemer i apper, maskinvare og systemkode. Dersom logging ikke testes grundig, kan det skape flere problemer enn det løser.
Både Facebook og Robinhood har opplevd at når brukere tastet inn brukernavn og passord for å logge seg på, kunne loggingsfunksjonen se og registrere både brukernavn og passord. Denne informasjonen ble så lagret et annet sted. Dermed kunne alle med tilgang til loggene overta en konto.
I sjeldne tilfeller ser man at selskaper, som T-Mobile Australia, ignorerer sikkerhet til fordel for enkelhet. I en Twitter-diskusjon som senere ble slettet, forklarte en representant for T-Mobile at selskapet lagret passord i ren tekst. Dette ble gjort for at kundeservicemedarbeidere skulle kunne se de fire første bokstavene i et passord for bekreftelsesformål. Andre Twitter-brukere påpekte raskt hvor risikabelt dette var.