[web] Manier om client te indentificeren

[Yoram]

Beste Tweakers,

Omdat deze vraag over meerdere onderwerpen gaat leek dit me de beste categorie
Ik ben opzoek naar een manier om gebruikers/clients te kunnen identificeren. Ik zal de situatie even uitleggen.
In een jongerencentrum heb ik een systeem gebouwd waar de licht en geluid installatie te bedienen is via een pagina in een webbrowser. Deze pagina is gehost op een server die lokaal in het netwerk staat. De pagina is van buitenaf nu niet te bereiken. (Dat wil ik uiteindelijk wel, zodat ik problemen van afstand kan oplossen.)

Op dit moment laat ik de vrijwilligers naar de pagina surfen via een eenvoudige url (example.nl/techniek), daarin staat een iframe welke uiteindelijk naar de lokale server doorlinkt. Dit kan vanaf 2 PC's in de zaal worden bediend. Deze staan in een domein en worden regelmatig geupdate. Ik heb het deels te zeggen over deze PC's en kan zelf bepalen wat er op komt. Het is de bedoeling dat de pagina alleen te bereiken is voor de 2 pc's in de zaal.

Nu zoek ik dus een manier om deze pagina voor het bedienen van de installatie te beveiligen tegen mensen die ongewenst de installatie aan/uit o.i.d. willen zetten. Dat wil ik doen zonder wachtwoorden, dit ivm met veel verschillende vrijwilligers/gebruikers.

Er zijn een aantal manieren die ik al heb overwegen/geprobeerd heb
- Evercookie (Werkt matig. Laden duurt enorm lang, ivm silverlight/flash ed, en cookie werd niet altijd herkend.)
- Snelkoppeling met vast wachtwoord in URL.(Gebruikers wisten de URL te kopiëren en te misbruiken).
- Met PHP en de "$_SERVER['USER-AGENT'] op te vragen met nog wat variabelen en daarvan een unieke code te maken (Gaat niet werken omdat internet explorer en firefox word gebruikt. En het ip adres is niet altijd het zelfde)

Ik vroeg me dus af of er niet een stukje software bestaat wat ik op de client kan installeren en wat dan via de browser aan te roepen is om de bezoeker te kunnen identificeren. Eventueel een plugin in firefox of chrome?

Systeem is gemaakt met een licht besturingsprogramma Ecue. Daarin kan je een "Action-Pad" aan maken met knoppen. Deze is dus via een browser in het netwerk te bereiken en laad een flash applicatie met de knoppen.

[IceM]

Gewoon op basis van het (interne) ip adres van de client ($_SERVER['REMOTE_ADDR'])?

[HuHu]

Sowieso de mensen die het systeem misbruiken bestraffen en hun verantwoordelijkheden ontnemen.

[dev10]

Beveiligen op basis van enkel een IP-adres vind ik niet bepaald een goed idee. Kun je mij vertellen wat de exacte reden is dat je dit niet wilt beveiligen door middel van een wachtwoord? Ik vind het punt van veel verschillende gebruikers/vrijwilligers juist een argument om een wachtwoord te gebruiken. En dan wat HuHu zegt: bij misbruik rechten intrekken.

[Laurens-R]

Daarnaast is IP beveiliging niet goed genoeg als je bedenkt dat mensen achter een proxy kunnen zitten, een DHCP adres kunnen hebben en een IP relatief makkelijk te spoofen is (als men echt wil).

m.a.w. Je hebt nooit de garantie dat 1 IP adres altijd zal wijzen naar dezelfde client.

[ Voor 18% gewijzigd door Laurens-R op 27-05-2013 14:39 ]

[TheNephilim]

Wellicht is een 4-cijferige PIN een idee? Niet een ellenlang wachtwoord, maar wel iets wat je eventueel kunt wijzigen als er misbruik van gemaakt word. Ik zou niet inzetten op te zware beveiliging...

[Janoz]

Wat ik uit het verhaal opmaak is dat de beveiliging zo moet zijn dat de aansturing alleen vanaf 2 computers mag gebeuren. Een IP whitelist lijkt me dan juist wel een goede oplossing. Proxies zijn helemaal niet aan de orde, tenzij iemand een proxy weet te installeren op 1 van de twee PC's. het is dan alleen nog zaak om de DHCP zo in te richten dat die computers altijd dezelfde IP's krijgen (en dat deze niet aan anderen uitgedeeld worden)

[ Voor 20% gewijzigd door Janoz op 27-05-2013 14:42 ]

[storeman]

^ Met Janoz.

Een andere optie kan zijn om een Facebook account, openID of een andere openbare authenticatie te gebruiken waarmee men in kan loggen. Echter is puur op IP beveiligen wel het meest eenvoudig.

Verder zou je het wat obscuurder kunnen maken door de useragent van de firefox of een andere browser te modificeren en hier een bepaalde code in te zetten. Heel veilig is dit niet, maar 99% van de gebruikers zal het daar in ieder geval nooit zoeken.

[Hydra]

Wel een wachtwoord gebruiken en dat elke week aanpassen en met een postit op die 2 PCs plakken geen optie?

Janoz schreef op maandag 27 mei 2013 @ 14:41:
Wat ik uit het verhaal opmaak is dat de beveiliging zo moet zijn dat de aansturing alleen vanaf 2 computers mag gebeuren. Een IP whitelist lijkt me dan juist wel een goede oplossing. Proxies zijn helemaal niet aan de orde, tenzij iemand een proxy weet te installeren op 1 van de twee PC's. het is dan alleen nog zaak om de DHCP zo in te richten dat die computers altijd dezelfde IP's krijgen (en dat deze niet aan anderen uitgedeeld worden)

Sowieso kun je prima zien of een het een LAN IP betreft en deze in hetzelfde subnet zit. Lijkt me prima om, afgezien van een simpel wachtwoord, een dergelijke whitelist in te bouwen.

Wat ook nog kan is de gebruiker die de browser meestuurt (niet alle browsers doen dit, chrome wel geloof ik) te controleren.

[ Voor 84% gewijzigd door Hydra op 27-05-2013 15:31 ]

[HMS]

Het gebruik van een client side (SSL) certificate al overwogen?

[DiGyPh0]

Je kan ook met certifikaten gaan werken zoals hier beschreven.
Eventueel icm met een policy die het aanpassen van de internetopties in IE onmogelijk maakt

[Yoram]

Wat een reacties ineens, tof!

- Een erg zware beveiliging hoeft het idd niet te zijn, ik vind SSL en certificaten wel een klein beetje ver gaan maar ik ga het even wat beter bekijken. Het is dan wel goed beveiligd. Een 4 cijferige code is best een optie.

- Het punt dat ik het niet met wachtwoorden wil doen is omdat de meeste vrijwilligers slecht te bereiken zijn via mail o.i.d. daarom is een wachtwoord wat steeds veranderd niet handig. Goed voorbeeld is het spotify account van het jongerencentrum. Wachtwoord veranderd regelmatig maar toch gebruikt iedereen hem thuis ook(wat niet de bedoeling is), en als het wachtwoord veranderd is kan niemand mij vertellen wat het nou is.

- Via IP beveiligen lijkt mij zelf niks. Op alle pc's staat de DHCP aan en je gaat dan eigenlijk ook maar van 1 vast gegeven uit die niet altijd vast is.

Niet om het een of ander maar ik had HuHu z'n reactie eigenlijk al verwacht . Uit ervaring weet ik dat je het beter bij de bron kan aanpakken dus gewoon een slot erop zetten.

Het is een redelijk tot matig openbare ruimte dus er komen dagelijks meerdere mensen die niks met de installatie te maken hebben, dus post-its met het wachtwoord word hem niet .

[TRON]

Yoram schreef op maandag 27 mei 2013 @ 16:10:
Wat een reacties ineens, tof!

- Een erg zware beveiliging hoeft het idd niet te zijn, ik vind SSL en certificaten wel een klein beetje ver gaan maar ik ga het even wat beter bekijken. Het is dan wel goed beveiligd. Een 4 cijferige code is best een optie.

- Het punt dat ik het niet met wachtwoorden wil doen is omdat de meeste vrijwilligers slecht te bereiken zijn via mail o.i.d. daarom is een wachtwoord wat steeds veranderd niet handig. Goed voorbeeld is het spotify account van het jongerencentrum. Wachtwoord veranderd regelmatig maar toch gebruikt iedereen hem thuis ook(wat niet de bedoeling is), en als het wachtwoord veranderd is kan niemand mij vertellen wat het nou is.

- Via IP beveiligen lijkt mij zelf niks. Op alle pc's staat de DHCP aan en je gaat dan eigenlijk ook maar van 1 vast gegeven uit die niet altijd vast is.

Niet om het een of ander maar ik had HuHu z'n reactie eigenlijk al verwacht . Uit ervaring weet ik dat je het beter bij de bron kan aanpakken dus gewoon een slot erop zetten.

Het is een redelijk tot matig openbare ruimte dus er komen dagelijks meerdere mensen die niks met de installatie te maken hebben, dus post-its met het wachtwoord word hem niet .

Toch maar iedereen een persoonlijk account met een eigen wachtwoord waar ze dus zelf verantwoordelijk voor zijn?

[Janoz]

Yoram schreef op maandag 27 mei 2013 @ 16:10:
..

- Via IP beveiligen lijkt mij zelf niks. Op alle pc's staat de DHCP aan en je gaat dan eigenlijk ook maar van 1 vast gegeven uit die niet altijd vast is.
..

Wanneer je in je dhcp server (welke waarschijnlijk op de router draait) aangeeft dat die 2 PC's altijd hetzelfde IP moeten krijgen dan is dat gegeven behoorlijk vast hoor.

[HuHu]

Yoram schreef op maandag 27 mei 2013 @ 16:10:

Niet om het een of ander maar ik had HuHu z'n reactie eigenlijk al verwacht . Uit ervaring weet ik dat je het beter bij de bron kan aanpakken dus gewoon een slot erop zetten.

Mijns inziens ligt de bron van je probleem toch echt bij de mensen die er misbruik van maken en niet je applicatie.

[Hydra]

HuHu schreef op maandag 27 mei 2013 @ 16:52:
[...]

Mijns inziens ligt de bron van je probleem toch echt bij de mensen die er misbruik van maken en niet je applicatie.

Leuk hoor zo'n theoretische reactie maar in de praktijk ga je dat probleem niet zomaar oplossen.

[TheNephilim]

Janoz schreef op maandag 27 mei 2013 @ 16:38:
[...]

Wanneer je in je dhcp server (welke waarschijnlijk op de router draait) aangeeft dat die 2 PC's altijd hetzelfde IP moeten krijgen dan is dat gegeven behoorlijk vast hoor.

Dat is uiteraard de makkelijkste oplossing, al weet ik niet of hij wat met de router kan doen. Daarnaast, als ik zo de situatie lees, dan is er dus de kans dat er ongeoorloofd gebruik van de beide PC's is.

Maar... de TS heeft nu zoveel mogelijke opties aangereikt gekregen, moet een passende tussen zitten

[IceM]

Je wilt: toegang beperken tot je service tot twee systemen in een intern LAN.

Dan is toch de meest simpele én eenvoudige oplossing om dit te doen op basis van een IP adres zoals ik al aangaf? Je zorgt ervoor dat jou DHCP server die twee clients altijd hetzelfde IP adres geeft en klaar ben je.

Als dit niet voldoende is (bijvoorbeeld doordat gebruikers een MAC adres gaan spoofen en zo het interne IP adres krijgen) zul je de toegang moeten beperken met gebruikersaccounts, waarbij iedereen een eigen account krijgt. Alle andere methoden zijn namelijk niet zo eenvoudig te misbruiken.

[Janoz]

TheNephilim schreef op maandag 27 mei 2013 @ 19:03:
[...]


Dat is uiteraard de makkelijkste oplossing, al weet ik niet of hij wat met de router kan doen. Daarnaast, als ik zo de situatie lees, dan is er dus de kans dat er ongeoorloofd gebruik van de beide PC's is.

Ik ben benieuwd waar je dat uit leest. Het enige dat ik opmaak is dat TS het misbruik vanaf andere PC binnen het jongerencentrum wil voorkomen. Vandaar ook de eis dat het alleen toegankelijk is vanaf die 2 PC's.

[eM.]

Verreweg het makkelijkste in dit geval is filteren op ip. Maak gewoon een simpele beheer interface waarbij je eenvoudig het IP adres kan aanpassen, indien nodig.

Zelfs dat zou je kunnen automatiseren, door met curl script de DHCP clients uit de router te toveren. Maar goed dat schiet zn doel misschien een beetje voorbij:)

[Yoram]

Beetje verbaasd dat iedereen beveiligen op IP toch de beste optie vind.. Beetje PHP/javascript o.i.d. is niet de moeite voor mij. Dus had eigenlijk gehoopt dat er een manier was om clients te herkennen op een wat "geavanceerdere" manier. Een tooltje/plugin die niks anders doet dan een echt unieke code afgeeft welke ik kan uitlezen met behulp van JS o.i.d.

Ik had in mijn lange verhaal ook aangegeven dat ik het systeem later van buitenaf ook bereikbaar wil maken, dan gaat het hele IP verhaal niet op denk ik. Misschien moet ik dat via team viewer blijven doen, maakt de boel wel eenvoudiger.

Thx voor de reacties!

@TRON: Daar was ik ooit al mee begonnen. Een intranet om vrijwilligers uit te nodigen om te komen werken. Maar het punt dat de meeste vrijwilligers te stom zijn om in een mailtje op een link te klikken was voor mij de doorslag om het niet verder te ontwikkelen. (Ja het was echt een link met lettergrootte 50 ofzo )

@HuHu: wat hydra zegt .

@storeman: Via facebook is best een idee! Vrijwilligers weten toevallig wel hoe dat werkt dusja .

Ik kan zelf in alle onderdelen van het netwerk terecht, dus ook de router en overige servers.Onze router is zo'n graf apparaat van KPN waar je geen reed mee kan, zal een kijken of hij je ook adressen kan reserveren in de DHCP. Anders een overwegen om de DHCP via de server te laten lopen. Verder zitten alle pc's in een domein en zitten bijna potdicht.

[CH4OS]

Ik zou zeggen: geef de twee PC's in kwestie elk een eigen vast IP-adres. Vervolgens in de Apache config (als je Apache gebruikt natuurlijk!) in de vhost:

code:

Order Deny,Allow
Deny from all
Allow from 192.168.2.x
Allow from 192.168.2.y

Ik ben hierbij ervan uitgegaan dat de KPN router de IP-adressen uitdeeld, ook de KPN routers kunnen een static lease uitgeven.

Als je dat niet wilt, dan is de oplossing van TRON toch echt de beste. Dan leren de gebruikers dat maar (en dan is het inderdaad een probleem van de gebruiker en níet die van de applicatie). Als je mensen op hun wenken blijft bedienen, zal het alleen maar erger worden is mijn ervaring.

Sorry, maar als mensen een link in een e-mailtje niet kunnen aanklikken, dan vraag ik mij serieus af wat ze dan überhaupt achter een PC doen.

[ Voor 67% gewijzigd door CH4OS op 28-05-2013 14:09 ]

[P.O. Box]

Yoram schreef op dinsdag 28 mei 2013 @ 13:50:
Beetje verbaasd dat iedereen beveiligen op IP toch de beste optie vind.. Beetje PHP/javascript o.i.d. is niet de moeite voor mij. Dus had eigenlijk gehoopt dat er een manier was om clients te herkennen op een wat "geavanceerdere" manier. Een tooltje/plugin die niks anders doet dan een echt unieke code afgeeft welke ik kan uitlezen met behulp van JS o.i.d.

eigenlijk is iedere oplossing die niet IP adres georienteerd is, mijns inziens niet de juiste oplossing...

wat je zou kunnen doen is een DLL schrijven die een hardwareID genereert op basis van een aantal eigenschappen van de clientPC (MAC, whatever)... deze DLL moet op de website gebruikt worden en dus geinstalleerd worden zodra de gebruiker de website bezoekt... via een validatie lijst kun je dan kijken of de betreffende hardwareID toegang heeft....

desalniettemin vind ivind het allemaal wat omslachtig en overdreven... je geeft al aan dat de beveiliging niet erg zwaar hoeft te zijn... beveiliging op vaste IP adressen is dan de manier... als het toch allemaal van die digibetische vrijwilligers zijn die de boel gebruiken, lijkt me van IP spoofing nou niet zo snel sprake...

[Janoz]

Yoram schreef op dinsdag 28 mei 2013 @ 13:50:
Beetje verbaasd dat iedereen beveiligen op IP toch de beste optie vind.. Beetje PHP/javascript o.i.d. is niet de moeite voor mij. Dus had eigenlijk gehoopt dat er een manier was om clients te herkennen op een wat "geavanceerdere" manier. Een tooltje/plugin die niks anders doet dan een echt unieke code afgeeft welke ik kan uitlezen met behulp van JS o.i.d.

"Ik kan heel goed auto merken en types herkennen en gecombineerd met de kleur en de velgen van die auto kun je ze al vrij goed uit elkaar houden. Het verbaasd me dan ook dat iedereen hier zewgt dat ik dat beter met het nummerbord kan doen"

Ik had in mijn lange verhaal ook aangegeven dat ik het systeem later van buitenaf ook bereikbaar wil maken, dan gaat het hele IP verhaal niet op denk ik. Misschien moet ik dat via team viewer blijven doen, maakt de boel wel eenvoudiger.

Dat sluit elkaar zeker neit uit. Zoals hierboven ook al aangegeven heb je zelfs helemaal geen php nodig. Dit kan allemaal gewoon met apache. Ik zag dat je een iframe gebruikt? Dat is eigenlijk ook niet meer nodig. Je kunt gewoon een reversed proxy in apache gebruiken. Klinkt ingewikkeld, is het niet. Ikzelf gebruik het om bijvoorbeeld Sabnzbd en Transmission beschikbaar te maken via dezelfde webserver, waarbij er via het interne netwerk helemaal geen wachtwoord nodig is en voor externe toegang juist wel.