[Beveiliging] Hoe veilig is dit algoritme?

[mkleinman]

Ik heb een variant gemaakt op public/private RSA beveiliging voor me website.

Een user logt in met Username/Pass, in de controle procedure haal ik username/pass op uiteraard en controleer ofhet klopt. Daarna set ik een 28 cijferig random getal in de database bij die user.

Daarna versleutel ik met een maf algoritme het userid met dit random getal.

Daarna geef ik aan elke willekeurige procedure (pagina) het user_id en de controlewaarde mee. En in elke procedure controleer ik dus of het user_id tesamen met de controlewaarde nog overeenkomt met de randomvalue van 28 cijfers in de database.

Zodra een user uitlogt wordt getal in db op NULL geset.

Is dit algoritme een beetje veilig?

[Verwijderd]

misschien in combinatie met IP adres nog veiliger?

[ACM]

Is een https verbinding niet makkelijker?

Magoed, wat veel belangrijker is, is dat _alles_ dan minstens net zo veilig is als bovenstaand verhaal. Ik denk dat het niet al te onveilig is.
Bedenk ook hoe groot de kans is _dat_ men je site ook daadwerkelijk wil hacken...

[under-world]

Of dit in P uit te drukken is ?? denk het niet...
Het klinkt in ieder geval wel erg veilig !!!

[mkleinman]

Het gaat uiteindelijk om geld achter de website, dus goeie beveiliging is redelijk nodig.

echter https gaat vooralsnog te ver voor de klant waar ik voor werk, dus ik moet het op andere manier doen.

en uiteraard log ik alles wat een persoon doet, dus elk willekeurige wissewasje wat fout gaat (iemand veranderd de controlewaarde e..d.) dan wordt dat gelogd

[ACM]

Op zondag 10 maart 2002 20:35 schreef osama het volgende:
Of dit in P uit te drukken is ?? denk het niet...
Het klinkt in ieder geval wel erg veilig !!!

't Zal wel in P uit te drukken zijn

Hangt vooral van dat maffe algoritme af...

[under-world]

misschien kan hij daar wat meer over vertellen...

[Janoz]

Ik zie het nut van het 'maffe algoritme' niet echt eigenlijk. Deze manier lijkt me net zo veilig als gewoon een random nummer in de DB onthouden, en deze aan de client geven.

[_-= Erikje =-_]

en hoe "random" je random nummer is

[SchizoDuckie]

waarom niet gewoon de gebruiker z'n username in de cookie zetten, en in de database achter de username z'n ipnummer zetten?

Dan heb je iig 1x gecheckt of de user/pass klopt, en hoef je de volgende keer alleen maar select * from table where username = $usercookie & ip = $REMOTE_ADDR te doen. Veilig zat lijkt me, aangezien je niet zomaar een IP kan spoofen van iemand die ingelogd is. dan zal je ip én login naam moeten weten.

[Verwijderd]

IP nummers gebruiken voor beveiliging is een slecht idee.
AOL gebruikers switchen constant van IP nummer doordat er daar een heel stel uitgaande proxies in een pool staan.
Je kan van een AOL'er dus nooit zeggen dat hij 2 tellen later nog hetzelfde IP nummer heeft.

[SchizoDuckie]

Op zondag 10 maart 2002 22:41 schreef MarcoTC het volgende:
IP nummers gebruiken voor beveiliging is een slecht idee.
AOL gebruikers switchen constant van IP nummer doordat er daar een heel stel uitgaande proxies in een pool staan.
Je kan van een AOL'er dus nooit zeggen dat hij 2 tellen later nog hetzelfde IP nummer heeft.

daar hebben we toch $HTTP_FORWARDED_FOR voor?

[mkleinman]

En dat samen met dit random nr zou het nog veiliger zijn.

hmm. I like the idea.

Trouwens het "algoritme" om het userid te verbouwen naar de controlewaarde is pretty useless.

dat is namelijk

randomvalue * 3 * 1234567890 * USER_ID * SYSTIME in seconds.

dus in me decodeerslag kan ik achterhalen wanneer een user heeft ingelogd.

[RickN]

Ik snap niet zo goed hoe dit iets beveiligt. Begrijp ik het zo goed?

1. user logt in.
2. username/password check.
3. genereer een random getal voor de gebruiker.
4. bereken een controle getal uit de userid en het random getal.
5. stuur de userid en het controle getal naar de gebruiker.
6. de gebruiker gebruikt nu deze getallen om te surfen over het beveiligde deel van je website.

Waarom is dit veilig? Ik hoef toch alleen maar de userid en bijbehorende controle getal af te luisteren? Welk random getal daarbij hoort is totaal irrelevant, dat hoef ik niet te weten.

Als er echt belangrijke informatie achter je website zit snap ik niet waarom je geen bekend beveilingings protocol neemt.

[mkleinman]

RickN : Het random getal is wel degelijk van belang, want als de user is uitgelogd is dit getal weg en kan je dus zowiezo al op deze manier niet als andere user data bekijken.


Alleen dus als je met 2 personen tegelijkertijd inlogt en je dus van de andere persoon zijn user_id weet en het controlegetal dan lukt dat..

Maar you're right. het moet veiliger :-)

[RickN]

Op maandag 11 maart 2002 09:05 schreef mkleinman64 het volgende:
RickN : Het random getal is wel degelijk van belang, want als de user is uitgelogd is dit getal weg en kan je dus zowiezo al op deze manier niet als andere user data bekijken.


Alleen dus als je met 2 personen tegelijkertijd inlogt en je dus van de andere persoon zijn user_id weet en het controlegetal dan lukt dat..

Maar you're right. het moet veiliger :-)

Yep, dat klopt wel. Maar aan de andere kant is het enige wat nu van belang is, het wel of niet aanwezig zijn van het random getal, het functioneerd dus als het ware als een vlag en het random zijn van die vlag heeft in je huidige implementatie geen toegevoegde waarde. Je kunt wat dat betreft net zo goed met een binaire waarde bijhouden of een bepaalde user is ingelogd...

Al is dat wel weer gevaarlijk als een hacker userid's kent en een mogelijkheid heeft om uit te vinden welke user's ingelogd zijn. Als hij dat namelijk weet hoeft hij niet eens meer iets af te luisteren. Om dit te voorkomen is zo'n random controlegetal wel weer nuttig.

M.a.w. je bent op de goede weg...

[mkleinman]

random getal werkt niet als een vlag, bedoeling is juist dat de controlewaarde berekening dusdanig van vorm is dat een hacker met een bek vol tanden zit en niet weet met welke getallen de berekeningen tot stand komt.

Ik zat inderdaad te denken aan een cookie extra te setten om eea nog wat veiliger te maken :-)