login script, spørsmål om sikkerhet

[hockey500]

Hei hei,

jeg satte nettopp sammen et enkel login-script, men jeg har liten peiling på sikkerhet. Det jeg lurte på var rett og slett om dette var sikkert (nok), eller om jeg burde gjøre noen endringer. Scriptet er redigert for å sette det hele sammen til en fil, bare for denne anledningen.

Sånn ser scriptet ut. Jeg la den på ekstern server for syntax highlighting. Tabellen som brukes er veldig enkel, ser sånn ut:

mysql> describe loginscript_users;
+----------+--------------+------+-----+---------+----------------+
| Field    | Type         | Null | Key | Default | Extra          |
+----------+--------------+------+-----+---------+----------------+
| id       | int(11)      | NO   | PRI | NULL    | auto_increment |
| username | varchar(255) | NO   |     | NULL    |                |
| password | varchar(255) | NO   |     | NULL    |                |
+----------+--------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

 

Hva burde endres i scriptet, noe jeg burde gjøre totalt annerledes?

Endret 13. juni 2006 av hockey500

[Peter]

password trenger strengt tatt ikke være varchar, da du burde hashe alle passord i databasen.

Dette kan gjøre med f.eks. md5() eller sha1(), eventuelt kan du bruke den innebygde funksjonen password() i mysql, men den anbefales ikke for tidlige versjoner av mysql.

 

Fordelene ved hashing er flere:

 

Først om fremst er det irreversibelt, og dette er hovedargumentet. Dvs. at det ikke finnes noen enkel vei å finne frem til klartekst-passordet fra en skikkelig hashet streng. Det betyr at selv om noen skulle få tak i hele databasen din, så vil de ikke kunne lese ut passordet til brukerene. (Det _er_ mulig, men krever en del mer arbeid)

 

For det andre er hasher alltid av en gitt lengde. md5 = 32 tegn, sha1 = 40 tegn, password() = 16 tegn, du kan derfor med sikkerhet sette en fast størrelse på feltet i databasen.

 

 

Når du legger brukeren inn i databasen, sørger du for å legge inn hashen til passordet brukeren valgte, og når du skal logge inn en bruker, hasher du passordet brukeren skrev inn og sammenligner med hashen du har i databasen tidligere.

Endret 13. juni 2006 av Nazgul

[Krisse]

Alle passord må være VARCHAR, fordi det ikke finnes en egen datatype som heter f.eks. MD5. MD5 er bare funksjonen du må kalle når du skal hashe passordet i databasen. Men jeg har redusert størrelsen på brukernavn til 50 og passord til 32.

 

Når du legger brukeren inn i databasen, sørger du for å legge inn hashen til passordet brukeren valgte, og når du skal logge inn en bruker, hasher du passordet brukeren skrev inn og sammenligner med hashen du har i databasen tidligere.

Hvis du har sett på koden har du nok merket at det er slik jeg gjør det.

 

Det jeg lurte mest på er hvor sikkert dette er med tanke på XSS, SQL injections, session hijacking og lignende. Og hvor lang tid tar det å brute-force passordet når jeg bruker en salt-string på 20 tegn + passordet? altså rundt 25-30 tegn, både tall og bokstaver. Burde vel ikke være gjort på noen timer det?

 

EDIT: brukte søstra mi sin laptop uten å tenke over at jeg har feil bruker her ja dette er trådstarter, for de som ikke skjønte det.

Endret 13. juni 2006 av Krisse

[Peter]

Bruk CHAR(32) for md5

VARCHAR er av variabel størrelse, og det trenger du ikke da alle md5-hasher er 32 bytes.

 

 

EDIT:

Så forresten ikke at du hadde lagt ut skriptet.

Endret 13. juni 2006 av Nazgul

[hockey500]

så forskjellen på VARCHAR(32) og CHAR(32) er? Du kan jo sette størrelse på begge

[ZoRaC]

Ser da rimelig grei ut den, ingen direkte "farer"/sikkerhetshull som jeg kan se.

 

Å salte passordet beskytter mot bruteforce angrep på MD5-hashen, om noen skulle greie å få fatt i den, men den beskytter jo ikke mot bruteforce-angrep på innloggings-skjemaet ditt.

 

Det jeg gjør er å lagre hvert feilede innlogginsforsøk i en tabell i databasen og stenger pålogging for bruker x i 15 min etter 3 feil-innlogginger og stenger i tillegg for pålogging fra IP y etter 5 feil fra samme IP. Det for å sikre at en angriper ikke kan prøve et nytt brukernavn når det er første er "sperret".

 

I tillegg låser jeg hele siden i 15 min om det er mer enn 20 feil-innlogginger i løpet av 3 min, uavhengig av brukernavn/IP som er brukt. Dette for å hindre angrep via forskjellige proxyer (som vil gjøre IP-sperren min ubrukelig).

[hockey500]

Mens vanlig programmer kanskje klarer å sjekke et par millioner kombinasjoner pr. sekund, kan det vel ikke gå stort raskere enn en kombinasjon eller to i sekundet når man prøver å brute-force selve skjemaet på siden, for siden må jo kalles opp igjen for hvert eneste forsøk? det er vel ingen stor risiko? Men jeg kan alltids legge til en slik sperre ja.

[Peter]

så forskjellen på VARCHAR(32) og CHAR(32) er? Du kan jo sette størrelse på begge

6300961[/snapback]

VARCHAR har i variabel størrelse.

CHAR har fast størrelse.

Dvs. at VARCHAR(m) 0<= m

mens CHAR (m) m=m

 

For at VARCHAR skal kunne fungere, må feltet ha noe som angir lengden på feltet, dette krever én byte ekstra for hver tuppel.

På 1024 tupler vil du ha brukt en megabyte ekstra.

 

VAR*, *BLOB, *TEXT er de feltene som har variabel størrelse. Disse krever alt fra 1-4 bytes per tuppel for å angi lengden på feltet.

 

 

Alt dette står i manualen, bare å lese...

[ZoRaC]

Er nok ingen stor risiko nei, men "better safe than sorry"... hehe

[hockey500]

Men ellers ingen som finner noen sikkerhetshull/ting som kan forbedres i scriptet?

 

Scriptet ligger her og tabellen ser slik ut nå:

mysql> describe loginscript_users;
+----------+-------------+------+-----+---------+----------------+
| Field    | Type        | Null | Key | Default | Extra          |
+----------+-------------+------+-----+---------+----------------+
| id       | int(11)     | NO   | PRI | NULL    | auto_increment |
| username | varchar(50) | NO   |     | NULL    |                |
| password | char(32)    | NO   |     | NULL    |                |
+----------+-------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

Endret 13. juni 2006 av hockey500