Version2 og Mediehuset Ingeniøren udsat for hackerangreb

Brugerdata kan være blevet lækket fra Version2 Job som følge af et hackerangreb rettet mod Version2 og de øvrige af Mediehuset Ingeniørens hjemmesider. Alle brugere bør for en sikkerheds skyld ændre deres kodeord.

En sårbarhed har ramt det udbredte CMS, Drupal, der anvendes på et hav af hjemmesider verden over. Sårbarheden, der nu er lukket, har blandt andet betydet, at hackere har kunnet tilgå brugerinformationer på berørte hjemmesider.

Mediehuset Ingeniøren, som Version2 er del af, anvender netop Drupal, og er som følge af sårbarheden blevet udsat for et hackerangreb på flere af de hjemmesider, som mediehuset står bag.

Det drejer sig om Ingeniørens hjemmeside ing.dk, it-mediet Version2's hjemmeside version2.dk, konferencesitet jobtraef.dk og rekrutteringsbuearets Capax' hjemmeside capax.dk.

Sårbarheden er blevet udnyttet til at oprette brugere med administrator-adgang på hjemmesiderne. Det konkrete angreb er foregået via en såkaldt SQL-injection-sårbarhed. Det vil sige, at hackeren har kunnet køre SQL-forespørgsler i de bagvedliggende databaser.

I forbindelse med angrebet har hackeren haft adgang til de brugeroplysninger, der er knyttet til de forskellige sites. Det vil typisk sige brugernavn og mail. Passwords har været opbevaret kryptereret.

Teknisk har brugerpasswords været kørt gennem en SHA-512-algoritme, som har været ‘salted’ med en tilfældig værdi. Det er normalt en af de mest sikre og anerkendte metoder til sikring af kodeord, fortæller digital udviklingschef og driftsansvarlig i Mediehuset Ingeniøren Jesper Bille Haun.

Skift password for en sikkerheds skyld

For en sikkerheds skyld opfordrer han dog alle brugere med profiler på ing.dk og version2.dk til at skifte kodeord - og kodeord på andre sites, hvor de samme login-oplysninger er anvendt.

»Når et site har været kompromitteret, bør man altid skifte kodeord på de ramte hjemmesider og andre steder, hvor samme login-oplysninger må være anvendt. Der findes metoder, der kan knække den sikkerhed, der ligger i password-krypteringen, hvis der har været brugt forholdsvis simple kodeord,« siger Jesper Bille Haun.

Brugere er der har oprettet profiler via Facebook har i udgangspunktet ikke fået kompromitteret deres oplysninger.

Udover oplysninger om brugere oprettet på de forskellige Drupal-hjemmesider, så har hackeren via Version2 i princippet også haft adgang til oplysninger på Version2's Job-side.

»Hackeren kan også have hentet informationer om de profiler, der er oprettet på Version2 Job. Det er oplysninger som arbejdserfaring, uddannelse og den slags. Vi ved ikke, om disse oplysninger faktisk er blevet tilgået,« siger Jesper Bille Haun.

Sikkerhedshullet i Drupal er patched og dermed lukket med version 7.32 af cms'et. Tidligere versioner af Drupal core 7 formodes er ramt af sårbarheden. Drupals sikkerhedshold sendte en meddelelse ud om sårbarheden, som blev beskrevet som yderst kritisk i onsdag i sidste uge, 15. oktober, omkring klokken 18 dansk tid.

Mediehuset Ingeniørens servere blev øjensynligt angrebet natten til torsdag 16. oktober cirka syv timer senere.

Oprettede bagdør

Efter at have brugt sikkerhedshullet til at oprette administratorbrugere på de forskellige sites, har hackeren oprettet sin egen bagdør på Version2's hjemmeside. Herefter har hackeren lukket sikkerhedshullet på hjemmesiderne, så den kendte SQL-sårbarhed ikke har kunnet anvendes af andre.

Bagdøren på Version2 har gjort det muligt for hackeren at afvikle blandt andet php-kode via specifikke og skjulte url-adresser.

Den ondsindede kode og hackerens adgang skulle nu være ryddet helt af vejen.

»Vi vil forsøge at undgå lignende angreb ved minutiøst at gennemgå og evaluere vores beredskab og om nødvendigt tage yderligere skridt for at sikre data,« siger Jesper Bille Haun.

Den uafhængige new zealandske ekspert Bevan Rudge anslår, at 100.000-vis af sites har været ramt verden over af sikkerhedshullet og nu har fået installeret bagdøre i hackersagen, der har fået navnet Drupageddon.

»Der er i øjeblikket mange danske sites hos store og kendte virksomheder, der stadig kører ældre versioner af Drupal. De kan naturligvis være patchet af anden vej, men det er ikke sikkert, at Drupageddon er slut endnu,« siger Jesper Bille Haun, som opfordrer til større åbenhed blandt de ramte virksomheder for bedre i fællesskab at bekæmpe uvæsenet.

Følg forløbet

Kommentarer (57)

Jesper Louis Andersen

Teknisk har brugerpasswords været kørt gennem en SHA-512-algoritme, som har været ‘salted’ med en tilfældig værdi. Det er normalt en af de mest sikre og anerkendte metoder til sikring af kodeord, fortæller digital udviklingschef og driftsansvarlig i Mediehuset Ingeniøren Jesper Bille Haun.

Dette er faktuelt forkert. Den bedste metode til at sikre et password er at benytte en Key Derivation Function, eller et KDF. Der findes et antal af disse: PBKDF2, bcrypt og scrypt er de mest kendte. Men også PHKs MD5-baserede KDF bør nævnes, om end det er af lidt ældre dato.

Problemet med SHA-512+salt er at SHA-512 er designet til at være "hurtig" i den forstand at du hurtigt skal kunne lave kryptografiske checksums af store mængder data. Derfor er de designet til at kunne processere data så hurtigt som muligt, hvor antallet af klokcycles per byte er optimeret så meget som muligt. Naturligvis således at der stadig er en sikkerhedsmargin i forhold til de krav der stilles til en kryptografisk checksum.

Når du gemmer brugeres kodeord, så ønsker du det modsatte. Du vil gerne have at der skal laves forholdsvist meget arbejde pr. login for at gøre det sværere at bryde kodeordet. Derfor skal der som minimum køres mange runder af SHA-512, men bedre er det at benytte en funktion der er decideret designet til at være dyr i beregning.

En KDF kan typisk justeres så du kan checke omkring 10 passwords per sekund på en moderne maskine. Til sammenligning kan jeg checke tusinder af SHA-512+salt words.

Jan Wiberg

I burde nok invalidere alle passwords, eller som minimum informere folk per mail (hvis ikke allerede gjort selvf.). Det er ikke sikkert at jeres brugere når at se denne artikel.

Ove Andersen

Det var også på tide at få skiftet password alligevel :)

Har I nogen ide om, hvilken kode der er blevet indsat på Jeres sider, og hvilke eksterne man ubevist har besøgt (og hvor meget skod-ware man er blevet udsat for)?

Rasmus Rask

"Bagdøren på Version2 har gjort det muligt for hackeren at afvikle blandt andet php-kode via specifikke og skjulte url-adresser."

På de besøgende og deres klik rundt på sitet?

Jesper Haun Digital Development

Jesper Louis Andersen og Peter Mogensen: Jeg er ikke krypteringsekspert, så her må jeg lytte til vore konsulenter på opgaven, der fortæller, at SHA-512 er anbefalet metode til netop det.

Casper Olsen: Jo, det er samme fejl. Hackeren var bare hurtigere end os.

Jan Wiberg: Du har helt ret. Vi arbejder på en løsning.

Adam Tulinius: Der gik ikke 10 dage, men vi ville være sikre på, at vi havde situationen under kontrol, før vi gik ud med historien.

Ove Andersen: Hackeren har placeret en PHP-fil i en mappe, der normalt bruges til billeder, som han kunne komme tilbage til og afvikle kode i. Det er naturligvis fjernet. Brugere er ikke blevet dirigeret til andet indhold.

Hilsen
Jesper Bille Haun
Mediehuset Ingeniøren A/S

Peter Mogensen

Jeg er ikke krypteringsekspert, så her må jeg lytte til vore konsulenter på opgaven, der fortæller, at SHA-512 er anbefalet metode til netop det.

Det var sådan set ikke fordi jeg havde anden pointe end at fortælle Jesper Louis at hans argument ikke nødvendigvis var relevant (med den liden info artiklen gav).

Men ... hvis dine "krypteringseksperter" virkelig mener at SHA-512 i sig selv er nok og ikke bare forsimpler sagen for dig, så vil jeg godt tilslutte mig Jesper Louis' argument og betvivle om de faktisk også er "krypteringseksperter".

Søren Fuglede Jørgensen

Disclaimer: Jeg er heller ikke "krypteringsekspert", men hvis jeg skriver noget ævl, kan jeg heldigvis bare hævde, at min version2-konto er blevet hacket.

Brug en KDF!


Hvis man skal være lidt pernitten er en KDF jo i bund og grund bare en funktion, der æder et argument (i det her tilfælde den rigtige kode) og spytter en kryptografisk stærk nøgle ud. Alt efter hvor meget man lægger i ordet "stærk", kan man jo sagtens argumentere for, at SHA-256 gør præcis det. Derudover vil den nok typisk afhænge af flere øvrige argumeter, men der kan vi jo bare kræve, at den er konstant i dem.

Din (ganske rigtige) pointe er, at det væsentligste i den her forbindelse er, at enhver implementering af funktionen vil være langsom, men det er ikke en antagelse om generelle KDF'er og i nogle anvendelser decideret uhensigtsmæssigt. Derfor skelner man mellem KDF'er og passwordbaserede KDF'er (PBKDF'er), hvor sidstnævnte kræves at være langsomme og at afhænge (ikke-trivielt?) af et salt (og omvendt vil nøglematerialet i en generel KDF selv være tilfældigt, i en passende forstand, mens det typisk ikke er tilfældet for brugeres kodeord). Afsnit 9 i ham her snakker lidt om den skelnen.

Det sagt er konklusionen nu rigtig nok: Forhåbentlig har Jesper Hauns eksperter fundet frem til at bruge noget "i stil med" PBKDF2 eller lignende.

Thue Kristensen

Men ... hvis dine "krypteringseksperter" virkelig mener at SHA-512 i sig selv er nok og ikke bare forsimpler sagen for dig, så vil jeg godt tilslutte mig Jesper Louis' argument og betvivle om de faktisk også er "krypteringseksperter".

Jeg ved heller ikke om jeg er krypteringseksper, men vil også gerne tilslutte mig esper Louis' argument.

Hvis man forstår hvordan john the ripper virker (hvilket ikke er så indviklet), så er det klart at ren SHA-512 ikke er godt nok.

Jesper Louis Andersen

Nu fremgår det jo ikke helt tydeligt af artiklen om der bare var tale om SHA-512, eller om den SHA-512-baserede KDF "$6$" ... som i øvrigt minder meget om PHKs MD5 ("$1$") som du (næsten) anbefaler.

Naturligvis kan du godt stretche en SHA-512 på samme måde som PHKs MD5, og det giver samme sikkerhed. Det jeg er lidt imod er at man bare, relativt blindt, skriver SHA-512+salt hvilket netop ikke vil være specielt sikkert. Desværre leder den slags udtalelser til implementeringer der ikke er sikre overfor indtrængen, fordi folk hører at "sådan skal man gøre". Den konkrete implementation kan jo godt vælge at køre flere runder og stretche sit materiale. Men det er ikke helt trivielt, så hvis du ikke ved bedre, så skal du holde dig fra at være "smart" og bruge noget der er standard.

Og Søren Fuglede har helt ret i at jeg skød for hurtigt når det gælder KDF'er generelt, og at der er forskel på at aflede en nøgle og gemme hashede passwords. Det beklager jeg. Du kan godt, med lidt god vilje, udnytte PBKDF2 til det, men jeg vil helt klart foretrække enten bcrypt eller scrypt til formålet, for de er designet til det.

Jesper Lund

Jesper Louis Andersen og Peter Mogensen: Jeg er ikke krypteringsekspert, så her må jeg lytte til vore konsulenter på opgaven, der fortæller, at SHA-512 er anbefalet metode til netop det.

Beklager at det er lidt OT og thread-hijacking, men nu vi er ved password sikkerheden og har Version2 administratorerne i tale, kunne det være rart at få HTTPS på version2.dk og ing.dk, så vi ikke sender passwords i cleartext.

Jeg ved at version2.dk og ing.dk kører på samme server (IP adresse), men der er noget som hedder SNI, og efterhånden må de sidste klienter uden SNI understøttelse være gået bort, for eksempel Internet Explorer på Windows XP.

Thue Kristensen

Jeg ved at version2.dk og ing.dk kører på samme server (IP adresse), men der er noget som hedder SNI, og efterhånden må de sidste klienter uden SNI understøttelse være gået bort, for eksempel Internet Explorer på Windows XP.

Om ikke andet så kunne man jo bare tilknytte endnu en IP-adresse til serveren, og så servere siderne fra hver sin IP.

Men ja, jeg synes ikke at version2 bør holde sig tilbage fra SNI for at kunne understøtte IE8 på Windows XP...

Kim Bjørn Tiedemann Blogger

Problemet med SHA-512+salt er at SHA-512 er designet til at være "hurtig" i den forstand at du hurtigt skal kunne lave kryptografiske checksums af store mængder data. Derfor er de designet til at kunne processere data så hurtigt som muligt, hvor antallet af klokcycles per byte er optimeret så meget som muligt. Naturligvis således at der stadig er en sikkerhedsmargin i forhold til de krav der stilles til en kryptografisk checksum.

Jeg er fuldstændig enig i at KDF er vejen frem, men version2 og ing.dk indeholder ikke følsomme oplysninger og dermed kan man sagtens argumentere for, at SHA512+salt er rigeligt. Det er i praksis umuligt at brute-force SHA512+salt, såfremt brugerne har valgt et tilfældigt adgangskode af en vis længde (12+). Sikkerheden afhænger derfor af styrken på brugerens adgangskode og derfor vil nogle brugeres adgangskoder kunne "crackes", men det kræver en heftig indsats.

Kim Bjørn Tiedemann Blogger

Der manglede lige lidt:

Det overordnede problem er, at folk ikke bruger stærke adgangskoder samt at de genbruger adgangskoder på tværs af sites og derfor hvis de lækkes på et site, så kan de bruges på andre sites. Det er selvfølgelig et problem, og derfor bør vi bruge KDF som mindsker risikoen for at et password kan "crackes". Men sikkerheden her er begrænset af det svageste led og såfremt folk fortsat genbruger adgangskoder så er der masser af systemer derude med dårlig password implementering. Her har vi set klar-tekst, MD5 hash, MD5 hash med salt, kryptering med en asymmetrisk nøgle helt op til KDF implementeringer.

Thue Kristensen

men version2 og ing.dk indeholder ikke følsomme oplysninger og dermed kan man sagtens argumentere for, at SHA512+salt er rigeligt. Det er i praksis umuligt at brute-force SHA512+salt, såfremt brugerne har valgt et tilfældigt adgangskode af en vis længde (12+).

Jeg skal selv indrømme at mit Version2-password ikke er vanvittigt stærk, netop fordi jeg hellere vil kunne huske det. Mit email-password er langt mere sikkerheds-kritisk, og derfor valgt stærkere.

Men der er stadig ikke nogen grund til at vælge SHA512+salt i stedet for en KDF. Det er jo gratis at vælge den rigtige løsning.

Kim Bjørn Tiedemann Blogger

Men der er stadig ikke nogen grund til at vælge SHA512+salt i stedet for en KDF. Det er jo gratis at vælge den rigtige løsning.

Desværre er det ikke helt gratis. Rigtigt mange vælger netop standardløsninger, som Drupal, SharePoint, CRM og lignende og her er man ofte underlagt det underliggende produkts password implementering. Op til for ganske nyligt var det normalt, at en .NET web applikation ud af boksen benyttede SHA-1+salt. I den seneste version er det skiftet ud med PBKDF2 implementering (http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc...) der benytter SHA1.

Fremdrettet skal vi bruge KDF - det er der ingen tvivl om. Men KDF redder os ikke, hvis brugerne bruger svage adgangskoder eller genbruger på tværs af sites.

Ps. faktisk ser det ud til at Drupal ud af boksen bruger SHA512+salt med et vist antal iterationer: http://joncave.co.uk/2011/01/password-storage-in-drupal-and-wordpress/

Tine Andersen

Hvad kan mit password til v2 og ing (det er to forskellige!)- så rent faktisk bruges til?
Ja, man kan udgive sig for at være ego, og dermed skrive i de to sites debatfora, men ellers kan jeg nu ikke se, at skaden er ret stor.

Surt show, som man siger.

Mvh
Tine- aka Gnavensmølf: Jeg kan ikke fordrage passwords...

Jakob Bruun Hansen

Dit password kan først og fremmest bruges til at logge ind på andre konti, hvor du har brugt det samme password. Mest oplagt, hvis du bruger det til den mailadresse, som din konto er registreret med. Der er mange der genbruger password på tværs af sites, ikke mist fordi der har været så stor fokus på at vælge sikrere passwords, som er svære at huske. Dem der gør det har en tillid til, at sites indehaver passer godt på passwordet. Derfor er det vigtigt at have en stærk passwordkryptering, også selvom man ikke mener man har noget vigtigt. Passwordet er vigtigt.

Kim Bjørn Tiedemann Blogger

Jeg bruger LastPass som er en online adgangskode løsning. Til hvert site genererer jeg en ny adgangskode og er dermed sikker på at: 1. Password har høj entropi og 2. Der er ikke genbrug af password på tværs af sites. Løsningen integrerer med de forskellige browsere og mobil OS, så det er super simpelt.

Jeg mener faktisk at det er mere alvorligt at version2 ikke benytter https ved login og efterfølgende sætter en secure cookie end at password måske har været gemt med SHA512+salt. Et svagt password bliver ikke stærkt ved at tilføje KDF - det vil stadig være nemt at brute-force, hvis man bruger et password som 123456 eller qwerty.

Bo Ørsted Meyer Zachariasen

Men sikkerheden her er begrænset af det svageste led og såfremt folk fortsat genbruger adgangskoder så er der masser af systemer derude med dårlig password implementering.

Det kunne man oplyse om der hvor password indtastes og stille minimumskarv ved oprettelse og ændring af password.

Jeg bruger LastPass og har derfor auto genereret ”tilfældige” lange og forskellige password.
LastPass kan lave et sikkerhedstjek hvor alle password kvalitetsvurderes og genbrugte markeres.

KeePass er også god og er nr. 2 på listen over alternativer efter LastPass: [http://alternativeto.net/software/lastpass/]

Lars Bjerregaard

Først og fremmest, tak for at i overhovedet siger noget. At blive offer for en ny sårbarhed er ærlig snak, så det vil jeg ikke give jer på puklen for. Men herefter VIL i få på punklen af undertegnede, for jeres stadig farlige håndtering af logins og passwords, både på V2 og Ing.dk, for det holder fandeme ikke....

1) Har i hørt om den der ting der hedder HTTPS? Det er sådan en ting der BESKYTTER vores credentials. På v2 og ing.dk er det ikke muligt at bruge https. Alle vores brugernavne og passwords bliver sendt i klartekst over netværket, selv på de sider hvor man logger ind, og ændrer eller indtaster passwords. FAIL #1

2) Jeres password-reset mekanisme fungerer ikke. Når man har klikket på knappen for at resette password, får man tilsendt en email hvor der står at ens password er nulstillet, og at man skal klikke på et engangs-link for at indtaste et nyt (uden https naturligvis). DETTE FUNGERER IKKE! Jo, man kommer til v2 forsiden, hvor der står at man nu er logget ind med sit brugernavn, og skal klikke på "dette link" for at skifte sit password. Men "dette link" fører bare til den normale brugerprofil side, hvor man skal indtaste sit GAMLE password, for at kunne lave et nyt. Altså kan man ikke glemme sit password på v2 og ing.dk da man SKAL bruge det for at lave et nyt. FAIL #2.

3) Og for at det ikke skal være løgn, så er ens password, efter at have gennemgået ovenstående "reset" procedure, rent faktisk IKKE nulstillet. Man kan stadig fint logge ind med sine gamle credentials (hjælpsomt gemt af ens browser). Dvs. at password nulstilling OVERHOVEDET IKKE FUNGERER, den nulstiller ikke noget som helst. FAIL #3

Sig mig - hvad tænker i på? Jeg ville sådan set have forventet at, i lyset af artiklen, ville i have brugt dette som en anledning til at gennemgå/gennemprøve jeres egne sikkerhedsprocedurer, men åbenbart ikke. Far er skuffet, far er vred!!!

Så venligst:
- Giv brugerne mulighed for at bruge HTTPS og helst som default
- Lav password nulstilling der faktisk virker

NU, tak.

Lars Bjerregaard

og så lige for at medtage nogle flere ting, som andre også peger på:

4) Det er utilgiveligt, at i ikke sender folk en email om at de skal skifte password med det samme, og med det samme
nulstille alle folks konti, til de har skiftet password. FAIL #4

5) Brug en stærk, anbefalet og moderne hashalgoritme til at beskytte passwords, dvs. formodentligt bcrypt eller scrypt. Formodentligt FAIL #5

6) Der kunne placeres PHP filer hvor de ikke hørte til, dvs. at rettigheder i web filsystemet ikke er i orden. FAIL #6

Jeezz guys....

Kim Bjørn Tiedemann Blogger

Så mit brugernavn, email og password er ikke følsomme oplysninger?

Ikke følsomme nok til at jeg ikke mener at SHA512+salt ikke er nok til at beskytte adgangskoderne på sitet. Husk nu på, at der stadig skal laves en betydeligt indsats for at "cracke" ikke trivielle adgangskoder af en vis længde og jeg tror ærligt talt ikke, at der er nogen der gider den indsats i forhold til at kunne se din email adresse eller for at udgive sig for at være dig på version2.

En svag adgangskode bliver ikke stærkere af, at der benyttes KDF. Selvom hvert forsøg tager 1 sekund, så tager det ikke lang tid at løbe igennem de 20-100 mest brugte adgangskoder (123556, qwerty, etc) for hver bruger. Det kan paralleliseres på mange maskiner.

Man kunne fx løbe igennem denne liste: http://stricture-group.com/files/adobe-top100.txt

Hvis der virkeligt er tale om følsomme oplysninger, så bør der være 2-faktor på login.

Kim Bjørn Tiedemann Blogger

Hvorfor give køb på sikkerheden, hvis det bedst opnåelige er gratis og trivielt at implementere?

Som jeg har skrevet tidligere, er det ikke gratis. Drupal er en standardløsning ligesom WordPress, SharePoint og mange andre løsninger. Her er man underlagt de sikkerhedsvalg, som man har truffet på platformen. Hvis man ikke er tilfreds med standardløsningen, skal man ind og kode det om.

Vi giver hver dag køb på den ultimative sikkerhed i forhold til bekvemmelighed. Hvorfor skulle version2 stoppe ved KDF? Hvorfor ikke inkludere endnu en faktor på login? Det er altid en afvejning af omkostninger, bekvemmelighed etc og jeg synes det er fint at tage et bevidst valg, om at standardløsningens implementering med SHA512+salt er fint nok for dette site (ifølge min tidligere kommentarer ser det faktisk ud til, at Drupal 7 benytter en langsom hashing http://joncave.co.uk/2011/01/password-storage-in-drupal-and-wordpress/).

Desuden er det ikke "bare version2 sitet". Folk genbruger passwords på tværs af vigtige sites, kriminelle giver penge for din email adresse, etc...

Præcis - og når de gør det, så har de sikkert brugt det på et site, som har lavere sikkerhed end SHA512+salt. KDF løser ikke dette problem. Det kan kun løses gennem en adfærdsændring, brug af password managers eller 2-faktor.

Jakob Bruun Hansen

Præcis - og når de gør det, så har de sikkert brugt det på et site, som har lavere sikkerhed end SHA512+salt. KDF løser ikke dette problem. Det kan kun løses gennem en adfærdsændring, brug af password managers eller 2-faktor.

Men nu er det jo altså site her der er blevet hacket. Så hvad det andet site har er underordnet. Lad os sige, at angriberen er interesseret i et password tilhørende en enkelt debatør her, for at angribe ham et andet sted. Så er salt delen ikke længere relevant. Og beskyttelsen på det andet system heller ikke (forudsat det ikke er 2 faktor). Kun den superhurtige sha2 står så mellem angriberen og passwordet. En kdf ville hæve den nødvendige reaktionstid og sænke den nødvendige passwordkompleksitet med 3-4 størrelsesordner ift ren sha2. Jeg er enig i det ikke nødvendigvis er gratis, men det er heller ikke irrelevant.

Kim Bjørn Tiedemann Blogger

Men nu er det jo altså site her der er blevet hacket. Så hvad det andet site har er underordnet.

Mit argument er, at hvis man genbruger sine adgangskoder så har man helt andre problemer end om version2 bruger SHA512+salt. Fordi man nu er underlagt det svageste led i kæden af sites, som opbevarer ens adgangskode.

Lad os sige, at angriberen er interesseret i et password tilhørende en enkelt debatør her, for at angribe ham et andet sted. Så er salt delen ikke længere relevant. Og beskyttelsen på det andet system heller ikke (forudsat det ikke er 2 faktor). Kun den superhurtige sha2 står så mellem angriberen og passwordet. En kdf ville hæve den nødvendige reaktionstid og sænke den nødvendige passwordkompleksitet med 3-4 størrelsesordner ift ren sha2.

Enig - men angrebstiden afhænger stadig af entropien i debatørens adgangskode. Hvis der er tale om en almindelig brugt adgangskode, som kan slåes op i en tabel, så hjælper KDF dig (næsten) ikke. Hvis der er tale om en lang (+12), tilfældig adgangskode med store og små bogstaver, specialtegn og tal, så skal du stadig som hacker bruge lang tid på at cracke det (https://www.grc.com/haystack.htm).

Men vi da skal bruge KDF - men skal vi bruge tid (og penge) på at gøre det på alle sites derude, som benytter SHA512+salt? Det mener jeg ikke... Vi skal nok starte med at fjerne dem, der gemmer i plain text, MD5 eller SHA1 uden salt.

Og det her angreb har som andre også har skrevet, vist langt større problemer end måden hvorpå adgangskoden er gemt.

Jesper Lund

Mit argument er, at hvis man genbruger sine adgangskoder så har man helt andre problemer end om version2 bruger SHA512+salt.

Meget enig. Jeg aner ikke hvordan password sikkerheden er de cirka 200 steder, hvor jeg gennem tiderne har oprettet en konto til et eller andet. Jeg gider heller ikke bruge tid på at undersøge det.

Det eneste fornuftige er forskellige passwords på de enkelte sites. Det betyder brug af password manager, da ingen kan huske 200 forskellige passwords (well, jeg kan i hvert fald ikke). Og når man bruger en password manager, kan man ligeså godt generere tilfældige passwords af passende længde som 12-16 tegn.

Jens Jönsson
Bill Andersen

Hvad kan mit password til v2 og ing (det er to forskellige!)- så rent faktisk bruges til?
Ja, man kan udgive sig for at være ego, og dermed skrive i de to sites debatfora, men ellers kan jeg nu ikke se, at skaden er ret stor.


Nej, du har ret. Det ville ikke være nogen katastrofe. Tværtimod ville der måske for en gangs skyld komme noget fornuftigt fra din konto.

Mvh
Bill - der åbenbart heller ikke har forstået at man ikke behøver underskrive hvert indlæg med fjollerier.

Bill Andersen
Jakob Bruun Hansen

Du kan jo i den situation bruge sidens domæne, som en del af passwordet.

F.eks. DitPassWordversion2.dk

Det vil ikke beskytte det, hvis passwordet er gemt i klartekst eller bliver opsnappet fra en ukrypteret http session. Så ville det være lige til at læse dit "hovedpassword". Du kunne scramble dit sammensatte pasword selv først, f.eks

read -s | sha256sum | awk '{print $1}' | xclip -i  
skriv sammensat password

Så er det i det mindste ikke lige til at aflæse, og sikkert, hvis dit hovedpassword er sikkert. Men så er man jo næsten ovre i at gemme password i en password manager, og hvorfor så ikke bare gøre det?

Allan Høiberg

Jeg har lige fået en mail om sagen fra jer. Går jeg ud fra. :-)

En lille kilde til bekymring er at linket i mailen sender én omkring api.heyloyalty.com på vejen - så min første tanke er nødvendigvis at det kan være et phishingforsøg.

Der er vist også noget med "sikkerhedsrelaterede" links i emails i det hele taget, og hvad man plejer at forsøge at lære hele sin omgangskreds, de skal tænke som det første når de ser sådan nogen - men det... ;-)

