[BC3] ASP->Hulp bij plan opzet SECURE login pagina

[Mister_X]

hey, daar bent ik weer

ik heb een vraag je, ik heb dit: ASP scripje gevonden.

<%
if Request.Form("login") = "Guest" AND Request.Form("password") = "Guest" Then
Response.Write "This is all the <B>cool stuff</B> we are trying to protect!"
Else
Response.Write "Access Denied!"
''Response.End
End If
%>

ik wil dit gebruiken om mijn pagina''s te beveiligen (de post topic en reply pagina, dus alleen replyen of posten als je een correct login + paswoord invoert)

uiteraard word dit scrip iets uitgebreider en gekoppelt aan een user tabel, maar dat is het probleem niet,

ik heb in mee hoofd het idee om het zo te doen:

ik heb een post.asp waarin je je
-TOPIC NAAM
-naam
-paswoord (nog niet, dan wel)
-emailadres
-BERICHT
moet invoeren, daarna kijkt ie eers naar het usernaam+paswoord, dan moet ie een cookie zetten zodat ze de volgende keer niet in hoeven te loggen!

dus de 2e keer dat ze wat willen posten moeten de (met post.asp) velden naam/emailadres/paswoord al ingevuld zijn, maar niet in een invoerbak, gewoon als tekst op het scherm, dus dan hou je alleen de invoerbakken van new topic en bericht open.

hoe pak ik dit het aan? het moet dus in 1 file. post.asp

ik hoef geen scrippies ofzo maar gewoon de volgorde hoe het moet lopen en of dit wel kan?

kijk dit is de plan van aanpak:

IF COOKIE EXCIST THEN
<dont show invoerbak naam/emailadres/paswoord
ELSE

SHOW EMPTY invoerbak voor naam/emailadres/paswoord
END

IF pas+usernaam is correct THEN
se a cookie & post message
redirect naar forum.asp
ELSE
rederict FOUT.ASP
END

is dit zoals het moet gaan lopen? (dan niet in die woorden uiteraard! )

heb ik hier goed over nagedacht? of gaat dit nooit werken?

bedankt voor het helpen alvast,

Evert

[Verwijderd]

If cookie exist then
verify nogmaals username & password
if username && pasword == goed then
ga verder naar posten.
else
ga naar fout.asp

xxx () Jelle

[ACM]

Al dat gedoe met honderd keer de cookie waarden checken

Wat ik meestal doe:
Maak een login systeem dat sessions vult.
Deze sessions worden dan _alleen_ door de login en loguit page bewerkt (wat username enzo betreft)

In php haal ik dan het volgende truckje uit:

PHP:

<?
$login_naam = "";
session_start();
if($login_naam == "")
{
    got_to_login();
    die();
}
?>

En het is volgens mij nog goed ook
Ohja, het voorkomt ook nog es het nutteloos en gevaarlijk vaak het bekijken van de passwords etc. De session_id is nu de enige gevaarlijke key, maar die kan je gekoppeld aan een ip oid opslaan in een database om ze aldaar te checken.

Ook handig is het gebruiken van SSL in deze context.

[Mister_X]

SSL, PHP

ik niet begrijp en dat gequote stukje meot ik met ene vergroot glas bekijken,

enne xx terug jellie pelly , zeker vrij vandaag kerel?

wat een domme sig heb je trouwens

Bier is voor mietjes©
R.A.Z.O.R.B.L.A.D.E :
Robotic Artificial Zombie Optimized for Repair of Biomechanical Lifelike Androids Designed for Exploration

[Verwijderd]

Op vrijdag 18 mei 2001 15:50 schreef Mister_X het volgende:
SSL, PHP

SSL = Secure Socket Layer
PHP = Personal HomePage

[Mister_X]

ik weet wel wat het is hoor maar ik gebruik/ken die talen niet dat bedoelde ik.

[Verwijderd]

Op vrijdag 18 mei 2001 16:03 schreef Mister_X het volgende:
ik weet wel wat het is hoor maar ik gebruik/ken die talen niet dat bedoelde ik.

<edit>
Sorry, F5 syndroom
</edit>

[Verwijderd]

Op vrijdag 18 mei 2001 16:03 schreef Mister_X het volgende:
ik weet wel wat het is hoor maar ik gebruik/ken die talen niet dat bedoelde ik.

SSL!=taal.
SSL=protocol.

[Mister_X]

F5 sydroom?

laat dat over dat SSL maar hangen hoor! is niet important right now.

[Yucon]

F5 => S5



<edit>
Ik dacht even dat Mister_X''s reactie tegen raptorix een vriendschappelijke afzeikopmerking was (collega''s ofsow) ipv een extreem lompe newbie-met-grote-bek-opmerking. Maar door het bericht hieronder begin ik toch te twijfelen... Kennen jullie elkaar of niet?

Mensen die je helpen moet je niet afzeiken, en op mensen die ergens verstand van hebben en je helpen moet je helemaal zuinig zijn
</edit>

[raptorix]

Mister X je moet es beginnen gewoon een normaal boek te kopen, daar staan dit soort dingen echt haarfijn uitgelegt, maar ik zal niet lullig zijn, je moet gewoon gebruik maken van een session variable, je laat een user inloggen, als zijn username/password klopt onthou je zijn userid, dit kan je dan weer makkelijk koppelen aan zijn postings, je kan eventueel zijn username password onthouden maar check dat gewoon als iemand je website entert. Dus maak dan een procedure die zijn username/password uit de cookie inleest en check dat op de zelfde manier als je normaal de user controleert, uiteraard is het resultaat ook weer hetzelfde.

[Mister_X]

Op vrijdag 18 mei 2001 16:43 schreef Yucon het volgende:
F5 => S5



<edit>
Ik dacht even dat Mister_X''s reactie tegen raptorix een vriendschappelijke afzeikopmerking was (collega''s ofsow) ipv een extreem lompe newbie-met-grote-bek-opmerking. Maar door het bericht hieronder begin ik toch te twijfelen... Kennen jullie elkaar of niet?

Mensen die je helpen moet je niet afzeiken, en op mensen die ergens verstand van hebben en je helpen moet je helemaal zuinig zijn
</edit>

welke reactie van mij tegen raptorix?

[Mister_X]

Op vrijdag 18 mei 2001 16:56 schreef raptorix het volgende:
Mister X je moet es beginnen gewoon een normaal boek te kopen, daar staan dit soort dingen echt haarfijn uitgelegt, maar ik zal niet lullig zijn, je moet gewoon gebruik maken van een session variable, je laat een user inloggen, als zijn username/password klopt onthou je zijn userid, dit kan je dan weer makkelijk koppelen aan zijn postings, je kan eventueel zijn username password onthouden maar check dat gewoon als iemand je website entert. Dus maak dan een procedure die zijn username/password uit de cookie inleest en check dat op de zelfde manier als je normaal de user controleert, uiteraard is het resultaat ook weer hetzelfde.

ik heb geen boeken over asp, laastaan geld om er 1 te kopen! ik vroeg ook gewoon of it theoretisch mogelijk is/was.

maar thx zal zo, ... nee ben net wakker, ik zal vanmiddag efff.... kut moet ik voetballen...ik zal het onthouden voor na het weekend, (op me werk ga ik weer verder)

morguh nog allemaal.

[Yucon]

Shit, ik vergiste me... wat een blunder... de post waar ik het over had (4de van boven) was tegen razorblade bedoeld. Maar mn opmerking blijft staan, smileys of niet, samen met je andere commentaar was het een lompe post. Ik twijfelde een beetje over mn post nu, ouwe koeien ensow, maar omdat ik twee personen verwisseld heb en het je niet echt duidelijk was dus toch maar. Eigenlijk denk ik gewoon dat je, en dan heb ik het over je posts in het algemeen, de dingen die er staan als je eigen problemen moet zien waarbij anderen je kunnen helpen en niet als iets waar je mee bezig bent en ondertussen anderen de lastige dingen laat oplossen als je even vastzit. Vat het verder niet te negatief op want iedereen hier is ooit begonnen, zie het meer als een dat-je-het-ff-weet reactie.

[Mister_X]

Op vrijdag 18 mei 2001 16:43 schreef Yucon het volgende:
F5 => S5



<edit>
Ik dacht even dat Mister_X''s reactie tegen raptorix een vriendschappelijke afzeikopmerking was (collega''s ofsow) ipv een extreem lompe newbie-met-grote-bek-opmerking. Maar door het bericht hieronder begin ik toch te twijfelen... Kennen jullie elkaar of niet?

Mensen die je helpen moet je niet afzeiken, en op mensen die ergens verstand van hebben en je helpen moet je helemaal zuinig zijn
</edit>

leg nou nog 1 keer uit welke reactie tegen die raptorix?

ik newbie? laatme niet lachen!

[Verwijderd]

Idee voor het opzetten van een secure login pagina. Zo wil ik het gaan doen, maar is deze methode veilig, hoe kan het veiliger???? Extra ideeen zijn zeer welkom!!


Even extra info: ik wil win2k met IIS gaan draaien, omdat ik windows nodig heb voor verdere programma's. Als scripting-language kies ik voor ASP, en eventueel compileer ik een component dat ik in Visual Basic heb geschreven om aan te roepen. Ik maak gebruik van SSL dmv shttp.


Ik maak een tabel met user/passwd gegevens. Ik sla niet het passwd plain op, maar een MD5 key daarvan.

userId userName MD5Passwd

Ik maak een tabel met daarin sessie-gegevens, namelijk:

sessieId userName sessiekey ipnummer startdatum laatsterequestdatum

Een sessie verloopt na een bepaalde tijd. Dan moet opnieuw worden ingelogt. Dit wordt gecheckt bij een request en zo af en toe worden gewoon alle oude sessies verwijdert i.v.m. het opschonen van de tabel.

Als een gebruiker inlogt stuurt hij met 'n form z'n username en passwd op. Als deze gegevens correct zijn, wordt er:
- een willekeurige string gemaakt: de sessiekey
- word een sessie aan de tabel toegevoegt, met alle gegevens netjes ingevult.
- worden de gegevens sessieId userName sessieKey laatsterequestdatum opgeslagen in een cookie.


Bij het ophalen van een volgende pagina wordt er gekeken of er een cookie is, zo nee dan: opnieuw inloggen
zo ja dan: checken hoe oud 't cookie is en of 't niet verlopen is. (Dit wordt alleen in 't cookie opgeslagen zodat er niet iemand is met een oude sessieId, en dus dan een melding krijgt van acces denied, maar gewoon een nette login pagina krijgt)
als 't een "goed" cookie is dan:
- checken of de gegevens kloppen met de gegevens in de sessie-tabel. Hierbij ook checken of de sessie niet verlopen is m.b.v. de laatsterequestdatum uit de tabel.
- laatsterequestdatum in de tabel aanpassen en in het volgende cookie aanpassen.


Er komt natuurlijk ook een uitlog knop waarmee de sessie uit de tabel wordt gehaalt en het cookie leeggemaakt.

[gorgi_19]

:? Volgens mij kan je beter het Session-object van ASP eerst eens goed gaan onderzoeken voordat je dit gaat bouwen. Er zijn namelijk een aantal zaken die volgens mij niet echt hoeven of gewoon niet kloppen.

Zo wil je bijvoorbeeld een cookie aanmaken met een sessionkey, wat een willekeurige string is. Waarom sla je de UserID niet op in een sessievariabele? Zo hoef je ook geen gegevens op te slaan in een database.

Daarnaast verloopt een Sessie-variabele per definitie na verloop van tijd (ik hoop het wel voor je, althans.., anders wordt het vaak je server resetten.;))

[Verwijderd]

Maak 1 file : login.asp

Check hier of een cookie bestaat bij gebruiker

*Zo ja - Controleer waarden met waarden in db
**Oke - Zet Session("login") op TRUE
*Zo nee - Verwijder Cookie, ga terug naar login scherm

*Geen Cookie- Toon Login Scherm
**Check gevens
***Oke > Session("login")=TRUE
****Set Cookie met gegevens, Ga door naar de huidige pagina
***Fout > Geef login scherm

Include dit bestand in elke pagina die je wilt beveiligen. Dus niet alleen de voordeur maar ook de achter/zijdeurtjes

[Verwijderd]

Hmmz, zeer thanx voor jullie reacties. Ik heb idd niet veel ervaring met ASP, en wist dus niet dat ASP zelf al een zooi functies had. Ik zal eens kijken wat M$ allemaal al heeft gemaakt..

[Verwijderd]

Check even

[url="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/aspwsm.asp"]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/aspwsm.asp[/url]

En dan "ASP Session ID Encryption and Session Security"

Belangrijkste opmerkingen over de beveiliging:

- Session ID values are 32-bit long integers.
- Each time the Web server is restarted, a random Session ID starting value is selected.
- For each ASP session that is created, this Session ID value is incremented.
- The 32-bit Session ID is mixed with random data and encrypted to generate a 16-character cookie string. Later, when a cookie is received, the Session ID can be restored from the 16-character cookie string (ASPSESSIONID).
- The encryption key used is randomly selected each time the Web server is restarted.

Ze encrypten de data van de sessionId, dat is opzich wel een erg goed idee. Maar bij gebruik van een sessionKey heeft dat eigenlijk alleen als nut dat het wat moeilijker te achterhalen is hoe het inloggebeuren werkt, verder is het opzich niet nodig.

In plaats van een randome sessionId en encryption, had ik in mijn idee dus een niet-randome sessionId en een sessionKey. De sessionKey kan dan wel heel wat langer dan 4 bytes.

Wat zij ook NIET doen is een IP erbij opslaan. Dit geeft natuurijk wel wat flexibiliteits voordelen, maar als je dit wel doet is dit wel meteen een stuk irritanter voor een mogelijke inbreker.

Zij slaan (natuurlijk) ook geen user-informatie op. als je dit wel doet, staat de username natuurlijk wel op de pc van de desbetreffende persoon, maar het gokken van de goede sessionKey bij de goede username is natuurlijk nog moeilijker. Verder is het toch wel leuk als een bezoeker herkent wordt als hij een site later nog 's bezoekt.


Conclusie:
sessions zijn dus wel handig, maar mijn idee werkt in princiepe ook. (en dat ip is toch wel erg handig)

Graag jullie commentaar..

[ACM]

Doe dat es in een eigen topic, ipv steeds deze omhoog trappen terwijl de topicstarter al niet eens meer op GoT rondloopt (geloof ik)