[Alg / Best practise] Inloggen website

[PolarBear]

Ik zie vaak in P&G login pagina's voor websites en ze zien er niet allemaal even veilig uit. Daarom dit topic over de do's en don'ts van inlog pagina's.

Zelf programeer ik in ASP.Net/VB.Net. Om het inloggen zo veilig mogelijk en zo foutbestendig mogelijk te maken doe ik het volgende:
- Passwords in de database altijd hashen in MD5 of SHA1;
- Geen SQL in de code maar een aanroep naar een stored procedure;
- Databasestring niet in de code maar in web.config;
- Loggen van mislukte login attempts;
- Valideren gebruikte tekens in de invoervelden.

Nog meer nuttige tips voor inlog pagina's ?

[LauPro]

Password hashen naar MD5 is niet veiliger hor, het enige veiligere wat er aan is dat je het wachtwoord van de user beschermt, maar voor jou heeft het verder geen prioriteit lijkt me (als iemand bij je database kan komen kan hij ook wel je login-script omzeilen).

[Eskimootje]

LauPro schreef op 01 March 2003 @ 14:37:
Password hashen naar MD5 is niet veiliger hor, het enige veiligere wat er aan is dat je het wachtwoord van de user beschermt, maar voor jou heeft het verder geen prioriteit lijkt me (als iemand bij je database kan komen kan hij ook wel je login-script omzeilen).

Mwah als ze in je database zitten hebben ze dan meteen alle paswoorden. En aangezien ze een paswoord meestal voor meer dan een site gebruiken zou ik het gewoon lekker hashen.

[kvdveer]

PolarBear schreef op 01 March 2003 @ 14:33:
Ik zie vaak in P&G login pagina's voor websites en ze zien er niet allemaal even veilig uit. Daarom dit topic over de do's en don'ts van inlog pagina's.

Zelf programeer ik in ASP.Net/VB.Net. Om het inloggen zo veilig mogelijk en zo foutbestendig mogelijk te maken doe ik het volgende:
- Passwords in de database altijd hashen in MD5 of SHA1;
- Geen SQL in de code maar een aanroep naar een stored procedure;
- Databasestring niet in de code maar in web.config;
- Loggen van mislukte login attempts;
- Valideren gebruikte tekens in de invoervelden.

Nog meer nuttige tips voor inlog pagina's ?

Dat lijkt me een aardig complete lijst... Wat je nog niet genoemd hebt is hoe een sessie gemaakt wordt. De ingebouwde sessies van ASP en PHP zijn overigens buitengewoon geschikt en veilig.

Voor php/mysql ontkom je er niet aan om een directe sqlaanroep te doen. Waar je dan nog op moet letten, is dat je PHP de conversie naar MD5 of SHA1 door php laat uitvoeren, en niet door je database. Op die manier heb je er, als je het DB-verkeer aftapt, nog steeds niets aan. Een beveiligde verbinding met je DB en Client is natuurlijk ook zeer wenselijk.

Als je een MD5 of SHA1 hash ontwerpt, gebruik dan niet allen het wachtwoord, maar ook andere (onveranderlijke) gegevens zoals de username of registratiedatum. Op die manier is niet te zien welke gebruikers het zelfde wachtwoord hebben.

[Eskimootje]

Het allerbeste is natuurlijk als ze niet weten wat je doen. Maak gewoon iets creatiefs qua hash en inlogmethode en gebruik geen standaard dingen. Maak liever zelf iets dat is lastiger te kraken.

[LauPro]

Eskimootje schreef op 01 March 2003 @ 14:39:
[...]

Mwah als ze in je database zitten hebben ze dan meteen alle paswoorden. En aangezien ze een paswoord meestal voor meer dan een site gebruiken zou ik het gewoon lekker hashen.

offtopic:
Zei ik dat niet dan 'het enige veiligere wat er aan is dat je het wachtwoord van de user beschermt'

[Eskimootje]

LauPro schreef op 01 March 2003 @ 14:43:
[...]

offtopic:
Zei ik dat niet dan 'het enige veiligere wat er aan is dat je het wachtwoord van de user beschermt'

*srry* maar het is dus wel veiliger itt wat jij beweerde.

offtopic:
Je leest iets anders wat er bedoeld word, het inloggen veilig maken bestaat niet alleen uit de beveiliging van jouw pagina maar ook van de gegevens van de gebruikers.

[ Voor 27% gewijzigd door Eskimootje op 01-03-2003 14:54 ]

[LauPro]

Eskimootje schreef op 01 March 2003 @ 14:45:
[...]

*srry* maar het is dus wel veiliger itt wat jij beweerde.

offtopic:
'Om het inloggen zo veilig mogelijk en zo foutbestendig mogelijk te maken' zegt de TS, lijkt me dus dat het alleen om zijn login-gedeelte gaat

[gorgi_19]

PolarBear schreef op 01 maart 2003 @ 14:33:
Ik zie vaak in P&G login pagina's voor websites en ze zien er niet allemaal even veilig uit. Daarom dit topic over de do's en don'ts van inlog pagina's.

Zelf programeer ik in ASP.Net/VB.Net. Om het inloggen zo veilig mogelijk en zo foutbestendig mogelijk te maken doe ik het volgende:
- Passwords in de database altijd hashen in MD5 of SHA1;
- Geen SQL in de code maar een aanroep naar een stored procedure;
- Databasestring niet in de code maar in web.config;
- Loggen van mislukte login attempts;
- Valideren gebruikte tekens in de invoervelden.

Nog meer nuttige tips voor inlog pagina's ?

1e. Is vooral handig mocht je database gehacked worden, zodat je wachtwoorden niet direct op straat liggen. Echter, je kan dit nog doen icm een password policy.
2e. In zijn algemeenheid denk ik dat je SQL Injection attacks bedoeld.
3e. opslaan in web.config heeft niets met een inlogpagina te maken, maar meer met de reusability. Mocht je een connectionstring moeten wijzigen, dan hoef je geen nieuwe dll neer te zetten.
4e. In combinatie met een IPcheck. Verder kan je na 10 inlogpogingen een account op 'locked' zetten voor een x aantal minuten. Op deze manier voorkom je brute force attacks.
5e. Geldt ook niet specifiek voor inlogpagina's, maar gaat meer uit van het principe: vertrouw nooit de input van users.

Verder: ASP.Net heeft al een ingebouwd inlogmechanisme voor Forms authentication. Je kan eens kijken naar Role Based Security en het opslaan van de inlognaam / inlogcode / inlogID, waarna je hem uit de context.current.user.identity.name kan uitlezen.

[PolarBear]

kvdveer schreef op 01 March 2003 @ 14:40:
[...]

Dat lijkt me een aardig complete lijst... Wat je nog niet genoemd hebt is hoe een sessie gemaakt wordt. De ingebouwde sessies van ASP en PHP zijn overigens buitengewoon geschikt en veilig.

Ik gebruik de Forms Authentication van .Net. Werkt prima.

LauPro schreef op 01 March 2003 @ 14:37:
Password hashen naar MD5 is niet veiliger hor, het enige veiligere wat er aan is dat je het wachtwoord van de user beschermt, maar voor jou heeft het verder geen prioriteit lijkt me (als iemand bij je database kan komen kan hij ook wel je login-script omzeilen).

Het is ook meer bedoelt om de wachtwoorden uit handen te houden van onbevoegden. Men kan in ieder geval niet de wachtwoorden van gebruikers achterhalen, dat vinden de meeste gebruikers wel fijn.

gorgi_19 schreef op 01 maart 2003 @ 14:55:
[...]

1e. Is vooral handig mocht je database gehacked worden, zodat je wachtwoorden niet direct op straat liggen. Echter, je kan dit nog doen icm een password policy.

Het gaat mij niet alleen om veiligheid. Zie ook hierboven.

4e. In combinatie met een IPcheck. Verder kan je na 10 inlogpogingen een account op 'locked' zetten voor een x aantal minuten. Op deze manier voorkom je brute force attacks.

Beter, waarik mee bezig ben, is ook naar de username kijken. Zodat foutieve logins vanaf hetzelfde ip, en verschillende foutieve logins van verschillende IP's (proxies) worden afgevangen.

[ Voor 28% gewijzigd door PolarBear op 01-03-2003 15:00 . Reden: Nog een quote >:) ]

[whoami]

gorgi_19 schreef op 01 March 2003 @ 14:55:
[...]

3e. opslaan in web.config heeft niets met een inlogpagina te maken, maar meer met de reusability. Mocht je een connectionstring moeten wijzigen, dan hoef je geen nieuwe dll neer te zetten.

Reuseability, gemak, en toch ook wel een beetje beveiliging. Normaal gezien kan je als bezoeker op die manier nooit aan de connectie-string geraken.

[gorgi_19]

whoami schreef op 01 March 2003 @ 16:12:

[...]


Reuseability, gemak, en toch ook wel een beetje beveiliging. Normaal gezien kan je als bezoeker op die manier nooit aan de connectie-string geraken.

1e en 2e ben ik met je eens. Echter, hoe kan een bezoeker anders je connectionstring zien als je hem in je code-behind meecompileert? De .dll kan hij immers toch niet downloaden?

[whoami]

gorgi_19 schreef op 01 March 2003 @ 16:39:
[...]

1e en 2e ben ik met je eens. Echter, hoe kan een bezoeker anders je connectionstring zien als je hem in je code-behind meecompileert? De .dll kan hij immers toch niet downloaden?

Ik heb me laten vertellen dat, als je je connectiestring bv. in een sessie-object bewaart, en als je applicatie crashed, het zou kunnen gebeuren dat die connectiestring naar het scherm wordt geprint.

[gorgi_19]

whoami schreef op 01 March 2003 @ 16:41:

[...]


Ik heb me laten vertellen dat, als je je connectiestring bv. in een sessie-object bewaart, en als je applicatie crashed, het zou kunnen gebeuren dat die connectiestring naar het scherm wordt geprint.

Connectionstring moet je imho nooit in een session-object bewaren. Ik heb ook nergens gezien dat ze dat wel doen.

Ik doelde meer op bijvoorbeeld de voorbeelden uit de quickstart van ASP.Net:
Uit http://samples.gotdotnet....=CS\datagrid1.aspx&font=3

C#:

SqlConnection myConnection = new SqlConnection("server=(local)\\NetSDK;database=pubs;Trusted_Connection=yes");
SqlDataAdapter myCommand = new SqlDataAdapter("select * from Authors", myConnection);

Hier wordt de connectionstring er hard in gezet. Bij standaard instellingen (tracing uit en standaard foutmelding) hoor je de connectionstring dan niet te zien.

Wel blijft geldig dat de onderhoudbaarheid lastiger is. Echter, je kan ook een config.cs maken en deze meecompileren. De connectionstring zet je dan neer als variabele, welke in de rest van de bestanden ingelezen wordt.

[ Voor 14% gewijzigd door gorgi_19 op 01-03-2003 16:47 ]

[Treenaks]

Ik sla altijd netjes SHA1 hashes op in een database, en laat mn webserver de authenticatie doen (apache, mod_auth_pgsql, dan krijg je zo'n "Username" windowtje van je browser)... werkt als een trein, en je weet als programma zeker dat een user geauthenticeerd is (REMOTE_USER environment variabele). En je hoeft niet onnodig met sessies te gaan kl*ten

Eventueel kan je ook wel iets maken in Perl (met DBI kan je heel mooi SQL escapes voorkomen met query templates) maar dat blijf ik eng vinden.