Problem med sikkerhed (opbevaring af koder)

Her kan du rapportere de fejl, som du finder ved brug af Saldi.

Redaktører: Agerskov, Peter Rude, Sarah Aagaard

Besvar
Tony
Indlæg: 26
Tilmeldt: tors apr 26, 2012 1:47 pm

Problem med sikkerhed (opbevaring af koder)

Indlæg af Tony »

Sad og kiggede lidt på det js der bliver brugt til at gemme/validere passwords.

Det er desværre en MD5 uden brug af salt eller andet!

Det store problem er ikke sikkerheden på selve sitet. Problemet er, at alle passwords dermed bliver gemt som hashes, hvor der på nettet kan findes rainbow tables, som gør det er lige til højrebenet at lave opslag på brugernavn og password... Og eftersom mange gemmer backup af deres database (Saldi understøtter det direkte, nærmest opfordrer til det) - så er det noget rigtigt møg hvis nogen får fingre i din database...

Problemet er, at det er nemt at finde brugernavn-password kombinationen, og de fleste af os genbruger vores passwords på forskellige sites.
Resultatet er, at vi næsten lige så godt kunne have opbevaret passwords i klartekst!

En bedre løsning ville være at alle Saldi installationer bare have en fælles salt (kunne i princippet bare være at tilføje "saldi" til alle passwords inden MD5 hash bliver lavet - dermed er odds for at der ligger en offentlig rainbow table faktisk væk. Det er selvfølgelig stadig muligt at lave brute force cracking - men det kan ikke undgås.. En installationsspecifik salt er selvfølgelig endnu bedre :)

Løsningen: Lige til højrebenet for alle med adgang til koden. Tilføj en salt værdi i /javascript/md5.js - husk lige manuelt at få opdateret alle passwords i jeres bruger tabeller (både admin og end users), ellers kan ingen logge ind.

Det betyder selvfølgelig, at jeres login ikke vil virke længere, hvis man så overskirver sin tilrettede md5.js! Husk det!

(og husk på, at alle jer der har den hostede løsning: Hvis Saldi teamet skulle have lyst - eller nogen får hacket deres database - så tager det under 5 min. at få alle brugernavn-password kombinationer cracket! Så genbrug er en katastrofe! - når password bliver gemt som de gør i dette tilfælde)
Peter Rude
Udvikler
Indlæg: 613
Tilmeldt: tirs okt 28, 2003 11:07 pm

Indlæg af Peter Rude »

md5.js anvendes kun hvis variablen $brug_timestamp er sat, hvilket den normalt ikke er. Den er lavet til installationer som kører uden https, da koden bliver "posted" i klartekst mellem index.php & login.php.

Så hvis man vil anvende salt inden koden skrives i tabellen er der flere steder der skal rettes.
admin/admin_brugere.php
admin/opret.php
index/install.php
index/login.php
systemdata/brugere.php

Jeg prøver at udtænke en mere sikker løsning, med anvendelse af en form for unik salt værdi. Udfordringen ligger i at det skal være muligt at indlæse en sikkerhedskopi et andet sted, samtidig med at salt værdien ikke må stå i databasen eller kildekoden. Uanset hvad, vil metoden være til at læse sig til i kildeteksten, og det vil således være muligt at knække koden, for en begavet cracker.

Under alle omstændigheder er det vigtigt at bruge en adgangskode som er unik, og ikke den samme som der bruges til alle andre sites.
Go' fornøjelse.
/Peter

Opret et professionelt regnskab på https://saldiregnskab.dk
Ring på 4690 2208 hvis du vil vide mere.
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

Indlæg af nielsrune »

Som jeg har forstået det, skal man skelne mellem disse to ting, der ikke kan løses på samme måde:

1) Opbevaring af passwords på serveren
2) Transmission af password mellem klient og server

Det første sigter imod at sikre sin database, i det tilfælde en fremmed får adgang til databasen, et dump, eller en backup af denne.

Det andet sigter mod at forhindre, at uvedkommende kan aflæse password, hver gang en bruger logger ind.

Ad 1) skal salt være unik per bruger, og være helt tilfældig ved hver ny bruger eller når en bruger ændrer sit password. Salt kan endvidere uden problemer ligger i databasen i brugertabellen.

Derimod skal hash af password+salt beregnes på serveren. I brugertabellen ligger så to felter. Et med salten, og et med hash(password+salt).

Når en bruger ved logon indtaster sit brugernavn og password bliver det (her i eksemplet) sendt i klartekst til serveren. Serveren finder så brugeren i databasen på baggrund af brugernavn, og henter den salt, der ligger i brugerens tabelrække. På baggrund af salten og det indtastede password beregnes en hash. Denne hash sammenlignes med den hash, der ligger i brugerens tabelrække, og hvis de to er ens, skal brugeren logges ind. Er de ikke ens, skal siden blot fejle men ikke afsløre, at man har ramt et brugernavn, der findes i databasen.

Proceduren er udemærket beskrevet i artiklen https://crackstation.net/hashing-security.htm, hvor der også er et php-script har til at hente og implementere.

edit: På min Debian 7 skulle jeg lige have installeret php5-mcrypt, før det virkede

Ad 2) er dette en helt anden opgave, der også kort nævnes i ovenstående artikel. Det mest optimale er en HTTPS-forbindelse, men det er jo ikke alle selv-hostere der har sådant, eg. hvis saldi alene køres på lokalt netværk. $Brug_timestamp er fin, men sikrer ikke 100% imod MITM-angreb, da serveren identitet ikke kan garanteres.

Foruden et selvudstedt ssl-certifikat bruger jeg $brug_timestamp, og synes det er et umærket praksis at bruge. Implementeres ovenstående, skal $brug_timestamp jo blot opdateret ud fra samme princip som nu, hvor de to databasens hash og den beregnede hash af indtastet kodeord også lige hashes med timestamp, inden de sammenlignes.

Dog i forhold til brug_timestamp: Hvis hash-algoritmen ikke i samme forbindelse opdateres til sha256 el.lign., vil I fra Saldi-teamets side så ikke opdatere javascript/md5.js til den nyere version 2.2, der ligger på programmørens hjemmeside http://pajhome.org.uk/crypt/md5/md5.html. Version 2.1, der følger med Saldi har tidligere givet mig problemer med passwords, der indeholder æøå.

Som beskrevet er der altså to helt forskellige sikkerhedstiltag, der ikke bør eller kan sammenlignes, men skal implementeres hver for sig. Og så skal der naturligvis skrives en overgangsside, til opdatering af alle passwords fra md5 til sha256+salt :-)

I forhold til sikkerhedskopierne, burde ovenstående også løse dine tanker herom. Evt. kunne man helt undlade at skrive passwords til backupfilerne, som nu, og i stedet kræve, at der er oprettet en gyldig bruger, inden der kan indlæses en backup.

Med venlig hilsen

Niels Rune Brandt
Brugeravatar
ht
Indlæg: 62
Tilmeldt: ons nov 23, 2011 10:33 pm

Re: Problem med sikkerhed (opbevaring af koder)

Indlæg af ht »

Lyder rigtigt Niels jeg stemmer for endnu/bedre sikkerhed i Saldi, det er jo vigtig information Saldi gemmer på, og tak for links de er informative !
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

Re: Problem med sikkerhed (opbevaring af koder)

Indlæg af nielsrune »

http://www.version2.dk/blog/omg-de-send ... ekst-67971

Et interessant blogindlæg om lige netop den nuværende implementering.
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

Re: Problem med sikkerhed (opbevaring af koder)

Indlæg af nielsrune »

I mangel af bedre har jeg selv givet dette et forsøg, der netop er lagt på https://github.com/nielsrune/saldi/tree/pbkdf2

Løsningen implementerer PBKDF2 er understøtter alle nyinstallationer samt eksisterende installationer både ved oprettelse af nye regnskaber men også allerede eksisterende brugeres regnskaber, hvor brugeren her skal skifte adgangskode ved første login.

Sikkerhedskopier rammes derved, at hidtidige koder i md5-hash ligger direkte i sikkerhedskopierne. Man bør derfor så vidt muligt lave nye sikkerhedskopier.
Timestamp-systemet er deaktiveret, dels da det ikke var implementeret konsekvent alle steder, hvor der sker login, dels da det reelt ikke giver nogen sikkerhed imod mellemmandsadgreb. Alle installationer bør derfor køres over https. Lokale LAN-installationer kan med fordelt bruge selvsignerede ssl-certifikater. Virker uden problemer hos mig.

Køres en installation ikke over https sendes adgangskoder mv. direkte som klartekst mellem klient og server. Som tidligere nævnt i denne tråd er formålet med denne implementering alene at sikre, at brugerens adgangskode, der tit er den samme på flere sites, ikke kommer en angriber til kundskab. En indtrægen i databasen eller en sikkerhedskopi stiller alligevel i princippet hele regnskabet til rådighed for den tålmodige.

Jeg skal lige køre nogle flere lokale tests inden jeg oprettet en pull request, me jeg håber med dette, at den fortsatte udviklingen af Saldi snart bliver flyttet 100% over på git i stedet for patchede filer på en ftp-server som nu.
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

Re: Problem med sikkerhed (opbevaring af koder)

Indlæg af nielsrune »

Pull request er nu lagt på github

https://github.com/DANOSOFT/saldi/pulls
Besvar