Netsundhedsplejerske.dk: Datalæk afslører e-mailadresser og passwords i klartekst

Ansvaret bør vel ligge hos dem, som har udviklet siden (antaget at den er udviklet af en ekstern partner).

Jeg har lige haft en elektriker til at skifte min sikringstavle. Jeg forventer at han har styr på det, for jeg har ingen mulighed for at kontrollerer det. På samme måde, kan vi ikke forvente at alle som har købt en hjemmeside, er eksperter indenfor IT-sikkerhed. Men man burde kunne forvente, at dem som laver den, som minimum har styr på det basale.

Netsundhedsplejersken.dk er bare en hjemmeside ud af mange med ingen sikkerhed, hvor et tyndt sikkerhedsglimmer er lagt over. De gør noget nyttigt for os, dog er de ofte sat op af nogle der typisk ikke ved bedre. Det er på tide at man stiller krav til hjemmesiderne og en mærkning som glad eller sur hængelås.

Derudover så bør man idag helst anvende blowfish

Ifølge OWASP er bcrypt (blowfish-ish) ikke længere den anbefalede cipher til at opbevare adgangskoder. Nu hedder det Argon2 :)

Heini Hansen?

Nej jeg eferlyser ikke et svar, det er mere for at løfte diskussionen om os som brugere af en website og vores forventninger til at dem der står for sitet er 100 pct proffessionelle, uden at vi har en mulighed for at tjekke dette.

Så mistro mistro mistro :)

Gem aldrig løsen

Amen.

Og må jeg i den forbindelse lige nævne SRP. Her kender serveren på intet tidspunkt passwordet, for klienten fører i stedet et zero-knowledge proof for at han kender det.

I praksis kan man stadig forsøge sig med bruteforce af de "verifiers", som serveren har, og det koger i bund og grund ned til, at gætte hvordan klienten har hashed sit password.

Protokollen har også nogle andre gode egenskaber.

Dette er stadigvæk et utroligt dårligt design. Gem aldrig løsen, om det så er krypteret eller ej. Hvis en bruger gemmer sit løsen, så håndteres det ved at generere et nyt. Det er ikke specielt svært at opsnappe en email, og du stoler endvidere også på at dine supporterer ikke bare løber med alle dine kunders løsener, som de sikkert også har brugt andre steder (det er selvfølgelig en dårlig idé, men det sker meget i praksis).

"Hændelsen har ikke medført læk af følsomme persondata. Spørgsmål-svar korrespondancen med brugerne gemmes på hjemmesiden, og de er dermed tilgængelige. Men der er ikke tale om følsomme persondata, understreger netsundhedsplejerske.dk"

Hvor ved man det fra - at der ikke er noget læk af følsomme oplysninger? Jeg kender ikke siden, og den er vel nu ændret. Men på hjemmesiden er det vel sandsynligt, at spørgsmålene har været anonyme - og at spørgerne subjektivt kan opleve det som endog særdeles følsomt, hvad de har spurgt om? Har man en log, som viser, om spørgsmålenes oprindelse er tilgået uretmæssigt?

Der er mange måder at gemme password i en database i krypteret form, men som man kan dekryptere hvis nødvendigt

Det er aldrig nødvendigt at dekryptere et password. Hvis man har behov for at logge ind som en bruger så skal det laves så systemet tror at man er den bruger og ikke give mulighed for at give password.

Det ældgamle argument om at det er nemmere at supportere kunderne når man har adgang til deres password holder ikke. Der er mange måder at gemme password i en database i krypteret form, men som man kan dekryptere hvis nødvendigt.

For to år siden lavede jeg en lille applikation som arbejdede med et AES-krypteret password. Når supporteren skulle se det blev han bedt om at indtaste dagens password, der så dekrypterede passwordet til skærm. Alle kundepassword lå både som hash (til login) og AES-krypteret. Hver nat blev disse AES-krypterede passwords rekrypteret med et nyt password som blev sendt til supporterne.

For at kompromitere disse AES-krypterede passwords skulle man både have soucekode (for at se hvordan krypteringen foregår), de AES-krypterede passwords og dagens password.

Mailen til supporterne indeholdt i øvrigt ikke selve dagens password men et link til en side med uforudsigelig URL hvor det fremgik. Gamle password sider slettes (overskrives og slettes) også hver nat.

På det omtalte web site logger man ind med brugernavn og password uden https beskyttelse

Så er niveauet lagt.

Skal det forståes som at salt-delen ikke gemmes sammen med den hashede værdi?

Derudover så bør man idag helst anvende blowfish ( se https://www.techrepublic.com/blog/australian-technology/securing-passwords-with-blowfish/ ) - da den har en "cost" indstilling.. så man løbende kan opjustere hvad det koster at bruteforce et kodeord.

Han vil ikke kommentere på, om de nye kodeord fortsat ligger som klartekst.

Med andre ord, kodeordene ligger stadig i klartekst...

Skal det forståes som at salt-delen ikke gemmes sammen med den hashede værdi? Og I så fald, hvor gemmer man så salten?

Et gæt? Global Salt? (Samme Salt for alle)?

Ikke at det vil være i nærheden af lige så godt som at gøre det 'rigtigt'...

indenfor meget kort tid, er blevet forbedret betydeligt

Kan ejerne af hjemmesider med login ikke gøres ansvarlige? Password hashing har været i brug siden 1978, altså for 40 år siden.

Det slags inkompetence burde være strafbar.

Hændelsen har ikke medført læk af følsomme persondata

Måske ikke, men personhenførbare data er der tale om, så GDPR vil rammer Netsundhedsplejerske.dk

indenfor meget kort tid, er blevet forbedret betydeligt

Hvordan kan det være at nogen bare vil forsøge at får en positiv vinkel på sådan en historie, erkend dog at man har fucket up big time.

Nej det havde Netsundhedsplejerske.dk ikke, for så ville de ikke kunne sige:

Hændelsen har ikke medført læk af følsomme persondata

Er der nogen, som kan uddybe følgende:

Center for Cybersikkerhed anbefaler, at passwords bliver hashed med en password-hashfunktion,
at der anvendes salt, og at det kun er den hashede værdi, der bliver gemt i databasen.

Skal det forståes som at salt-delen ikke gemmes sammen med den hashede værdi? Og I så fald, hvor gemmer man så salten? Jeg har altid læst at det skulle gemmes som et par, således :<hash-værdi>.