[php] beveiliging login

[Verwijderd]

Ik heb dankzei het vele lezen van allemaal topics op got een leuk login systeem verzonnen. Alleen nu is het probleem dat 1 de gebruiker de login/wachtwoord niet kan opslaan en 2 dat het systeem dat vanuit gaat dat bepaald probleem alleen door gebruikers op te lossen is, veel te simple.

Het werkt als volgt, de gebruiker heeft 3 gegevens (username/wachtwoord/beveiligingcode).

- Gebruiker vraag pagina op, sessie word aangemaakt (bij submit indien er geen sessie meer is geen login)
- Server genereerd 2 code's in de vorm van een image, een getal die de gebruiker mot optellen bij zijn beveiligingscode en moet invoeren met de knopen. (beveiliging tegen keyloggers oa).
- en een image met een string (verificatie code) die de gebruiker moet overtikken.

indien de gebruiker alle gegevens invoert, word van de code (beveiligingscode+gegenereert getal), verificatiecode, en wachtwoord een sha1 string gemaakt en dat gestuurd voor bevestiging.

Voordat er word gesubmit, word het wachtwoord, code en verificatiecode velden leeggemaakt.

Volgende link zie je een voorbeeld van de img


Ik zoek graag een oplossing om de optelsom probleem dat aan de gebruiker word voorgesteld te vervangen door iets nog simplers maar wel even effectief. Want bepaalde gebruikers hebben nog wel problemen met het optellen (hoe vreemd dat ook klinkt).

En bepaalde gebruikers willen niet steeds hun username/wachtwoord tikken, maar ik haal die natuurlijk leeg voordat ik submit. Hoe kan ik ervoor zorgen dat zij hun ww kunnen opslaan en ik niet het wachtwoord over het internet hoef te sturen

en als laatst, deze login kan helaas niet altijd via ssl gedaan worden, hoe kan ik zoeen systeem verbeteren?

[simon]

Mag ik vragen wat het nut is van een dergelijke beveiliging? Ik denk dat dit niet echt heel veel veiliger is. Je beveiligt nu maar op 1 punt... Zorg bijvoorbeeld dat die wachtwoorden eerst via JS gemd5t/sha't worden, en dan pas verzonden...

[CyberThijs]

Simon schreef op zaterdag 20 november 2004 @ 16:14:
Mag ik vragen wat het nut is van een dergelijke beveiliging? Ik denk dat dit niet echt heel veel veiliger is. Je beveiligt nu maar op 1 punt... Zorg bijvoorbeeld dat die wachtwoorden eerst via JS gemd5t/sha't worden, en dan pas verzonden...

indien de gebruiker alle gegevens invoert, word van de code (beveiligingscode+gegenereert getal), verificatiecode, en wachtwoord een sha1 string gemaakt en dat gestuurd voor bevestiging.

[simon]

thijswalc schreef op zaterdag 20 november 2004 @ 16:16:
[...]


[...]

Maar daarmee belicht je maar 1 kant van mijn post. Mijns insziens: als het echt zo veilig moet dan lijkt het me dat je er geld in zou kunnen steken en SSL fixen. Want imho wordt het er zo niet echt veiliger op.

Schijnveiligheid is nog gevaarlijker dan weinig veiligheid..

[Erkens]

Verwijderd schreef op zaterdag 20 november 2004 @ 16:12:
En bepaalde gebruikers willen niet steeds hun username/wachtwoord tikken, maar ik haal die natuurlijk leeg voordat ik submit. Hoe kan ik ervoor zorgen dat zij hun ww kunnen opslaan en ik niet het wachtwoord over het internet hoef te sturen

dat is de taak van de browser om een dergelijke service aan te bieden

[ixi]

Voor het onthouden van gebruikersnaam en wachtwoord kan je een checkboxje maken. Vervolgens plaats je een cookie met een hash erin.

Bij elke keer dat iemand op de site komt kijk je of de hash uit een cookie overeenkomt met je eigen tabel van hashes. Genereer dan een 'random' wachtwoord die ook door de validatie komt (voor slechts 1 keer natuurlijk).

Dit is 1 manier natuurlijk... zijn nog zat andere manieren.

[Xander]

Erkens schreef op zaterdag 20 november 2004 @ 16:21:
[...]

dat is de taak van de browser om een dergelijke service aan te bieden

Alleen lijkt me dat de meeste browsers dit niet meer doen als de inputvelden leeggemaakt worden voor het submitten?

[Erkens]

XanderH schreef op zaterdag 20 november 2004 @ 16:29:
[...]


Alleen lijkt me dat de meeste browsers dit niet meer doen als de inputvelden leeggemaakt worden voor het submitten?

dat zijn dan slechte browsers imo

[Verwijderd]

Ik noem maar een dwarsstraat, maar zou je niet het volgende kunnen doen:

In de db sla je het wachtwoord op als een normale Hash. Wanneer de gebruiker wil inloggen genereer je een zaai getal en genereer je de tweede hash. Dit is
nu een samengestelde hash van het orgineel in combinatie met je zaai getal. Deze
samengestelde hash zet je in een sessie variabele.
Dit zaai getal stuur je naar de browser en zet je in een hidden field.
Wanneer de gebruiker op inloggen klikt zal eerst de hash van gebruikersnaam en wachtwoord
gegenereerd worden, vervolgens genereer je de tweede hash met het zaai getal.
Deze hash stuur je naar de server. Je script controleert of beide hashes hetzelfde
zijn. Zo ja, inloggen is geslaagd, zo nee, inloggen is mislukt.

Dit lijkt mij een veilig systeem aangezien je bij elke login een nieuwe samengestelde hash genereerd. Wanneer een aanvaller dus de hash heeft, kan
hij de volgende keer niet opnieuw inloggen.

[Verwijderd]

thnx ixi, heb al een idee, ik zorg dat de gebruiker een hash opgeslagen krijg en dan alleen beveiligingscode en verificatie code meot invoeren.

@ Simon, ik bied een systeem aan aan de klant, en probeer het zo veilig mogelijk te maken, ook sll is te kraken als iemand een keylogger op systeem heeft. Dit systeem bied dus wel wat voordelen boven ssl, maar is absoluut niet geen vervanger van.