Som en ekstra tanke: Hvis serveren har været hacket, kan vi så være sikre på at der ikke ligger en stump ond kode i password-oprettelsessiden, der snupper de nye koder med det samme, eller for den sags skyld i siden hvor man kan ændre sin gamle kode mens man er logget ind - og for at gøre det skal skrive den eksisterende? </sølvpapirshat>

/Allan

Peter Kyllesbeck
Henning Jensen

Som endog er ankommet på min "gamle" email?
Jeg ændrede min email her og på ing.dk for et par år siden.
Så huskes vores "gamle" emails længe ??

Alle links i mailen peger på "http://api.heyloyalty.com/redirect/index.php?l=oOKc65H5&m=6afcf557-cbxxx...;, også telefon nummer og mail linierne.

Kære bruger på Version2 job

Version2.dk har desværre været udsat for hacker-angreb. Du kan læse mere om sagen her:

http://www.version2.dk/artikel/version2-og-mediehuset-ingenioeren-udsat-...

Vi arbejder på højtryk for at rydde op og sikre systemerne mod fremtidige angreb.

Vi regner ikke med, at dine data er blevet stjålet, og vi regner heller ikke med, at dit kodeord er blevet det. Men vi kan ikke garantere det.

Og for en sikkerheds skyld skal man altid ændre kodeord på de ramte sites - og eventuelt på andre sites, hvor du har brugt samme kodeord.

Du kan skifte kodeord her:

http://www.version2.dk/user/password

Bemærk, at du ikke skal være logget ind, når du bruger dette link.

Med venlig hilsen

Jesper Bille Haun
It- og udviklingschef

Mediehuset Ingeniøren A/S
Kalvebod Brygge 31-33
DK - 1560 København V

Direkte: +45 33 26 53 41
Mobil: +45 24 46 52 65
Mail: jbh@ing.dk

Steen Christensen

Alle links i mailen peger på "http://api.heyloyalty.com/redirect/index.php?

Den slettede jeg med det samme. Der er for mig ingen tvivl om at jeg ikke skal stole på den mail. Det er ren phishing .

Hvis det mod forventning skulle vise sig at den er ægte, må jeg sige at det er ekstremt uproffesionelt udformet. Det går stik imod alle anbefalinger omkring håndtering af sådan en situation.

Det vil være rart med en bekræftelse fra Version 2 her på siden om denne mail er falsk eller ægte.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen