kim tiedemann bloghoved

OMG - de sender mit 5f4dcc3b5aa765d61d8327deb882cf99 i klar tekst

Jeg havde egentligt ikke forestillet mig, at mit tredje blogindlæg også skulle handle om sikkerhed, men jeg stødte på en sjov implementering, som jeg må dele.

Dette er endnu et offentligt system, som er meget brugt og som tilbyder personificeret indhold og følsomme oplysninger til autentificerede brugere.

Vi må ikke sende adgangskoden over en ukrypteret kommunikationslinje

Det er tydeligt, at der er nogen, der har sagt "vi må ikke sende adgangskoder over en ukrypteret linje", men i stedet for at lave https på sitet, så har man i stedet forsøgt at opnå sikkerhed på anden vis.

Hashing client-side

Brugeren bliver altså præsenteret for en login formular over ganske almindelig http. Brugeren kan indtaste brugernavn og adgangskode:

Illustration: Privatfoto

Html form'en postes tilbage til http://.../Login.asp, og under normale omstændigheder vil adgangskoden derfor også postes tilbage i klar tekst.

Men på sitets javascript findes en lille funktion, som kaldes på html form'ens onSubmit.

    function krypterKode() {
        document.form.md5kode.value = 
              hex_md5(document.form.adgangskode.value);
        document.form.adgangskode.value = '';
    }

Bemærk at funktionen kaldes kryptér kode :-)

Inden form'en submittes tilbage til login siden, så "krypteres" adgangskoden med MD5, hvorefter MD5 værdien puttes ind i et hidden felt og adgangskode feltet nulstilles.

Hvad er der galt med denne metode?

Der er mange ting galt med implementeringen.

For det første har man ikke sikret noget som helst. Eve (den onde hacker) har slet ikke brug for Alice's (den rare og uvidende bruger) adgangskode i klar tekst. MD5 hash værdien er nok til at logge ind, og den sendes i klar tekst uden brug af https.

For det andet er det dårlig praksis at bruge client side hashing i forbindelse med adgangskoder, da der bør være et server-side hash check også. Hvis hashing kun sker client-side og brugerdatabasen for sitet kompromiteres, så er det altså muligt for hackeren, at logge ind som alle brugere, da hackeren jo principielt har alle adgangskoder! Det svarer til at gemme adgangskoden i klar tekst i databasen.

For det tredje så kan vi med ret stor sandsynlighed antage, at sitet gemmer MD5 hashværdien i brugerdatabasen. Skulle denne database blive kompromiteret på et tidspunkt, er det en smal sag ved brug af lookuptabeller eller brute-force at få brugernes adgangskoder ud i klar tekst. Desvære ved vi, at brugere genbruger samme brugernavn og adgangskode på tværs af sites (bare spørg din omgangskreds), og derfor vil de kompromiterede informationer med stor sandsynlighed kunne misbruges på andre sites. Sitet burde benytte en mere moderne hash algoritme som SHA-2 samt salt'e adgangskoden pr bruger. Hvis man vil gå all-in, så kunne de bruge en langsom kryptografisk algoritme som PBKDF2 eller bcrypt.

For lige at opsummere:

  • Https everywhere
  • Benyt server-side hashing
  • Benyt moderne hash algorimer og husk rigeligt salt
  • Benyt langsomme kryptografiske algoritmer som PBKDF2 eller bcrypt, så brute-force bliver umulig i praksis.

Hvis man nogensinde mangler argumenter for, hvorfor adgangskoder som minimum skal hashes og saltes, så er her en god FAQ.

Ps 5f4dcc3b5aa765d61d8327deb882cf99 er MD5 hash for strengen "password"

Kommentarer (41)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Uffe Seerup

Udvikleren har læst, at man kan undgå passwords i klartekst ved at envejskryptere passwords.

Og hvorfor skulle man dog spilde server ressourcer i disse JavaScript tider?

(sarkasme kan forekomme i ovenstående)

Ja, det ligner "checkbox" udvikling, hvor man har kunnet fortælle kunden at "selvfølgelig sender vi ikke passwords i klartekst".

Man glemmer så lige at sige, at med den valgte løsning har angribere heller ikke brug for password'et i klartekst. Eve vil være fint tilfreds med hashværdien. Så behøver hun ikke engang selv hash'e.

Mere formelt kunne man sige, at løsningen danner sit eget password ud fra brugerens "key-phrase" - og at dette password stadig overføres i klartekst.

  • 9
  • 0
Bjarke Walling

Jeg begik selv samme fejl engang, men er blevet klogere siden. Jeg hashede passwordet med et timestamp for at man ikke bare kunne genbruge samme token, men det skal bemærkes at man generelt ikke kan lave crypto client-side, så længe at JS-koden ikke serveres over HTTPS.

  • 2
  • 0
Baldur Norddahl

at man generelt ikke kan lave crypto client-side, så længe at JS-koden ikke serveres over HTTPS

Du kan ikke lave noget som er sikkert imod man-in-the-middle angreb. Men du kan godt lave noget der beskytter imod simpel aflytning.

HTTP har iøvrigt en indbygget mekanisme til at udveksle kodeord, som sikrer imod simpel aflytning: HTTP Digest Access Authentication: http://en.wikipedia.org/wiki/Digest_access_authentication

  • 2
  • 0
Peter Makholm

Jeg er enig i dine betragtninger om den konkrete implementation, men jeg er uening i at man skal undgå at hashe på klienten. Gjort rigtigt kan det øge sikkerheden af det samlede system væsentligt.

En mulighed er HTTP digest mode som Baldur Norddahl henviser til. I dag ville jeg dog nok nærmere se på SASL SCRAM-SHA1 (RFC5802) der gør ting en smule anderledes.

Både digest mode og SCRAM kræver dog at man gemmer kodeord i klar-tekst, til gengæld kan man så designe sin server så det er en meget begrænset del af applikationen der har adgnag til kodeordet i klartekst. Denne del kan så beskyttet ekstra meget. Ved en traditionel server hashing-metode er det den mest sårbar del af serveren der har adgang til kodeordet i klartekst, nemlig forenden der er direkte tilgængelig fra det store skumle internet.

Hvis man er midelmådig til sikkerhed bør man nok bare sende kodeordet i klartekst over en krypteret forbindelse (SSL) og sammenligne med en hashet og salted udgave man har liggende i databasen. Men det er ikke nødvendigvis den optimale løsning hvis man viirkelig vil lave sikre systemer.

  • 3
  • 0
Casper Paulsen

Man behøver da ikke nødvendigvis gemme kodeordet i klartekst? Kan det ikke køres igennem en hashing funktion før det anvendes i SASL eller Digest, så det er denne hash værdi der er gemt i databasen og samtidig bruges af klienten?

Kan sgu ikke lide ideen om at et password er gemt i klartekst.

  • 2
  • 0
Peter Makholm

Man behøver da ikke nødvendigvis gemme kodeordet i klartekst? Kan det ikke køres igennem en hashing funktion før det anvendes i SASL eller Digest, så det er denne hash værdi der er gemt i databasen og samtidig bruges af klienten?

Spørgsmålet er lidt hvad vi opfatter som 'kodeordet'. For mig er der forskel på 'det brugeren taster ind' og 'den byte-string der bruges til authentificering'. Ud fra en sikkerhedsvurdering er det sidstnævnte der kan bruges til et angreb og derfor holdes hemmelig.

Det er helt fint at hashe før digest/scram og så gemme hashen. Men man skal stadigvæk være opmærksom på at det man gemmer er tilstrækkeligt til at gennemføre en authentification. Det vil sige at ens database skal alligevel besykttes som gemte den direkte på brugernes input.

Andre operationer det kan være passende at foretage mellem brugerens input og selve authentificationen er unicode normalisering (og grundlæggende sørger for at ikke-ascii tegn er unicode og ikke et tilfældigt tvetydigt tegnsæt).

  • 4
  • 0
Bjarke Walling

Et sted, hvor citronen virkelig bliver presset i henhold til JS crypto, er HTML5-baserede bitcoin wallets. Folk ønsker ikke at deres nøgle bliver opbevaret på serveren – de stoler ikke på at tredjeparter kan opbevare nøglen sikkert eller af ideologiske hensyn. Omvendt er der åbenlyse udfordringer ved at foretage al crypto client-side. Der er eksempler på folk, der har fået stjålet sine penge af ondsindede browser extensions. Den bedste løsning i dette tilfælde er måske at bruge 2FA / multi-signature, foretage crypto både client- og server-side, lade serveren checke at transaktionen holder sig indenfor foruddefinerede parametre og kun acceptere den, hvis brugeren kan autentificeres ad andre kanaler. Eller lade folk hoste deres egen lokale server.

  • 1
  • 0
Jesper Udby

Nu kan man argumentere for om ikke informationerne i det pågældende system af og til kan være så følsomme at forbindelsen derfor burde være via SSL.

Og lad nu være med at antage noget om hvor dårligt de sandsynligvis har implementeret sikkerheden server-side. Det ved du vel reelt ikke noget om?

Jeg synes client-side hashing er udemærket. I systemer som ikke arbejder med følsom information - det kunne f.eks. være svømmeklubbens holdtilmeldingssystem - hvor SSL ikke er nødvendigt og hvor administration af og omkostninger til SSL kan være uden for foreningens muligheder, der er det en udemærket work-around til at undgå at brugernes kodeord kommer over linien i klartekst.

  • 1
  • 4
Henrik Pedersen

Jeg kan sværge at jeg har set NØJAGTIG samme kode i SkoleIntra (det gamle IT system til folkeskolerne hvor man kunne kontakte skolen osv.)

Jeg var også dybt forundret over client-side MD5 hashing. Det at være udvikler burde egentlig kræve et certifikat, som skulle generhverves hver 6 måned...

  • 2
  • 1
Thomas Larsen

Jeg kan sværge at jeg har set NØJAGTIG samme kode i SkoleIntra (det gamle IT system til folkeskolerne hvor man kunne kontakte skolen osv.)


Ja den er god nok. Det er de 'kompetente' folk hos SkoleIntra/ForældreIntra der har indført den vanvittige sikkerhedspraksis. Sammenlign eventuelt skærmbilledet i blogindlægget med følgende login-dialog:

http://www.kirstine.skoleintra.dk/Infoweb/Fi2/Default.asp

Men det er måske ikke så underligt. I det hele taget hersker der en nærmest grænseløs uvidenhed blandt offentlige digitaliseringsmedarbejdere om hvad sikkerhed reelt indebærer. Hvordan skulle man ellers forklare at SKAT fortsat 'krypterer' deres TastSelv-løsning med RC4? Det er i parentes bemærket en cipher-algoritme der har været frarådet af alle sikkerhedseksperter herunder Microsoft i adskillige år...

  • 3
  • 0
Kim Bjørn Tiedemann Blogger

Hvis du bare sender hashen hen over http i stedet for adgangskoden, så har du jo ikke opnået noget. Jeg behøver ikke din adgangskode - hashværdien er nok :-) Og når man så ydermere gør det uden salt og med en svag hashing algoritme, så er der ikke langt fra hash værdien til adgangskoden i klar tekst - og adgangskoder genbruger folk på tværs af sites.

Man kan i dag få SSL certifikater gratis hos https://www.startssl.com/, så omkostningerne burde ikke holde os tilbage.

  • 2
  • 0
Kim Bjørn Tiedemann Blogger

Jeg skrev faktisk også, at client side-hashing burde kombineres med server-side og ikke stå alene. Dette er tilfældet for både digest mode og scram, hvor serveren er involveret.

Jeg synes det er vigtigt, at vi ikke gemmer folks adgangskoder i klar tekst i en database. Der har været alt for mange eksempler på, at trods gode hensigter, så bliver de kompromiteret (også selvom de er beskyttet ekstra meget - spørg bare Sony, Adobe og Ebay). Det sker og når det sker er skaden stor, for almindelige brugere genbruger deres adgangskoder på tværs af sites. Men Scram kan jo fint kombineres med langsomme kryptografiske funktioner som PBKDF2, så det ikke er muligt at lave offline attacks selvom brugerdatabasen bliver kompromiteret.

  • 1
  • 0
Anders Palm

Men det er måske ikke så underligt. I det hele taget hersker der en nærmest grænseløs uvidenhed blandt offentlige digitaliseringsmedarbejdere om hvad sikkerhed reelt indebærer

Skoleintra er udviklet af et lille 2-mandsfirma, begge udviklerne er folkeskolelærere uden nogen formel udviklingsuddannelse bag sig. Projektet var oprindelig tiltænkt som et lokalt lille projekt i de 2 læreres kommune.

UNI-C stod kun for salg og support, ikke udvikling.

Det forklarer nok en del :)

  • 3
  • 0
Morten Juhl-Johansen Zölde-Fejér

I det hele taget hersker der en nærmest grænseløs uvidenhed blandt offentlige digitaliseringsmedarbejdere om hvad sikkerhed reelt indebærer.


Men bliver det hele ikke udliciteret? Hvor meget udvikling foregår i direkte offentligt regi? Det er vel kun kravspecifikationen og evalueringen af dens opfyldelse, der foregår i offentligt regi?
Ikke at det ikke er rigtigt, at der er problemer forbundet med de offentlige digitaliseringsprojekter, men det forekommer mig, at distinktionen er en anelse konstrueret.

  • 0
  • 0
Jesper Udby

Man kan i dag få SSL certifikater gratis hos https://www.startssl.com/, så omkostningerne burde ikke holde os tilbage.

Mine erfaringer med "drift" af hjemmesider i små foreninger siger mig at "omkostninger" er mange ting. At man kan få SSL certifikater gratis er ikke det samme som at det er uden omkostninger at implementere og drifte.
Det er i øvrigt ofte en udfordring blot at finde én i bestyrelsen - eller dennes omgangskreds - som magter drift/vedligehold af hjemmesider...

  • 1
  • 0
Jesper Udby

Jeg behøver ikke din adgangskode - hashværdien er nok :-)


Du misforstår min pointe. Har du adgangskoden (eller dennes hash) kan du logge på, ja.

Men ved hashing sendes adgangskoden ikke i klartekst... Så hvis du opsnapper min hash, ved du ikke nødvendigvis hvad min adgangskode var... Og hvis jeg har brugt den samme adgangskode i min bank er du ikke tættere på... Er vi enige her?...

At MD5 så er en skod-hash er en anden detalje. Men det kan jo være man kan sige det samme om SHA-512 om nogle få år...

  • 1
  • 3
Kim Bjørn Tiedemann Blogger

Men ved hashing sendes adgangskoden ikke i klartekst... Så hvis du opsnapper min hash, ved du ikke nødvendigvis hvad min adgangskode var... Og hvis jeg har brugt den samme adgangskode i min bank er du ikke tættere på... Er vi enige her?...

Nej - overhovedet ikke. Hvis du ikke tilfører pr. bruger salt til din hash, så kan jeg slå op i tilgængelige hash-lister eller rainbow tables og finde ret mange adgangskoder, fordi rigtigt mange almindelige brugere benytter simple og ikke særligt tilfældige adgangskoder. Du gør sikkert ikke, men det er blevet tydeligt i forbindelse med lækkede brugerdatabaser, at mange benytter simple passwords som 123456. Se bare på listen fra Adobes lækkede passwords: http://stricture-group.com/files/adobe-top100.txt.

Så det bliver efter min mening ikke en sikker løsning og næsten lige så slemt, som at sende adgangskoder over http.

  • 4
  • 0
Jesper Udby

Så det bliver efter min mening ikke en sikker løsning og næsten lige så slemt, som at sende adgangskoder over http.


Glimrende! Vi er enige!

Jeg har aldrig påstået det var sikkert og vi er enige om at det (kun) næsten er ligeså slemt som at sende adgangskoder over HTTP.

Det minder mig om at jeg da har alvorlige problemer med mine WordPress-drevne blogs som kører HTTP og hvor brugernavn/adgangskode sendes over HTTP i klartekst...

  • 0
  • 0
Kim Bjørn Tiedemann Blogger

Prøv at tage et kig på siden igen. Den udgave af systemet som jeg bruger, anvender i hvert fald https. Måske er du blevet snydt af, at siden er indlejret i en iframe. Iframen kører https, mens "ydersiden" kører http.

Det er rigtigt at den side, som der linkes til i en af kommentarerne, benytter https til login-framen og dermed "er sikker". Det virker dog som om, at det her system er deployet til mange forskellige driftsmiljøer og det er ikke alle, der benytter https til login frames. Der findes også udgaver, som udelukkende kører https.

Desværre så åbner man op for en helt anden problemstilling ved at benytte http til at loade framesettet og https til at loade de enkelte frames herunder loginframen. En Man-In-The-Middle vil kunne intercepte http trafikken, manipulere med server-response og dermed erstatte login framen med egen login side eller login siden uden https (fx med sslstrip). Og så er vi lige vidt :-)

  • 4
  • 0
Thomas Larsen

UNI-C stod kun for salg og support, ikke udvikling.

Det er vel kun kravspecifikationen og evalueringen af dens opfyldelse, der foregår i offentligt regi?

Det er offentlige myndigheder der forlanger at vi alle skal bruge deres digitale selvbetjeningsløsninger. Uanset hvem der udvikler løsningen er det i sidste ende de offentlige myndigheder og deres medarbejdere der bærer ansvaret for den ufatteligt ringe sikkerhed i de eksisterende løsninger. I en tid med systematisk masseovervågning af uskyldige borgere er det rimeligt at sige Digitaliseringsstyrelsen og/eller KL i allerhøjeste grad har svigtet deres ansvar ved ikke at udstikke tekniske retningslinjer for hvad der betragtes som en sikker selvbetjeningsløsning.

  • 4
  • 0
Michael Weber

http://www.version2.dk/artikel/sikkerhedshul-pivaabent-paa-8-maaned-stud...

Artiklen er fra juni 2010.
Er den ikke bare et symptom for, at KU på daværende tidspunkt ikke helt var kommet i mål med deres centralisering af deres IT-funktion?

Så vidt jeg ved, centraliserede de tilbage i slutningen af 00´erne de forskelige IT-afdelinger et eller andet sted inde i Kbh. i et eller anden form for "Babelstårn" i.e. langt væk fra brugerne. Måske husker jeg forkert.

  • 0
  • 0
Thomas Larsen

Artiklen er fra juni 2010.
Er den ikke bare et symptom for, at KU på daværende tidspunkt ikke helt var kommet i mål med deres centralisering af deres IT-funktion?


Hvis du læser artiklen vil du opdage at en fuldmægtig fra Uddannelsesservice er interviewet og at han udtaler at fejlen blev indberettet til leverandøren i efteråret 2009:

»Jeg har tjekket indberetningen fra sidste efterår og kan se, at tilbagemeldingen dengang var, at vi på system-niveau skulle ændre visse rollers adgang til at redigere html i systemet. Det gjorde vi efter bedste evne, men jeg kan nu forstå, at problemet stadig ikke er løst,« siger fuldmægtig i Uddannelsesservice, Peter Aagerup Jensen.

»Men det er utroligt så mange ting, der sker forbløffende hurtigt, når man fortæller leverandøren, at der er en artikel om hullet under opsejling. Vores leverandør Uni-C ekspederer straks sagen videre til norske IT's learning, der ved middagstid i dag (tirsdag red.) siger, at fejlen er fundet, og at de håber at have en løsning klar senere på dagen. Den er dog endnu ikke kommet,« siger Peter Aagerup Jensen sent tirsdag eftermiddag.

Episoden er nok snarere udtryk for at Uni-C - i hvert fald dengang - var en gevaldigt søvnig og selvtilstrækkelig organisation.

  • 1
  • 0
Jesper Udby

Du kan købe et single-site SSL certifikat for ~200 kr. om året. Nok ikke lige noget der vælter en forenings budget.


Jeg gentager:

Mine erfaringer med "drift" af hjemmesider i små foreninger siger mig at "omkostninger" er mange ting. At man kan få SSL certifikater gratis er ikke det samme som at det er uden omkostninger at implementere og drifte.

Det er i øvrigt ofte en udfordring blot at finde én i bestyrelsen - eller dennes omgangskreds - som magter drift/vedligehold af hjemmesider...

  • 2
  • 1
David Nielsen
  • 0
  • 2
Jesper Udby

Så skal de formentlig ikke selv drifte et website?

Men istedet bruge en hosted og professionelt driftet site

Okay, jeg skulle have været mere præcis. Når jeg skriver "drift" tænker jeg "drift i samarbejde med en Hosting Provider (HP)". Det er ikke det samme som at der ikke er drift-relaterede opgaver...

Forskellige HP'er har forskellige tilgange til SSL. Hos nogen er det dyrt og besværligt, hos andre er det nemt og stort set gratis.

Hvis din HP terminerer SSL'en på en load-balancer i DMZ'en (eller tæt på), så er trafikken sandsynligvis ukrypteret på bagsiden af denne.
Det betyder så blot at du skal have tillid til din HP.
Men det skal du jo alligvel, for det er jo der databasen med alle de saltede og hashede kodeord ligger :-)
Hvilket jo så ikke hjælper dig hvis dine kodeord drøner ukrypteret over en intern forbindelse hvor en kriminel (eller blot lettere anløben medarbejder, betalt af Se & Hør f.eks.) lytter med...
For slet ikke at nævne log-filer...

Sikkerhed er sq svært, så lad nu være med at pege fingre af andre der måske ikke lige har fået det helt korrekt første gang.
Det bygger i høj grad på tillid - som PHK er inde på andre steder - tillid til dem eller de der har de rigtig interessante adgange; om det så er til databaser, netværk eller anden infrastruktur.

Og som jeg for snart længe siden forsøgte at argumentere for, så er der situationer hvor det ikke er super-vigtigt at sikkerheden er som i... Lad mig se... Bankerne?

  • 0
  • 2
Martin Kristiansen

Hvis man alligevel bruger JS på klientsiden til autorisation er det på alle måde bedre at bruge en challenge/response protokol. Her bedes serveren om en challenge (et random hash). En response dannes på klientsiden ved at hashe denne challenge sammen med det indtastede password. Response sendes tilbage til serveren, der så validerer om den matcher det forventede.

Herved sendes hverken password, eller direkte hashes af password til server og man kan lave autorisation uden SSL.

TLS/SSL implementationer har så ringe en sikkerhedshistorie at det er naivt kun at sikre vha. SSL, IMHO.

  • 1
  • 0
Sebastian Paaske Tørholm

Artiklen er fra juni 2010.
Er den ikke bare et symptom for, at KU på daværende tidspunkt ikke helt var kommet i mål med deres centralisering af deres IT-funktion?

På Københavns Universitet har de forhindret udnyttelse af det ved at forhindre al HTML input fra brugere, men på en standard instans af it's learning skulle jeg mene, at dette hul (eller en nært beslægtet variant) stadig er tilgængelig.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize