niet meer mogen inloggen
Pagina: « vorige 1 2 3 4 volgende »
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
- controleren of ip al in die tabel staat
- zo ja:
- controleren of het nodig is om te wachten
- zo ja: geef melding voor wachten
- zo nee:
- geef inlogscherm weer
- als inlogformulier gesubmit is
- de tijd van inlog veranderen naar nu
- counter 1 omhoog gooien
- controleren of wachtwoord + naam goed is
- zo ja: verwijder rij uit tabel
- door laten gaan naar beveiligde gedeelte
- zo nee:
- inlogformulier laten zien
- zo nee:
- geef inlogscherm weer
- als formulier gesubmit is:
- ip invoeren + de tijd van inlog
- counter in tabel 1 omhoog gooien
- controleren of wachtwoord + inlognaam goed is
- zo ja:
- verwijder de rij uit tabel
- door laten gaan naar beveiligde gedeelte
- zo nee:
- inlogformulier laten zien
- zo ja:
- controleren of het nodig is om te wachten
- zo ja: geef melding voor wachten
- zo nee:
- geef inlogscherm weer
- als inlogformulier gesubmit is
- de tijd van inlog veranderen naar nu
- counter 1 omhoog gooien
- controleren of wachtwoord + naam goed is
- zo ja: verwijder rij uit tabel
- door laten gaan naar beveiligde gedeelte
- zo nee:
- inlogformulier laten zien
- zo nee:
- geef inlogscherm weer
- als formulier gesubmit is:
- ip invoeren + de tijd van inlog
- counter in tabel 1 omhoog gooien
- controleren of wachtwoord + inlognaam goed is
- zo ja:
- verwijder de rij uit tabel
- door laten gaan naar beveiligde gedeelte
- zo nee:
- inlogformulier laten zien
En daarvoor heb ik de volgende sql tabel:
Code (php)
1
2
3
2
3
id | ip | counter | datum
-----------------------------------------------------------
int(11) | varchar(255) | int(3) | datetime
-----------------------------------------------------------
int(11) | varchar(255) | int(3) | datetime
En zo controleer ik of de tijd al klaar is:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?php
$sSql = "
SELECT
*
FROM
logintijd
WHERE
ip = '" . $ip . "'
AND
(datum + INTERVAL 15 MINUTE) < NOW()
";
if ( !$rRes = mysql_query ( $sSql ) )
{
// Foutmelding geven
}
else
{
if ( mysql_num_rows ( $rRes ) )
{
// Gebruiker mag niet inloggen
}
else
{
// Gebruiker mag inloggen
}
}
?>
$sSql = "
SELECT
*
FROM
logintijd
WHERE
ip = '" . $ip . "'
AND
(datum + INTERVAL 15 MINUTE) < NOW()
";
if ( !$rRes = mysql_query ( $sSql ) )
{
// Foutmelding geven
}
else
{
if ( mysql_num_rows ( $rRes ) )
{
// Gebruiker mag niet inloggen
}
else
{
// Gebruiker mag inloggen
}
}
?>
Ik kan het helaas nu niet zelf uitproberen (server ed is down). Dus vraag ik maar: kan dit zo kloppen?
En dat verhaal klopt vast ook wel (Y)
bij foute login:
$_SESSION['wronglogins']['trys']+= 1;
$_SESSION['wronglogins']['time'] = time();
loginform:
if(isset($_SESSION['wronglogins']) && $_SESSION['wronglogins']['trys'] >= 10) {
echo 'je mag niet inloggen';
} else {
//formulier
}
alleen nog even controle inbouwen voor de tijd (al kleine hint meegegeven)
Quote:
Nadeel van sessies is vaak dat je geen/minder controle hebt over wanneer ze verlopen. Soms is het al zo dat een sessie verloopt bij het afsluiten van de browser zodat de gebruiker daarna dus weer kan proberen in te loggen. Dat lijkt me niet echt gewenst...werken sessies niet meer?
@Jordi: waarom zou je telkens met 1 record in de database werken? Als je nu voor elke inlogpoging gewoon een nieuw records aanmaakt, kun je aan de hand van al die records wel bepalen of een gebruiker te vaak heeft geprobeerd in te loggen.
Sla dus bijvoorbeeld het ip, het tijdstip van de poging, en of de poging wel/niet gelukt is op in zo'n record. Vervolgens kun je met een eenvoudige SELECT query dan wel achterhalen hoe vaak een gebruiker achter elkaar binnen een bepaalde tijd een gebruiker in mislukte inlogpoging gedaan heeft...
@Blanche, zou ik kunnen doen inderdaad, maar ik ben nu toch al bezig met het idee dat ik hierbovenaan heb 'gepresenteerd'. Als dit toch niet lukt, zal ik jouw idee proberen.
Thx allemaal ;)
Dit is een van de dingen waar je met dit soort toepassingen over na moet denken...
Maar nu je het zo zegt, ik had er inderdaad nog niet aan gedacht. Maar volgens mij is dit niet mogelijk als ik dat zo bekijk... Het kan dan wel iets met cookies/sessions gaan doen, maar dan heeft die andere persoon er dus ook niks aan.
Quote:
Je hebt het over 15 minuten niet in kunnen loggen. Dat is lijkt mij toch redelijk blokkeren van de inlogmogelijkheid. Als je dat per ip-adres doet, dupeer je dus iedereen met hetzelfde ip-adres. Denk bijvoorbeeld aan bedrijfsnetwerken waarbij vaak 1 extern ip-adres gebruikt wordt.Het gaat in dit geval om een klantensysteem en er komt niet blokkeer systeem oid bij.
De situatie dat twee mensen met hetzelfde ip inloggen is helemaal niet uitzonderlijk. Bij mij op het werk zitten twintig mensen aan de pc met allemaal hetzelfde externe ip-adres.
De CAPTCHA kan je dan of globaal doen (dus controleren op IP) of per gebruiker (zodat het slachtoffer altijd 'beschermd' is, ook als de aanvaller een dynamisch IP / proxy heeft).
Maar ik zal eerst maar even een goede captcha zoeken, ik kan namelijk helemaal niks met plaatjes maken met php (nja, ik kan wel iets, maar een goede capcha niet)
Edit:
Ik heb aardig snel een goede gevonden, misschien wel een beetje kinderlijk. Maar dat maakt mij niet uit :P
http://phphulp.jorendewit.nl/view/43/
http://phphulp.jorendewit.nl/view/43/
Edit:
Ik zal nu ook maar gewoon dat idee met de hele tijd een rij invoeren per ip :). Is in deze situatie wel wat makkelijker :)
Ik zal nu ook maar gewoon dat idee met de hele tijd een rij invoeren per ip :). Is in deze situatie wel wat makkelijker :)
Edit:
Alweer edit :P..
Ik denk niet dat die captcha helemaal goed is, er word namelijk heeltijd een ander plaatje neergezet. Dan kan iemand ook wel zien van: oh, dat is 5.png .. ah, dat is dus een koe oid. Of oh, dat is 4.png .. dat is dus een kip. Of denk ik nu helemaal verkeerd ??
Alweer edit :P..
Ik denk niet dat die captcha helemaal goed is, er word namelijk heeltijd een ander plaatje neergezet. Dan kan iemand ook wel zien van: oh, dat is 5.png .. ah, dat is dus een koe oid. Of oh, dat is 4.png .. dat is dus een kip. Of denk ik nu helemaal verkeerd ??
Gewijzigd op 01/01/1970 01:00:00 door J A
Ik heb nu ervoor gezorgt dat dat plaatje in een file word gezet ipv dat die [nummer].png word weergegeven. Maar nu is hij niet meer doorzichtig, heeft er iemand verstand van GD bij php ??
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Voorbeeld: http://jordi.frih.net/KlantenSysteem/includes/captcha.php
Je gaat dus met een jpg aan de slag ipv een png... een jpg kan nooit doorzichtig worden
Quote:
En bot kan dus niet verzinnen dat de een een 'koe' en de ander een 'kip' is of andersom. Vandaar dat het tegen bots wel werkt maar tegen gebruikers niet.Dan kan iemand ook wel zien van: oh, dat is 5.png .. ah, dat is dus een koe oid. Of oh, dat is 4.png .. dat is dus een kip.
Quote:
Dat lijkt mij dus wel. Het is hoogstirritant als je een website nodig hebt en je moet 15 minuten wachten voordat je erop kunt. Weet je wel wat 15 minuten van de baas z'n tijd kost :-POok al denk ik niet dat het heel erg is voor een bedrijfje met iedereen hetzelfde ip om een kwartiertje te wachten.
Kortom, je zult toch echt met een andere oplossing moeten komen. Wellicht dat een sessie icm een cookie wellicht de beste (gebruiksvriendelijkste) oplossing is.
Quote:
Image '.$_SESSION['key'].'.jpg
Je gaat dus met een jpg aan de slag ipv een png... een jpg kan nooit doorzichtig worden
Je gaat dus met een jpg aan de slag ipv een png... een jpg kan nooit doorzichtig worden
Dat is een typfoutje en dat is gewoon tekst die word weergegeven als het plaatje niet is gevonden. Dat heeft dus niets te maken met het plaatje zelf.
@Blanche, die oplossing van sessie en cookie heb je zelf een paar posts hierboven eigenlijk afgekeurd :P
Quote:
Nadeel van sessies is vaak dat je geen/minder controle hebt over wanneer ze verlopen. Soms is het al zo dat een sessie verloopt bij het afsluiten van de browser zodat de gebruiker daarna dus weer kan proberen in te loggen. Dat lijkt me niet echt gewenst...
Die captcha is nu ik erover nadenk maar half werk, als een persoon het 10 keer fout heeft, moet de persoon gewoon een captcha invullen. Maar de persoon kan natuurlijk zelf wel die captcha achterhalen.
Maar het is wel een goede beveiliging voor brute force.
Dit word dus moeilijk :P
Gewijzigd op 01/01/1970 01:00:00 door J A
Jordi schreef op 24.04.2008 17:04:
Nee, ik heb gebruik van enkel sessies voor dit doel afgeraden en dat doe ik nog steeds. @Blanche, die oplossing van sessie en cookie heb je zelf een paar posts hierboven eigenlijk afgekeurd :P
Met een cookie zou je echter kunnen ondervangen dat de sessie mogelijk niet meer beschikbaar is als de browser afgesloten wordt, de cookie blijft dat namelijk wel.
Is er dan echt helemaal geen goede oplossing zonder cookies te gebruiken ??
Wat is de reden dat je absoluut geen cookies wilt gebruiken? Bijna elke website maakt daar wel gebruikt van, dus waarom zou jij dat niet willen?
Maar ik heb een oplossing bedacht.
Na 10x fout = cookies (5 min wachten)
Na 20x fout = captcha
Na 30x fout = ban (15 van ip)
Als het een echte gebruiker was, zou die allang op wachtwoord reset hebben gedrukt ...
Gewijzigd op 01/01/1970 01:00:00 door J A
Quote:
En geef daar dan eens argumenten voor? Cookies zijn niet per definitie onveilig, alleen de manier waarop ze gebruikt worden kan onveilig zijn...k vind cookies onveilig :)