@Jorgen, in de database staat ook een hash van het wachtwoord!
alleen om een 2de hash te maken, gebruik ik een string (die de gebruiker van een image moet overtikken) en een combinatie van 2de getal (ook image) met zijn eigen beveiligingcode (die word dus nooit ingevoerd, alleen de som van 2 code's

EDIT: Ik had nog niet naar je reply gekeken Jorgen

[ Voor 34% gewijzigd door Verwijderd op 20-11-2004 16:41 ]

[Verwijderd]

Heb je uberhaupt naar mijn reply gekeken?

[Verwijderd]

Erkens schreef op zaterdag 20 november 2004 @ 16:33:
[...]

dat zijn dan slechte browsers imo

Helaas leven we in de wereld waarin we rekening moeten houden met slechte browser en beperkte mogelijkheden

voor mensen die intresse hebben in sourcecode: www.advany.com/LoginSecure.zip

(dit heb ik even uit mijn cms moeten strippen) en zitten ook stukken source in die ik van het web het gestript, helaas ben ik vergeten wat ik waar vandaan heb gehaald indien iemand iets van zichzelf ziet, mag hij of zij dat melden.

ik zou hier graag een discussie van willen maken of men vind of deze beveiligingen zin hebben? en of het beter kan?

[ Voor 16% gewijzigd door Verwijderd op 20-11-2004 16:53 ]

[Erkens]

Verwijderd schreef op zaterdag 20 november 2004 @ 16:52:
[...]


Helaas leven we in de wereld waarin we rekening moeten houden met slechte browser en beperkte mogelijkheden

true, echter die mensen willen wel veiligheid maar geen wachtwoorden invoeren, beetje krom als ik eerlijk moet zijn.

[Xander]

Verwijderd schreef op zaterdag 20 november 2004 @ 16:52:
[...]
ik zou hier graag een discussie van willen maken of men vind of deze beveiligingen zin hebben? en of het beter kan?

Ja, het heeft zin, voor de FBI ofzo...

Mja, serieus, ik vind het een leuk projectje... maar als beveiliging voor een CMS vind ik het een beetje zware overkill....

[Erkens]

XanderH schreef op zaterdag 20 november 2004 @ 17:01:
Mja, serieus, ik vind het een leuk projectje... maar als beveiliging voor een CMS vind ik het een beetje zware overkill....

overkill, tja, dat ligt aan de site lijkt me, voor een CMS van de locale punnikclub is het idd overkill, maar als je een CMS hebt voor bijvoorbeeld een groot bedrijf etc dan kan ik me dit wel voorstellen
Hoewel ik dan eerder SSL zou gebruiken, dit zijn eik wel erg veel handelingen voor een normale gebruiker.

[Verwijderd]

XanderH schreef op zaterdag 20 november 2004 @ 17:01:
[...]


Ja, het heeft zin, voor de FBI ofzo...

Mja, serieus, ik vind het een leuk projectje... maar als beveiliging voor een CMS vind ik het een beetje zware overkill....

ja, dat is natuurlijk een mening die elke klant ieder mag hebben. Ik implementeer gewoon aantal type beveilgingen, en klant kies de beveiliging die of zij wilt. En dat activeer je.

@ Erkens: er zijn natuurlijk meer redenen waarom je een betere beveiliging zou willen hebben. Niet elke klant kan eenvoudig kiezen voor SSL of vind dat te duur.

Ik heb ook aan zitten denken dat de procedure wel erg groot is. Maar wil dat oplossen door 1 week opslag van wachtwoord (exclusief het invoeren van beveiligingscode) aan te bieden.

@TormentoR: zou best kunnen, onze taal man is er nog niet over heengeweest

[ Voor 32% gewijzigd door Verwijderd op 20-11-2004 17:11 ]

[Akerboom]

offtopic:
zit wel een spelfout in je cms: "indien u gehackt wordt"

@Abdul Rahman: ok, maar ik dacht ik meld het even... staat zo slordig in een cms

[ Voor 59% gewijzigd door Akerboom op 20-11-2004 17:14 ]

[Erkens]

Verwijderd schreef op zaterdag 20 november 2004 @ 17:07:
@ Erkens: er zijn natuurlijk meer redenen waarom je een betere beveiliging zou willen hebben. Niet elke klant kan eenvoudig kiezen voor SSL of vind dat te duur.

je hoeft voor SSL echt geen duur certificaat te hebben, de gebruiker krijgt dan (eenmalig indien ze hem importeren) een venstertje te zien of ze het homemade certificaat ondersteunen, hoe duur kan dat zijn
Voor veiligheid is bijna nooit iets te duur lijkt me

TormentoR schreef op zaterdag 20 november 2004 @ 17:09:

offtopic:
zit wel een spelfout in je cms: "indien u gehackt wordt"

offtopic:
"Dit systeem is allen toegangelijk.......

[ Voor 20% gewijzigd door Erkens op 20-11-2004 17:14 ]

[simon]

Toch vraag ik me af waarom dit zo veilig zou zijn. Als je een kluis zwaar op de voordeur beveiligt, maar een zijwand vergeet kom je ook nergens... Daar zitten mijn grootste twijfels bij dit geheel

[Verwijderd]

Erkens schreef op zaterdag 20 november 2004 @ 17:13:
[...]

je hoeft voor SSL echt geen duur certificaat te hebben, de gebruiker krijgt dan (eenmalig indien ze hem importeren) een venstertje te zien of ze het homemade certificaat ondersteunen, hoe duur kan dat zijn
Voor veiligheid is bijna nooit iets te duur lijkt me

ja, dat is ook zo, maja, keuze aan de klant zelf, maar niemand heeft echt idee'en het veiliger zou kunnen?

@ TormentoR: THNX , zal het doorvoeren.

@ Simon: kun je dit toelichten?

[ Voor 4% gewijzigd door Verwijderd op 20-11-2004 17:17 ]

[Erkens]

Verwijderd schreef op zaterdag 20 november 2004 @ 17:16:
@ Simon: kun je dit toelichten?

lijkt me opzich niet zo moeiljik
als je eenmaal binnen bent en je per ongeluk een raam open zet kan alsnog iedereen naar binnen: ReactID misbruik en de gevolgen

Nu in normale taal: als je een session id kan kapen maakt de login niks uit

[Verwijderd]

Erkens schreef op zaterdag 20 november 2004 @ 17:21:
[...]

lijkt me opzich niet zo moeiljik
als je eenmaal binnen bent en je per ongeluk een raam open zet kan alsnog iedereen naar binnen: ReactID misbruik en de gevolgen

Nu in normale taal: als je een session id kan kapen maakt de login niks uit

Klopt, heb ook idee'en om wat andere beveiligingen in te bouwen, ip & browser check (en als dat mislukt, logout).

maja, achter een proxy heeft dat weinig zin.

Zo wie zo geef mijn cms niet zo snel sessie id's weg, blijft in de cookie, maargoed.

[ Voor 4% gewijzigd door Verwijderd op 20-11-2004 17:25 ]

[Erkens]

Verwijderd schreef op zaterdag 20 november 2004 @ 17:25:
[...]


Klopt, heb ook idee'en om wat andere beveiligingen in te bouwen, ip & browser check (en als dat mislukt, logout).

maja, achter een proxy heeft dat weinig zin.

Zo wie zo geef mijn cms niet zo snel sessie id's weg, blijft in de cookie, maargoed.

cookies zijn ook te sniffen secure krijg je dat niet
ip check kan soms onhandig zijn, maar dat ligt aan je doelgroep, sommige mensen zitten idd achter een proxyserver die naar buiten toe steeds een ander IP geven

[AaroN]

Denk eraan dat je ook de tijd in die hash verwerkt. Zo heeft een eventuele spoofer ook geen succes. Aangezien je de hash steeds aanpast.

[Verwijderd]

AaroN schreef op zaterdag 20 november 2004 @ 17:31:
Denk eraan dat je ook de tijd in die hash verwerkt. Zo heeft een eventuele spoofer ook geen succes. Aangezien je de hash steeds aanpast.

Als je de tijd erin verwerkt, kan een aanvaller toch gewoon ook de tijd erin verwerken.

Je moet dus een random zaai getal nemen, zoals ik al in een eerdere reply heb proberen duidelijk te maken.

Ik vind het alleen nogal dikke overkill dit hele gebeuren. Een goede simpele login maken is niet zo heel moeilijk. Daar hoef je *echt* niet 14 ranzige lees-plaatjes-uit en "beveiligingscode" checks voor in te bouwen

[Verwijderd]

Erkens schreef op zaterdag 20 november 2004 @ 17:28:
[...]

cookies zijn ook te sniffen secure krijg je dat niet
ip check kan soms onhandig zijn, maar dat ligt aan je doelgroep, sommige mensen zitten idd achter een proxyserver die naar buiten toe steeds een ander IP geven

ja, ik zit net te kijken waarop je op kan checken of het de zelfde gebruiker is:

Ik kom op de volgende lijst waarop ik zou kunnen controleren

ip (optioneel)

dit lijkt me niet dat het verandert
HTTP_USER_AGENT, HTTP_ACCEPT, HTTP_ACCEPT_ENCODING, HTTP_CONNECTION, HTTP_KEEP_ALIVE

Dit bijna nooit
HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT_CHARSET

En dit zal ik dan moeten bijhouden, of het klopt elke keer
REFERER

Dit zou toch iets meer zekerheid kunnen bieden? verder kun je weinig over de gebruiker te weten komen of heb ik het mis?

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:07:
[...]

Als je de tijd erin verwerkt, kan een aanvaller toch gewoon ook de tijd erin verwerken.

Je moet dus een random zaai getal nemen, zoals ik al in een eerdere reply heb proberen duidelijk te maken.

Ik vind het alleen nogal dikke overkill dit hele gebeuren. Een goede simpele login maken is niet zo heel moeilijk. Daar hoef je *echt* niet 14 ranzige lees-plaatjes-uit en "beveiligingscode" checks voor in te bouwen

Zou je het erg vinden of we de discussie of het wel of geen overkill is een andere keer voeren? Anders krijg je een wellus niettus situatie.

Het nadeel van zaaigetal is dat het plain het netwerk word overgestuurd. Ik zorg door middel van 2 (niet 14) image's, en een rekensom dat men het iets moeilijker krijgt.

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:09:
[...]

dit lijkt me niet dat het verandert
HTTP_USER_AGENT, HTTP_ACCEPT, HTTP_ACCEPT_ENCODING, HTTP_CONNECTION, HTTP_KEEP_ALIVE

...

Als één ding wel simpel te faken is met een programma al proxo, dan zijn het deze wel...

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:11:
[...]


Zou je het erg vinden of we de discussie of het wel of geen overkill is een andere keer voeren? Anders krijg je een wellus niettus situatie.

Het nadeel van zaaigetal is dat het plain het netwerk word overgestuurd. Ik zorg door middel van 2 (niet 14) image's, en een rekensom dat men het iets moeilijker krijgt.

Wat maakt het uit of een zaaigetal plain over het netwerk gestuurd wordt? Het gaat er toch om dat een aanvaller maar maximaal één keer kan inloggen met zijn afgevangen hash...
Een aanvaller kan toch ook gewoon de twee afbeeldingen afvangen en dan handmatig intikken?

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:12:
[...]


Als één ding wel simpel te faken is met een programma al proxo, dan zijn het deze wel...

het is meer het idee, want als iemand een sessie idee per ongeluk krijgt, dat hij of zei precies browsertype enz moet hebben om het te gebruiken. Anders word de sessie beeindigd. Het is natuurlijk niet muurdicht, maar weer een klein stukje beveiliging.

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:14:
[...]


Wat maakt het uit of een zaaigetal plain over het netwerk gestuurd wordt? Het gaat er toch om dat een aanvaller maar maximaal één keer kan inloggen met zijn afgevangen hash...
Een aanvaller kan toch ook gewoon de twee afbeeldingen afvangen en dan handmatig intikken?

1tje kan hij zo intikken (en hij moet natuurlijk deze request ook afvangen, zijn al weer 3), voor de andere heeft hij een deel van een code nodig.

[Verwijderd]

Wat dacht je van het volgende:

Zelfde verhaal als net, alleen genereer je van het zaaigetal nu een afbeelding, stuur je naar de browser. Gebruiker vult inloggegevens in, typt het zaaigetal over.
Scriptje genereerd hash van inloggegevens, tweedehash met zaaigetal en verstuurd die.
Dit lijkt mij imho de meest simpele manier om het veilig te krijgen. Al dat gemiemel met HTTP_ACCEPT blabla is nergens voor nodig. De situatie die ik hier beschrijf is
veilig.

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:22:
Wat dacht je van het volgende:

Zelfde verhaal als net, alleen genereer je van het zaaigetal nu een afbeelding, stuur je naar de browser. Gebruiker vult inloggegevens in, typt het zaaigetal over.
Scriptje genereerd hash van inloggegevens, tweedehash met zaaigetal en verstuurd die.
Dit lijkt mij imho de meest simpele manier om het veilig te krijgen. Al dat gemiemel met HTTP_ACCEPT blabla is nergens voor nodig. De situatie die ik hier beschrijf is
veilig.

tot iemand in de handen komt van de sessieID, magoed, daar gaan we niet uitkomen.

[Verwijderd]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:26:
[...]


tot iemand in de handen komt van de sessieID, magoed, daar gaan we niet uitkomen.

Dat probleem blijf je altijd houden...

[JochemK]

Even een meer algemene reply, maar op
http://www.phpfreakz.com staat een Webprogrammer's Hacking Guide waar redelijk veel algemene info in staat over hoe een website te beveiligen.

Doe er je voordeel mee zou ik zeggen

[Vold]

Zelf vind ik het erg onnozel die beveiliging die jij daar hebt, zelf word ik ook helemaal gek van dat soort dingen.. Wat ik zelf zou toepassen is bijvoorbeeld:

- Logica vragen ipv zinloos cijfersovertypen (welke kleur is oranje ?, Welke kleur heeft een sinasappel?, zijn natuurlijk betere voor te verzinnen )
- Bewust misleidende dingen inbouwen, een md5 string in een cookie zetten, dat bijvoorbeeld niet de md5 van een password is, maar md5 van een password + unieke code per gebruiker..

Hoop dat je er wat aan hebt !

[eghie]

Verwijderd schreef op zaterdag 20 november 2004 @ 18:26:
[...]


tot iemand in de handen komt van de sessieID, magoed, daar gaan we niet uitkomen.

Wat kan iemand allemaal, als hij je sessieID in handen krijgt

Voor echte beveiliging, zou ik dus die random getallen erin implenteren en dan nog een SSL verbinding eroverheen rossen, al kost je dat wel geld. Maar het is wel een stuk veiliger.

Maak trouwens op de achtergrond een random zaai getal aan of een GUID (ook "random") en sla die op in een variable op de server, waar de client niet bij kan komen en in een sessie variable of cookie. Sla deze waarde op, alleen tijdens de pageload van het login scherm. Als je dan ingelogd bent, kijk dan elke keer of er een waarde in staat en of die klopt. Dit is ook te hijacken, maar het maakt allemaal moeilijker.

Ik ben trouwens meer .NET aanhanger, ook met beveiliging. Vind dat Microsoft de beveiliging aardig goed heeft geregeld in .NET. Ik zal vanaaf of morgen aaf een Login systeempje bouwen, zo veilig mogelijk en dat project hier nier zetten, inclusief source. Dan mogen jullie proberen of je hem kunt hijacken, zonder de source aan te passen ofcourse.

[ Voor 18% gewijzigd door eghie op 22-11-2004 10:58 ]

[Verwijderd]

of je gebruikt gewoon md5 encryption

edit: of zeg ik nu weer wat doms

[ Voor 33% gewijzigd door Verwijderd op 22-11-2004 10:43 ]

[Gerco]

Verwijderd schreef op maandag 22 november 2004 @ 10:43:
of je gebruikt gewoon md5 encryption

edit: of zeg ik nu weer wat doms

Ja, je zegt iets doms md5 is geen encryptie, het is hashing. Het verschil is in een note(n?)dop dat hashing maar 1 kant op gaat. Als je er md5 van maakt kan het niet meer (makkelijk) terug (dat is het hele doel).

^{Dit naast het feit dat hij dat ook al doet...}

on topic:
Hoe zit het met je beveiliging als ik hier eenmaal doorheen ben ? Kan ik gewoon een cookie stelen van een gebruiker en daarmee verdersurfen (dus dit hele login scherm niet te zien krijgen). Zitten er gaten in de paginas die hierachter zitten ? Als ik een URL weet binnen je systeen, kan ik daar dan iets mee?

Bij een webapp heb je een hele grote anonymous attack surface (als je tenminste de webserver zelf niet de authenticatie laat doen), een attacker kan elke willekeurige pagina direct aanroepen, als dan alleen je login super veilig is, maar er zit een gat in een andere pagina, is je systeem nog even goed lek.

[ Voor 49% gewijzigd door Gerco op 22-11-2004 10:49 ]

[eghie]

Verwijderd schreef op maandag 22 november 2004 @ 10:43:
of je gebruikt gewoon md5 encryption

edit: of zeg ik nu weer wat doms

Ehhm, dom is wel een beetje overdreven, maar ik denk dat je een deel van dit topic niet goed heb begrepen dan. Ze hebben het in dit topic al over hashen gehad en zo ook de TS. Hij hashed zijn wachtwoord al enzo. Dat hashen kan onder andere MD5 zijn, maar ook SHA-1 bijv. Dus hij gebruikt al een soort van MD5 algoritme.

MD5 is namelijk een Hashing algoritme waarmee je dus alleen kunt "encrypten" en niet meer kunt "decrypten". Zo zijn er nog meer hashing alogritmen dan MD5. SHA-1 bijv, is ook een hashing algoritme. Die gebruikt de TS. Die is namelijk nieuwer en bevat meer mogelijkheden, dus ook iets veiliger tegen brute-force aanvallen.

[RwD]

Moet hij niet even op GoT zoeken naar challenge - response ?

(Das wat ik in de vluggigheid geloof dat Jurgen voorstelt)

[curry684]

eghie schreef op maandag 22 november 2004 @ 10:33:
[...]

Wat kan iemand allemaal, als hij je sessieID in handen krijgt

* curry684 wijst subtiel naar curry684 in "ReactID misbruik en de gevolgen"

[eghie]

curry684 schreef op maandag 22 november 2004 @ 12:34:
[...]

* curry684 wijst subtiel naar curry684 in "ReactID misbruik en de gevolgen"

* eghie geeft maar even aan dat hij dat gelezen heeft, maar toch bedankt

Maar ik vraag me af, wat iemand kan doen met die sessie id, maar dan de technische kant. In jouw bericht gaat het vooral om dit forum en is het vrij algemeen, maar kan je normaal bijv. ook sessie id's aan URL's koppelen. Of moet je dat inbouwen in je software

Ik weet dat je met een Sessie ID verder kunt gaan met je sessie, maar worden daarin bijv ook cookies meegenomen enzo. Zou je bijv. als je een sessie id van iemand hebt, gebruik kunnen maken van een webapplicatie die ook cookies nodig heeft in z'n inlogsysteem En krijg je daarmee ook al de sessie variablen die bij die sessie horen

[ Voor 5% gewijzigd door eghie op 22-11-2004 12:57 ]

[curry684]

eghie schreef op maandag 22 november 2004 @ 12:56:
[...]

* eghie geeft maar even aan dat hij dat gelezen heeft, maar toch bedankt

Maar ik vraag me af, wat iemand kan doen met die sessie id, maar dan de technische kant. In jouw bericht gaat het vooral om dit forum en is het vrij algemeen, maar kan je normaal bijv. ook sessie id's aan URL's koppelen. Of moet je dat inbouwen in je software

Je kunt met een gelekt ReactID ook een custom cookie bouwen, en standaard ASP.NET en PHP sessions werken ook gewoon met een lang ID en een unieke code in een cookie. SessionID hijacking = complete sessie onder controle en full impersonation, *tenzij* je ook IP-checks en locks doet.

En krijg je daarmee ook al de sessie variablen die bij die sessie horen

HTTP is stateless, dus de serverside session variables hangen alleen in een lookup table aan het sessionID/phpID/reactID/whateverID vast. Ja, je neemt echt *alles* over omdat de server het verschil gewoon niet kan zien (behalve als je IP-locks etc. etc. blahblah doet)

[dev icey]

Sessies
Een stukje tekst om wat onduidelijkheid weg te halen.

Sessies is een naam voor een stuk informatie wat opgeslagen wordt op de server. Dit wordt meestal gebruikt voor gebruikersspecifieke informatie. Om sessies bij de juiste gebruiker te houden, krijgt elke gebruiker een zogenaamd sessieid (s.v. pincode), zodat de server de gebruiker zijn eigen sessies kan geven. Die sessieID wordt meestal opgeslagen in een cookie bij de gebruiker op zijn computer.

Stel gebruiker A krijgt de sessieID 82 aangewezen. Gebruiker A heeft dan een cookie (meestal PHPSESSID)met de inhoud o.a. waarde 82 (in md5). Gebruiker B, vindt die cookie, en leest de waarde uit. Gebruiker B heeft nu de sessieid van gebruiker A. Gebruiker B stopt de sessieid in zijn cookie, en de server ziet dat Gebruiker B, de sessieid heeft van gebruiker A. De server denkt dus dat Gebruiker B, gebruiker A is.
De server denkt dus dat de sessies die eigenlijk voor gebruiker A gemaakt zijn, nu dus voor gebruiker B zijn (want de server denkt dat gebruiker B gebruiker A is).

Als gebruiker A dus een sessie had, met de informatie dat hij ingelogd is onder gebruikersnaam A, en B kaapt die sessie. Dan is gebruiker B ingelogd onder A's gebruikersnaam. Dit is dus ook op tweakers gebeurd. De mod/admin gaf zijn sessieID weg via een link, en anderen stopten die sessieID in hun eigen cookie. React dacht dus dat de bezoekers die ene mod was.

Hoe kan dit nou?
Heel simpel, ik zei al eerder dat de sessieID meestal wordt opgeslagen in een cookie. Op sommige servers wordt de sessieID ook toegevoegd aan alle links die in pagina's staan. Als een mod/admin dan die link kopieert, kopieert hij dus ook het stuk met zijn sessieID mee. Deze fout zat ook in hotmail. Het kan de besten overkomen.

Hoe voorkom je dit
- Natuurlijk door de gebruikers, mods/admins goed in te lichten.
- Koppel de sessieID aan het ip van de gebruiker die inlogde. Zo kan de sessieID niet door een ander ip gebruikt worden. Let op, de sessieID geld zolang de browser open staat.
- SessieID's kunnen ook gesniffed worden -> gebruik hiertegen ssl. Maar zolang je de sessieId koppelt aan het ip, kunnen ze niks met de huidige sessieID.

Hopelijk is dit duidelijk, en anders, ask me

edit:
hm... soort verlengde versie van curry

[eghie]

curry684 schreef op maandag 22 november 2004 @ 13:02:
een verhaaltje over sessie id's.

dev icey schreef op maandag 22 november 2004 @ 13:21:
een uitgebreid verhaaltje over sessies

Het is me nu helemaal duidelijk. Thnx.

offtopic:
Hoe hete ook alweer zo'n afbeelding waarin je een verificatie code indrukt die de gebruiker dan moet overtypen om bots tegen te houden Ow laat maar. Ze heten keyphrases ofzo.

[ Voor 28% gewijzigd door eghie op 22-11-2004 22:30 ]

[AirX]

Je kunt ook iets client-side maken ... dus een programma maken die dmv een code op de website een eenmalige inlogcode maakt. Zo heb je ook geen problemen van keyloggers, omdat de inlogcode maar één keer te gebruiken is

[dev icey]

AirX schreef op maandag 22 november 2004 @ 13:42:
Je kunt ook iets client-side maken ... dus een programma maken die dmv een code op de website een eenmalige inlogcode maakt. Zo heb je ook geen problemen van keyloggers, omdat de inlogcode maar één keer te gebruiken is

Het probleem is dan dat je weer met een algorithme moet gaan werken, of met een verbinding tussen de server en dat programma. Anders kan de server nooit weten of de key die het programma maakt wel juist is.

De zwakte van een algorithme: Op een gegeven moment is het te achterhalen.
De zwakte van de verbinding tussen de server en het programma: Het is weer te faken/te onderscheppen. Uiteindelijk heb je weer ssl nodig, waardoor je het eigenlijk weer terug bij af bent.

[eghie]

Waarom moet je die beveiligingscode (in de TS) invoeren met die knoppen Die keyphrase is toch al genoeg tegen automagische programma's

[Xander]

eghie schreef op dinsdag 23 november 2004 @ 15:59:
Waarom moet je die beveiligingscode (in de TS) invoeren met die knoppen Die keyphrase is toch al genoeg tegen automagische programma's

Om ook keyloggers nog eens tegen te houden?

[eghie]

XanderH schreef op dinsdag 23 november 2004 @ 16:03:
[...]


Om ook keyloggers nog eens tegen te houden?

Nog niet eens aan gedacht

Ben nu zelf ook bezig om een login script te bouwen, maar dan ook zo veilig mogelijk. Dit is wel handig dat ik dat weet.

Opties die er nu in zitten:
• Client side SHA1 hashing (javascript)
• Random waardes worden mee gehashed met wachtwoord
• IP-Locking (voor zowel op sessie als cookie) (als keuze optie ofcourse)
• Unique ID meenemen in cookie en sessie (in login pagina) en dan steeds checken of ze bestaan en kloppen
• SQL injectie is niet mogelijk
• SSL is een pre
• Bij een fout in controlle op gegevens word je meteen uitgelogd
• Nu ook die beveiliging tegen keyloggers

XanderH schreef op dinsdag 23 november 2004 @ 16:06:
Terwijl het ook nog eens letterlijk in de TS staat

[...]

* eghie trekt nog maar een blikje wannabee "red bull" los.

Is het trouwens veilig om in je app zelf te checken of het wachtwoord geldig is, ipv de SQL database Ik doe dit nu, omdat ik de hash in de database nog een keer moet hashen met een random getal, om het zo nog veiliger te maken.

[ Voor 91% gewijzigd door eghie op 23-11-2004 17:21 ]

[Xander]

eghie schreef op dinsdag 23 november 2004 @ 16:04:
[...]

Nog niet eens aan gedacht

Terwijl het ook nog eens letterlijk in de TS staat

eghie schreef op dinsdag 23 november 2004 @ 16:04:
- Server genereerd 2 code's in de vorm van een image, een getal die de gebruiker mot optellen bij zijn beveiligingscode en moet invoeren met de knopen. (beveiliging tegen keyloggers oa).

[ Voor 27% gewijzigd door Xander op 23-11-2004 16:06 ]

[dev icey]

eghie schreef op dinsdag 23 november 2004 @ 16:04:
Is het trouwens veilig om in je app zelf te checken of het wachtwoord geldig is, ipv de SQL database Ik doe dit nu, omdat ik de hash in de database nog een keer moet hashen met een random getal, om het zo nog veiliger te maken.

Zou je het nog een keer kunnen uitleggen, ik snap niet echt wat je met deze vraag bedoeld? Wat ik ervan kan maken is dat je wilt weten of je in php moet controleren of de ingevoerde wachtwoord geldig is, of door sql moet laten doen middels "WHERE password = '" . $password . "'" ?

Mijn antwoord is, als je het wachtwoord in de database hebt zitten(md5), en je een hash krijgt van de inlogpagina: bijv. hash = md5(key+username+md5(ww)). Dan zou ik, wat volgens mij de enige manier is de password uit de database halen, op dezelfde manier hashen als de inlogpagina deed, zodat je ze dan nog steeds in php aan elkaar gelijk kan stellen.

[ Voor 6% gewijzigd door dev icey op 23-11-2004 17:48 ]

[eghie]

dev icey schreef op dinsdag 23 november 2004 @ 17:48:
[...]


Zou je het nog een keer kunnen uitleggen, ik snap niet echt wat je met deze vraag bedoeld? Wat ik ervan kan maken is dat je wilt weten of je in php moet controleren of de ingevoerde wachtwoord geldig is, of door sql moet laten doen middels "WHERE password = '" . $password . "'" ?

Mijn antwoord is, als je het wachtwoord in de database hebt zitten(md5), en je een hash krijgt van de inlogpagina: bijv. hash = md5(key+username+md5(ww)). Dan zou ik, wat volgens mij de enige manier is de password uit de database halen, op dezelfde manier hashen als de inlogpagina deed, zodat je ze dan nog steeds in php aan elkaar gelijk kan stellen.

Ja dit is nu wat ik dus ongeveer doe. Je hebt m'n vraag dus goed begrepen. Ik gebruik dan ASP.NET, maar het principe is hetzelfde, dus ik snap het wel. Ik hoorde/las (weet niet meer waar) pas namelijk dat je nooit je wachtwoord uit je database moet halen, maar al in de database moet controlleren op geldigheid. Alleen dan zit je dus met het probleem om je random getal/key aan je hash toe te voegen, want die kun je zo natuurlijk niet in de database opslaan. Nu check ik op gebruikersnaam in de database en haal dan het wachtwoord en userID op uit de database en controlleer ze in de applicatie, omdat ik ze dan ook kan hashen zoals bij de login pagina, maar ik vroeg me dus af of dit veilig is Nu heb ik dit wel in een functie staan die alleen true/false kan terug geven, dus kan verder niks anders terug geven, ook al zou SQL injection mogelijk zijn.

Ik denk zelf dus dat ik redelijk veilig zit, maar ik kan natuurlijk wat over het hoofd zien.

Trouwens, geeft het een extra veiligheid, als ik zowel de sessie als de cookie aan een IP lock Of is dat onzin/overbodig

[Erkens]

eghie schreef op woensdag 24 november 2004 @ 09:45:
Trouwens, geeft het een extra veiligheid, als ik zowel de sessie als de cookie aan een IP lock Of is dat onzin/overbodig

je weet wat een cookie is?

[eghie]

Erkens schreef op woensdag 24 november 2004 @ 10:04:
[...]

je weet wat een cookie is?

Ja ok, het hoort bij je sessie. Maar je hebt wel verschillen.

asp.net voorbeeld: session.Add("IP") is anders dan Response.Cookies.Add("IP").

* eghie gaat eerst maar eens echt in cookies verdiepen

[ Voor 22% gewijzigd door eghie op 24-11-2004 10:19 . Reden: request moet response zijn ]

[Erkens]

eghie schreef op woensdag 24 november 2004 @ 10:08:
[...]

Ja ok, het hoort bij je sessie. Maar je hebt wel verschillen.

asp.net voorbeeld: session.Add("IP") is anders dan Request.Cookies.Add("IP").

ehm, een cookie hoort niet bij een sessie, een cookie kan je helpen om een sessie te behouden
een cookie stuur je dus naar de browser en daar een ip aan toevoegen voegt niks toe, dat heeft geen toegevoegde waarde.
immers een cookie stuurt de browser steeds mee, en is dus nooit te vertrouwen, deze kan immers gefaked worden. (never trust userinput)

[eghie]

Erkens schreef op woensdag 24 november 2004 @ 10:15:
[...]

ehm, een cookie hoort niet bij een sessie, een cookie kan je helpen om een sessie te behouden
een cookie stuur je dus naar de browser en daar een ip aan toevoegen voegt niks toe, dat heeft geen toegevoegde waarde.
immers een cookie stuurt de browser steeds mee, en is dus nooit te vertrouwen, deze kan immers gefaked worden. (never trust userinput)

Je moet inderdaad nooit user input vertrouwen. Dat doe ik dan ook niet. Zowel in mn cookie als in session variables heb ik verschillende checks zitten voor geldigheid.

Ik verplicht de gebruikers ook altijd eerst naar login pagina te gaan. Rechtstreeks inloggen via cookie doe ik niet aan, omdat dus die cookie te faken is. Tijdens het inloggen worden die random waardes gegenereerd en in je cookie en session variables gedrukt. Bij elke pagina worden ze gecontrolleerd op geldigheid en of ze uberhaubt al bestaan. Ook gebruikersnaam en wachtwoord worden aan de tand gevoelt. Cookie word trouwens ook verwijderd als de browser word gesloten. Dit in combinatie met IP lock, voor zowel cookie als sessie, met gehashed IP met random waardes (kun je heeel moeilijk faken).

Dit systeem is toch nauwelijks te faken, of wel Dit in combinatie met SSL is wel heel erg moeilijk te hijacken. Tenminste dat is mijn idee.

[ Voor 4% gewijzigd door eghie op 24-11-2004 10:47 ]

[Erkens]

Ik zet gewoon een cookie met een eigen sessie id, welke ik in de database check of het geldig is. Extra dingen in cookies zetten is niet nodig. Want waarom zou je uberhaupt dingen als IP's willen opslaan in een cookie, dat is gewoon echt niet nuttig, want dat ip heb je ook al met $_SERVER['REMOTE_ADDR'] en waarom zou je die ook nog willen op kunnen vragen met $_COOKIE['IP'] zinloze verspilling van een cookie.

[edit]
Overigens is SSL geen toverwoord waarmee je pagina's direct veilig zijn, het encrypt enkel de verbinding, niet tegen jou gericht hoor, maar sommige denken dat met SSL alles veilig te krijgen is

[ Voor 23% gewijzigd door Erkens op 24-11-2004 10:53 ]

[eghie]

Erkens schreef op woensdag 24 november 2004 @ 10:52:
Ik zet gewoon een cookie met een eigen sessie id, welke ik in de database check of het geldig is. Extra dingen in cookies zetten is niet nodig. Want waarom zou je uberhaupt dingen als IP's willen opslaan in een cookie, dat is gewoon echt niet nuttig, want dat ip heb je ook al met $_SERVER['REMOTE_ADDR'] en waarom zou je die ook nog willen op kunnen vragen met $_COOKIE['IP'] zinloze verspilling van een cookie.

[edit]
Overigens is SSL geen toverwoord waarmee je pagina's direct veilig zijn, het encrypt enkel de verbinding, niet tegen jou gericht hoor, maar sommige denken dat met SSL alles veilig te krijgen is

Met het IP in cookie pas ik IP locking toe.

Pseudo code: (PS. let niet op deze code, het zal ongetwijfeld niet kloppen, maar het gaat om het idee)(wannabee php)

PHP:

if ($_COOKIE['IP'] == $_SERVER['REMOTE_ADDR'] && $_SESSION['IP'] == $_SERVER['REMOTE_ADDR'])
{
    login = true;
}
else
{
    login = false;
}

Zo wil ik checken of het IP in de cookie en sessie klopt met de echte IP van de bezoeker, dan is die cookie wat moeilijker te faken.

Ik weet trouwens dat je niet alleen op SSL moet vertrouwen, daarom moet je het in combinatie met je bestaande beveiliging gebruiken. SSL kun je bijv gebruiken om het sniffen naar pakketjes tegen te gaan, maar je applicatie moet zonder SSL ook al veilig zijn.

[Erkens]

eghie schreef op woensdag 24 november 2004 @ 11:05:
[...]

Met het IP in cookie pas ik IP locking toe.

Pseudo code: (PS. let niet op deze code, het zal ongetwijfeld niet kloppen, maar het gaat om het idee)(wannabee php)

PHP:

if ($_COOKIE['IP'] == $_SERVER['REMOTE_ADDR'] && $_SESSION['IP'] == $_SERVER['REMOTE_ADDR'])
{
    login = true;
}
else
{
    login = false;
}

Zo wil ik checken of het IP in de cookie en sessie klopt met de echte IP van de bezoeker, dan is die cookie wat moeilijker te faken.

maar wat is daat het nut van?

PHP:

$login = ($_SERVER['REMOTE_ADDR'] == $_SESSION['IP']);

is net zo veilig, immers als je het session id hebt, dan werkt hij toch niet met een ander ip, en als je echt kwaad wil dan verander je dat cookie met het ip toch ook gewoon

[eghie]

Erkens schreef op woensdag 24 november 2004 @ 11:12:
...en als je echt kwaad wil dan verander je dat cookie met het ip toch ook gewoon

Die reactie had ik verwacht Maar zie het volgende stukje:

eghie schreef op woensdag 24 november 2004 @ 10:46:
... Dit in combinatie met IP lock, voor zowel cookie als sessie, met gehashed IP met random waardes (kun je heeel moeilijk faken) ...

Het nut hiervan is dus dat je cookie niet makkelijk meer kunt faken.

[Erkens]

jij snapt waarschijnlijk niet wat je doet
immers, dat cookie met dat IP is gewoon een extra weergave van de standaard $_SERVER['REMOTE_ADDR'] niks meer, niks minder. Nu heb je een cookie met je session id erin, in je sessie staat welk IP bij deze sessie hoort, je checked het ip uit $_SERVER['REMOTE_ADDR'] met het ip uit je sessie, zodra dit matched is het goed, matched het niet dan is het ip anders, waarom dan toch nog een cookie met het ip toevoegen?
Of wil je ook cookies toevoegen met username en password ofzo omdat zeker te zijn dat het klopt

$_SERVER['REMOTE_ADDR'] is niet te faken, $_COOKIE[] wel, dus welke vertrouw je

[eghie]

Erkens schreef op woensdag 24 november 2004 @ 11:20:
jij snapt waarschijnlijk niet wat je doet
immers, dat cookie met dat IP is gewoon een extra weergave van de standaard $_SERVER['REMOTE_ADDR'] niks meer, niks minder. Nu heb je een cookie met je session id erin, in je sessie staat welk IP bij deze sessie hoort, je checked het ip uit $_SERVER['REMOTE_ADDR'] met het ip uit je sessie, zodra dit matched is het goed, matched het niet dan is het ip anders, waarom dan toch nog een cookie met het ip toevoegen?
Of wil je ook cookies toevoegen met username en password ofzo omdat zeker te zijn dat het klopt

$_SERVER['REMOTE_ADDR'] is niet te faken, $_COOKIE[] wel, dus welke vertrouw je

hahaha, nee sorry, heb hem nu door. Cookie koppelen met je sessie zorgt dus al voor de controlle. (* eghie gaat weer verder slapen)

$_SERVER['REMOTE_ADDR'] is degene die ik meer vertrouw (ik vertrouw hem niet volledig), alleen kun je die volgens mij ook faken, maar weet niet helemaal zeker.

[ Voor 5% gewijzigd door eghie op 24-11-2004 11:32 ]

[Verwijderd]

Het is in deze thread al een paar keer genoemt, maar waarom is op GOT een disussie over web apps meteen gelijk aan PHP?

Mij is altijd geleerd dat niet de hele web wereld op PHP draait. Er schijnt nog zoiets te zijn als J2EE en ASP onder andere. Deze discusssie is gewoon algemeen voor web security en heeft erg weinig met de taal PHP te maken.

[Erkens]

Verwijderd schreef op woensdag 24 november 2004 @ 12:08:
Het is in deze thread al een paar keer genoemt, maar waarom is op GOT een disussie over web apps meteen gelijk aan PHP?

Mij is altijd geleerd dat niet de hele web wereld op PHP draait. Er schijnt nog zoiets te zijn als J2EE en ASP onder andere. Deze discusssie is gewoon algemeen voor web security en heeft erg weinig met de taal PHP te maken.

php wordt hier gebruikt omdat de TS daarmee begon (zie titel)
Daarnaast zijn de voorbeelden erg eenvoudig te vertalen naar de andere talen, maar je kan moeilijk in een voorbeeld meteen in alle talen gaan schijven.

Daarnaast heb ik in dit topic ook asp.net voorbeelden gezien

[Verwijderd]

Verwijderd schreef op woensdag 24 november 2004 @ 12:08:
Het is in deze thread al een paar keer genoemt, maar waarom is op GOT een disussie over web apps meteen gelijk aan PHP?

Mij is altijd geleerd dat niet de hele web wereld op PHP draait. Er schijnt nog zoiets te zijn als J2EE en ASP onder andere. Deze discusssie is gewoon algemeen voor web security en heeft erg weinig met de taal PHP te maken.

Nou, mij is geleerd dat als TS zelf begint over PHP, dat je er vanuit mag gaan dat z'n probleem PHP betreft en dat een reply sturen met PHP niet verkeerd is...

Bovendien is dit hele topic toch al bruut gekaapt. Over veilig inloggen gaat het al lang niet meer

[Erkens]

Verwijderd schreef op woensdag 24 november 2004 @ 13:00:
Bovendien is dit hele topic toch al bruut gekaapt. Over veilig inloggen gaat het al lang niet meer

Volgens mij gaat dit topic juist over het inloggen * Erkens wijst nogmaals naar de titel.
Uiteraard moet je wel verder kijken dan alleen de login en dat is ook wat er gebeurd voor zover ik zie, waar zie je dan dat het "bruut gekaapt" is

[Verwijderd]

Nou, van veilig inloggen, zijn we opeens bij sessies belandt. Tuurlijk heeft dat enig verband met elkaar, maar dit topic gaat volgens mij over veilig inloggen. Daarin kan je dus discussieren over technieken om in te loggen. Dat een grote en ingewikkelde inlogprocedure geen nut heeft wanneer de aanvaller simpel de sessie kan kapen, is een ander punt. Dat heeft niets meer te maken met het inloggen zelf.
Dat een sessie simpel te kapen is, heeft niets meer met het inloggen an sich te maken. De inlogprocedure is dan nog wel veilig, maar is er gewoonweg ergens anders een fout in geslopen.
Dat bedoelde ik met offtopic gaan.

[Erkens]

Verwijderd schreef op woensdag 24 november 2004 @ 13:07:
Dat bedoelde ik met offtopic gaan.

sorry voor jou, maar daar stuurde de TS het topic naar toe

Verwijderd schreef op zaterdag 20 november 2004 @ 18:26:
[...]


tot iemand in de handen komt van de sessieID, magoed, daar gaan we niet uitkomen.

waar jij zelfs nog op reageert:

Verwijderd schreef op zaterdag 20 november 2004 @ 18:28:
[...]


Dat probleem blijf je altijd houden...

Dus waarom star blijven kijken naar enkel de login en niet even daar langs kijken, naar de manier waarop je ingelogt bent

[Verwijderd]

Dat de TS met PHP begon is mischien wel zo, maar alles gaat toch helemaal niet daarover? Het gaat over sessies, methoded om passwords te verzenden, methoden voor veilige communicatie enz. Wat in deze thread is nou PHP specificiek dan?

[Erkens]

Verwijderd schreef op woensdag 24 november 2004 @ 13:43:
Dat de TS met PHP begon is mischien wel zo, maar alles gaat toch helemaal niet daarover? Het gaat over sessies, methoded om passwords te verzenden, methoden voor veilige communicatie enz. Wat in deze thread is nou PHP specificiek dan?

niks, maar wat is je punt nu? kan iedereen misschien weer gewoon ontopic blijven

[Verwijderd]

Wat mijn punt is? Dat niet alles wat algemeen web app is, meteen onder de noemer PHP komt.

[eghie]

Verwijderd schreef op woensdag 24 november 2004 @ 13:07:
Nou, van veilig inloggen, zijn we opeens bij sessies belandt. Tuurlijk heeft dat enig verband met elkaar, maar dit topic gaat volgens mij over veilig inloggen. Daarin kan je dus discussieren over technieken om in te loggen. Dat een grote en ingewikkelde inlogprocedure geen nut heeft wanneer de aanvaller simpel de sessie kan kapen, is een ander punt. Dat heeft niets meer te maken met het inloggen zelf.
Dat een sessie simpel te kapen is, heeft niets meer met het inloggen an sich te maken. De inlogprocedure is dan nog wel veilig, maar is er gewoonweg ergens anders een fout in geslopen.
Dat bedoelde ik met offtopic gaan.

offtopic:
Dit topic gaat inderdaad over veilig inloggen, maar bij veilig inloggen moet je niet alleen de goede methodes hebben, maar ze ook goed en veilig gebruiken. Bij inloggen heb je natuurlijk ook sessie's en cookie's. Dit hoort ook allemaal bij het veilig inloggen, want is het inloggen nog steeds veilig als je zo maar een sessie van iemand kunt kapen Het inloggen is bedoelt om alleen toegestane gebruikers toegang te geven. Daarvoor moet je niet alleen naar het inlog procedure kijken, maar naar je hele web applicatie.

De TS begon mischien wel met PHP, maar het probleem ligt bij alle webapps, dus er mogen ook best andere talen behandeld worden en dat gebeurt ook wel. Ik heb bijv. ASP.NET gebruikt om uit te leggen. Daar is verder niks mis mee, omdat dit topic niet specifiek over PHP gaat (ook al begint de TS er wel mee). Plus dat je ook andere talen zo om kan zetten naar je eigen taal, omdat het principe hetzelfde is.

Maar laten we nu weer ontopic gaan dan.

Ik vind trouwens die anti-keylog methode een goed idee van de TS. Ik heb het er nu ook inzitten. Elke klein beetje helpt weer.

Wat je ook nog als optie erin kunt zetten is na bijv. 20 keer fout inloggen, dat je dan word gebanned. En dat je naar 3 keer inloggen een aparte pagina krijgt met de waarschuwing dat je 3x fout ingelogd bent en dat je dan ook wordt gelogd.

Ik zou trouwens niet te zuinig zijn met loggen. Wat je het beste kunt doen is een aparte log schrijven voor je beveiliging en daar alle mogelijke hijack pogingen te loggen, met IP en Hostname. En zorgen dat je zelf ook IP's kunt toevoegen/verwijderen aan een ban.

[ Voor 21% gewijzigd door eghie op 24-11-2004 14:28 . Reden: ff offtopic gedeelte tussen tags gezet ]

[Verwijderd]

eghie schreef op woensdag 24 november 2004 @ 14:17:
Wat je ook nog als optie erin kunt zetten is na bijv. 20 keer fout inloggen, dat je dan word gebanned. En dat je naar 3 keer inloggen een aparte pagina krijgt met de waarschuwing dat je 3x fout ingelogd bent en dat je dan ook wordt gelogd.

Ik hoop niet dat je met bannen bedoelt dat je het IP van de foute inlogger blokt, want dat heeft echt geen enkele zin (*hint*proxies*hint*). Beter is het om al na 5 foutieve logins van een gebruiker zijn/haar account volledig te blokkeren. Alleen als je contact opneemt met de admin kan je je account weer gebruiken. Zo heeft een brute-forcer een verwaarloosbare kans.

Sowieso moet je elke poging tot inloggen loggen, dan kan je eens in de zoveel tijd kijken of er niet toevallig iemand is die wel heel vaak het verkeerde wachtwoord opgeeft