Webudvikling: Sikker håndtering as passwords

Der er mange webudviklere som reelt ikke har den fjerneste ide om hvordan et password skal behandles, selv store sites som f.eks. LinkedIn har for nyligt vist at de ikke har styr på det.

1. Opbevar altid passwords krypteret

Hvis du som website udvikler på noget tidspunkt kan læse en brugers password, så er det en fejl. Passwords skal altid gemmes på en sådan måde at de ikke kan læses igen når de først er indtastet, det kaldes populært for “krypteret” mén faktisk er det forkert, fordi kryptering er pr. definition two-vejs, du kan kryptere og du kan afkryptere.

One-way hashing kan ikke “afkrypteres” men tilgengæld ved vi at det samme password altid vil give den samme hash og vi kan derfor blot sammenligne hashen af det gemte password med hashen af det indtastede password.

Som en sidste kommenar skal du altid bruge en sikker hash-algoritme, world-wide vækst indenfor computerkraft er eksponentielt og algoritmer der var sikre i 90’erne er idag nemme at bryde og dem der var sikre i 70’erne er endnu nemmere. Det betyder at f.eks. den populære md5 hash-function er usikker og ikke bør bruges, brug istedet sha-256 eller sha-512 som f.eks. kan implementeres med Php’s hash() funktion, derudover skal du bruge en unik salt pr. bruger/password.

2. E-Mail er så sikker som et postkort

Når du sender en email til en person så skal du forvente at det bliver læst af mindst 20 andre mennesker, din chef,  systemadministrator, internet udbyder, din kone, dine børn og et par tilfældige efterretningstjenester, hackere og spyware produkter.

Så det er aldrig acceptabelt at sende et password i en email, for det første fordi du ikke må have kendskab til brugeres password ifht. punkt 1, derudover giver du resten af verden hovednøglen til din bruger konto – og andre konti hvor denne bruger samme password.

Det er selvfølgelig heller ikke iorden at sende Visa/Dankort detaljer eller andre personlige information via E-Mail – og hvis du har behov for at sende f.eks. et password til en kunde, så generer et one-time-password til kunden som kun kan bruges én gang.

3. Begræns ikke password og udnyt entropy

Passwords skal være unikke og de skal være komplekse, hvis brugeren indtaster mærkelige tegn eller mellemrum, samt store og små bogstaver så er det alt sammen med til at gøre password sværere at gætte og hvis brugeren selv vælger at bruge disse tegn har kunden  formodentligt også styr på at taste password rigtigt hver gang.

Der er nogle sider der fjerner store og små bogstaver og specialtegn fra passwords, eller som giver en fejl hvis man indtaster et password med mellemrum i eller hvis man bruger specialtegn.

Jeg føler lidt at det er spild af jeres tid og sige det her, men jeg har set det flere steder og det er hamrende uprofessionelt og der er INGEN undskyldning for at simplificere brugerens password og da slet ikke for at begrænse brugerens password.

Det eneste du bør gøre ved dine brugeres indtastninger i et password felt er at hashe det, og gemme hashen. Punktum!

4. Undgå Information leaks

Når dine brugere glemmer deres passwords, og det gør de. Så skal de kunne genetablere det, det foregår typisk ved at du indtaster din email adresse på hjemmesiden og modtager en email med en one-time-url til at ændre dit password.

Det er sådan set fint nok, med mindre at formularen kan bruges til at gætte brugernavne med. Hvis du kan indtaste bruger@domæne.com og få beskeden “Beklager meget, men den indtastede adresse findes ikke i vores system” eller hvis du kan indtaste brugernavn og password og få beskederne hhv. “Dit brugernavn er forkert” og “Dit password er forkert”.

Ovenstående giver en angriber mulighed for at gætte sig frem til et gyldigt brugernavn, og det er selvfølgelig noget der skal undgåes.

Enkelte steder har jeg enddog opdaget at jeg blot ved at taste min email adresse får adgang til mit navn, adresse, telefon og email samt ordrehistorik.

Dette er selvfølgelig en stor fejl og skal undgåes, sørg for at en bruger altid skal oplyse både email og password, eller email kombineret med modtagelse af en email for at opnå adgang til opbevaret information.

5. Undgå at bruge passwords

Jeg kom lidt ind på det før med modtagelse af emails, hvis vi kan bygge et system uden brug af passwords vil det øge sikkerheden væsentligt.

Hvis vi f.eks. kan bruge two-factor authentifiation i form af email, sms eller telefonopkald så øger vi sikkerheden eksponentielt. Forestil dig at blive ringet op af en person der kender dig og blive spurgt om du er ved at logge ind på din webmail, hvergang du logger på. Personen kender din stemme og kender en række detaljer om dig. Så hvis personen ikke er sikker på stemmen bliver du spurgt om ting som farven på din bil, eller antallet af børn – eller lign.

Det giver sig selv at gør det meget sværere at omgå sikkerheden, men samtidig er det også lidt kluntet at skulle blive ringet op 10 gange om dagen – så lige mht. webmail er det måske ikke det smarteste, med mindre selvfølgelig du lægger en cookie på brugerens computer og lader telefonopkaldet gælde for lige netop dén computer i et bestemt antal dage, og i denne periode kan brugeren logge ind kun med sit password.

Telefonopkald af en personlig bekendt er måske i overkanten til langt de fleste applikationer, men SMS Verifikation er idag let tilgængeligt og billigt at implementere.

6. Anvend autogenererede passwords

Enkelte steder er det upraktisk at skifte passwords hele tiden og samtidig er det praktisk at kunne oplyse brugeren om sit password, det er f.eks. tilfældet ifht. webhosting hvor du har databaser og email konti der er indtastet flere forskellige steder.

Det er bestemt ikke optimalt men i mange situationer er det den udvej man rent administrativt har valgt, og derfor kan det give mening af opbevare passwords.

Til den slags konti skal du bruge autogenererede passwords sådan at du ikke risikere at kunden selv bruger sin dankort kode eller password til sin netbank, det skal være et unikt genereret tokken som kun bruges til den ene ting, du kan f.eks. bruge http://www.sikkeradgangskode.dk

Derudover anbefaler jeg at kombinere den type adgang med en ekstra for for kontrol, f.eks. logning af tilgang, ip adresse blokering eller lign.

Epilog

Er vi i mål nu? Nej … på ingen måde, men vi er godt igang. Hvis alle ovenstående punkter er nye for dig, tillykke, så er du en af de få der laver tingene ordentligt første gang.

Jeg har selv været ude for at må tage genveje på grund af deadlines eller nærige chefer, og har også selv været den der måtte ryde op efter det var gået galt.

Det koster som regel mere at ryde op når det ér gået galt, end det ville have kostet at gøre det rigtigt fra starten af og jeg vil også gerne understrege at det langt fra altid er programmørens skyld. Ligeså ofte er det projektlederen, direktøren eller marketingsafdelingen der stiller krav om at det f.eks. skal være muligt at oplyse kunden sit password.

 

2 Replies to “Webudvikling: Sikker håndtering as passwords”

  1. God post 😉
    Men det er lidt sjovt at du linker til http://www.sikkeradgangskode.dk som går stik imod det xkcd billede i toppen 😉 og at de passwords den generere kun er 8 tegn og kun alphanumeric.
    Det er nok nogen passwords jeg ikke ville definere som sikre 😉

    Mvh
    Martin Dilling-Hansen

  2. Hej Martin
    De passwords som sikkeradgangskode.dk generere er sikre nok, forstået på den måde at jeg har set selv erfarne webudviklere lave koder der hedder “1234” eller “dinmor” … og her snakker vi altså sekunder for at bruteforce.

    8 cifre alphanumeric kombineret med en sikker loginform der ikke tillader dig et ubegrænset antal logins er sikker til de fleste usecases … men nej, passphrase til min pgp nøgle er også væsentligt længere og bruger væsentlig flere tegn-typer, de fleste af mine servere tilgår jeg med en ssh nøgle.

    Dit script er bestemt ikke dumt, selvom jeg nok ville foretrække længere ordlister 🙂

Comments are closed.