Results 1 to 7 of 7

Thread: Brainstorm: beveiliging

  1. #1
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269

    Brainstorm: beveiliging

    Ik ben een beetje verder gaan ratelen op het idee 'beveiliging en server interactie', hier even de ideeen uit de chat en mijn ideeen die later gekomen zijn. Ik post ze op het forum zodat iedereen mee kan redeneren om te zorgen dat hun favoriete site niet misbruikt wordt ... [/slijm-modus]


    Allereerst kwam het idee om data van de client op te slaan op de server, zodat je, waar je ook zit, altijd dezelfde gegevens bij de hand hebt. Is op zich een leuk idee, maar vergt veel van de server, vooral als iedereen z'n complete cache gaat uploaden. Wat wel erg handig zou zijn is de mogelijkheid om tenminste op te slaan wanneer je laatste check was, zodat je als je bijvoorbeeld op je werk alle topics al langs hebt zien komen deze thuis niet nog een keer krijgt. Uiteraard moet je dat ook uit kunnen omdat je op je werk misschien de topics zelf niet leest en ze thuis alsnog wilt binnenhalen. Het idee om iets meer data op te kunnen slaan op de server is in ieder geval geen slecht idee...

    Verder was mijn idee om dan eventueel een Import/Export functie in te bouwen die de data naar bijvoorbeeld een eigen FTP server kan uploaden of op een of andere manier verplaatsen zodat je in ieder geval client-specifieke data ook mee kan nemen tussen 2 locaties (denk in het geval van mijn client aan je favorieten)en de NLDelphi server minder belast is met deze data (die met flink wat gebruikers toch aardig op kan lopen).



    In ieder geval heb je voor deze dingen een manier nodig om gebruikers te identificeren, dus zo kwam het idee om je inloggegevens in te moeten vullen in de client. Is technisch gezien zo in te bouwen en aangezien de mensen die baat hebben bij DeX toch al lid zijn maakt dat ook niet veel meer uit, maar het moet wel enigzins secure zijn, dus hier hetgeen wat ik zojuist bedacht heb onder de douche: (op een of andere manier komen daar mijn geniaalste ideeen vandaan )




    Het paswoord van vBulletin is opgeslagen in een MD5 hash formaat (MD5: eenwegsencryptie, is alleen te decoden met brute force). Je zou de inloggegevens mee kunnen sturen in een GET of POST query (liever POST trouwens, komt de data niet in logs te staan) en op de client alvast MD5 encrypten om aftappen van verkeer te verhinderen. Probleem is, als iemand dan eenmaal die MD5 hash heeft afgetapt kunnen ze dat gebruiken om de client te misbruiken. Ze kunnen welliswaar het paswoord niet achterhalen, maar we willen toch het zekere voor het onzekere nemen...

    Wat veel veiliger is is om nog steeds het paswoord op de client te encrypten en op te slaan (het hoeft toch niet te decrypten zijn), dan bij het uitvoeren van een query die string nemen en er de DateTime parameter die je meestuurt achteraan plakken, en dat vervolgens door MD5 heen te halen:

    Code:
    StoredPass := MD5(InputPass);
    // Sla StoredPass eventueel op...
    Pass := MD5(StoredPass + IntToStr(DateTime));

    Dat betekent dat als iemand het verkeer aftapt hij nog niks aan dit wachtwoord heeft, want de hash veranderd bij elke aanroep. Wat de server kan doen is het wachtwoord uit de db halen, dezelfde MD5(StoredPass + DateTime) uitvoeren en dat matchen.


    Het meest onveilig in dit geval is het opslaan van het wachtwoord op de client, dat is de enige manier om met een client in te kunnen loggen. Voordeel van de hash opslaan is wel dat als iemand die gegevens heeft dat hij(/zij) ze nog niet kan decrypten en er dus hooguit mee kan inloggen via de client...

    Je zou het wachtwoord alsnog kunnen encrypten, maar dan moet het decryptbaar zijn en heeft dus geen verdere waarde. Je moet ergens de grens leggen qua veiligheid. Je zou in de client het opslaan van het wachtwoord zelfs optioneel kunnen maken voor situaties waarin je een computer deelt o.i.d. (we nemen natuurlijk allemaal DeX mee naar internetcafe's in het buitenland , onee, tijdzone is dan anders, gaat DeX flippen...)



    Maar goed, op deze manier heb je een redelijk betrouwbare manier van inloggen en kan je wat simpele data opslaan op de server (samen met checks of er niet elke seconde wordt gequeried), en kan je 't zelfs uitbreiden tot 'Check private messages' of andere ongein



    Zo, weer veelsteveel getypt eigenlijk, maar goed, ik hoor wel wat jullie (en met name Marcel, die moet de server tenslotte updaten tegen die tijd ) ervan vinden...
    Qui custodiet ipsos custodes

  2. #2
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,213
    ik denk dat het inderdaad een goed idee is om een s te beginnen met het kunnen inloggen in je client en op de server de laatste ophaaltijd op te slaan. later kan dan alsnog worden besloten om wat andere data ook op de server op te slaan. Zo maak je ook meteen verplicht om lid te zijn van nldelphi voor je dex of psycho's client kan gebruiken. op zich geen slecht idee, aangezien dan een beetje duidelijk is wie het kan gebruiken. Op die manier kun je ook zien hoeveel verschillende mensen nu eigenlijk een van de clients gebruiken. wat dan weer kan doen besluiten om wel of niet meer data op de server op te slaan.

    wat betreft je manier van beveiligen: ik denk dat dit zeker zwaar genoeg beveiligd is. je hebt er tenslotte niet echt veel aan om de client te misbruiken. hooguit om het forum te flooden, maar als je dat per se wilt doen zijn er ook wel makkelijkere manieren dan een of andere encrypted client te gaan hacken.

    het opslaan van de users van de clients op de server heeft ook tot voordeel dat je eventuele misbruikers veel makkelijker kan identificeren (ze kunnen natuurlijk wel makkelijk een nieuwe userID aanmaken, maar alle kleine beetjes helpen)

    maar goed laten we eerst maar een s wachten wat de "baas" (?) ervan te zeggen heeft....


    PS. Psycho: je hoeft ons niet per se mee te delen dat je je beste ideen onder de douche krijgt. ik begin je software al steeds raarder aan te kijken....
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  3. #3
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Originally posted by walterheck
    PS. Psycho: je hoeft ons niet per se mee te delen dat je je beste ideen onder de douche krijgt. ik begin je software al steeds raarder aan te kijken....

    He, de code is dan in ieder geval clean

    Het hele encryptiegebeuren om het paswoord ging vooral om te zorgen dat niemand zomaar je paswoord kan krijgen. Aan de andere kant stuurt je browser het nog veel onveiliger mee, maar dat is vaak 1x inloggen, de client gaat meestal elke minuut het paswoord verzenden...
    Qui custodiet ipsos custodes

  4. #4
    Ik vind het er goed uitzien. Het steeds opnieuw verzenden van wachtwoord zouden we kunnen voorkomen door een session ID aan te vragen. Dus ik log in met username/wachtwoord en krijg een session ID terug. Vervolgens wordt die ID steeds gebruikt om aan te geven wie je bent.
    Marcel

  5. #5
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,213
    vraag is dan alleen hoe lang laat je die session duren?
    of zorg je ervoor dat als er vanaf een andere pc wordt geconnect met dezelfde uis/pwd, er een andere sessionid wordt gemaakt?
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  6. #6
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Niet zo moeilijk:


    Client stuurt username/passwd en vraagt om een session id. De server returned deze dan in de XML output, slaat 'm op in de database en de client zal deze onthouden zolang als deze draait. Bij de volgende aanvraag stuur je de session ID weer mee, zoekt de server naar opgeslagen ID's, en geeft een error code terug als de sessie verlopen is. De client probeert het dan nogmaals met username/password om een nieuwe ID te krijgen, lukt dat ook niet dan mag je aannemen dat het paswoord is gewijzigd in de tussentijd.

    De sessies blijven gewoon een uur geldig o.i.d., waarna de server ze automatisch verwijderd. Als de client een nieuwe request doet met een geldig ID dan update je gewoon de laatste access-time en blijft het ID geldig...


    Which reminds me, er moet misschien nog een afspraak komen voor error codes zodat de client deze juist kan interpreteren...



    [Edit]

    Dus dan zou elke pc inderdaad z'n eigen session ID hebben...
    Qui custodiet ipsos custodes

  7. #7
    Niet alleen elke PC, maar elke DeX. Je zou DeX 2x op kunnen starten, die moeten dan een eigen ID hebben.
    Marcel

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 13
    Last Post: 05-May-04, 00:54
  2. com+ beveiliging
    By jakees in forum Algemeen
    Replies: 3
    Last Post: 08-Jan-04, 18:00
  3. Beveiliging website
    By cliov6 in forum Koffiehoek
    Replies: 15
    Last Post: 10-Sep-03, 21:18
  4. Datum beveiliging
    By hjong in forum Algemeen
    Replies: 6
    Last Post: 06-Aug-03, 17:01
  5. Beveiliging Access database
    By The Master in forum Databases
    Replies: 9
    Last Post: 04-Jan-03, 01:09

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •