[vraagje] reactid

[BasieP]

hoi beste mensen,

zoals ik uit meerdere topics hier op got heb vernomen is het reactID niet iets om mee te koop te lopen, ik heb verschillende verhalen over rss feeds gelezen en de daarbij behorende risico's

nu zag ik dat wanneer ik uit wil loggen, al mijn reactID's voor het oprapen liggen.
natuurlijk moet ik dan wel ingelogt zijn.

Is het nu niet zo dat als ik een keer vergeet uit te loggen ergens en iemand kan bij mijn (niet uitgelogde) account, nu is dat opzich geen ramp, want ik kom thuis, en denk, 'he ff me account op school uitloggen, want dat was ik vergeten'

dan klik ik de derde optie aan, en delete alle sessions behalve deze.
als iemand op school nu mijn reactid's heeft gekopieerd, kan hij ze gewoon 1 voor 1 in een cookie stoppen en uitproberen volgens mij

is dit niet een groot security risk? zouden die react ID's daar wel zichtbaar moeten zijn?
wij als gebruikers hebben er toch niks aan om ze te zien, en zelfs modjes doen er niks mee, dus waarom staan ze daar?

[Verwijderd]

Ik weet niet of dat zo kan, maar ik ben het wel met je eens Misschien is het verstandig om een zoiets te doen als: "Onder deze account zijn x actieve sessies" en dan wel met dezelfde opties?

[BasieP]

Verwijderd schreef op dinsdag 13 december 2005 @ 22:22:
Ik weet niet of dat zo kan, maar ik ben het wel met je eens Misschien is het verstandig om een zoiets te doen als: "Onder deze account zijn x actieve sessies" en dan wel met dezelfde opties?

ja zoiets idd,

ikzelf ben nu bezig met een forum met een soortgelijk systeem, en wil dus dat users 1 specifieke sessie kunnen uitloggen. Nu kan ik geen andere info bedenken als ip adres waarop sessie begonnen is, en de tijd waarop sessie verloopt, (en dan dingen als hits enzo) maar ik denk dat die mensen van react ook zoiets hadden en elke sessie uniek wilden laten zien.. maar of het verstandig is..

[Harm]

Als je bent uitgelogd, dan zijn je reactID's niet meer geldig en kan je er dus niets mee. Op het moment dat iemand je reactID's kan zien op de uitlogpagina, kan die persoon toch al volledig gebruikmaken van je account, dus dan is dat ook geen extra securityprobleem IMHO.

[BasieP]

@Harm, als ik niet uitlog, maar vergeet uit te loggen kan die gebruiker dus al! mjin sessies gebruiken..

als ik dan optie 3 gebruik en alle behalve deze sessie uitlog op een andere pc, dan heeft die persoon nog steeds mijn huidige sessie (reactID) in handen, en kan deze misbruiken.

trouwens stel ik deze vraag ook vanuit mijn idee (zie ^^) omdat ik per sessie wil kunnen uitloggen. Zo kan het dus zo zijn dat een user dus zegt 'ow ik log alle sessies uit met het school-ip', en dan denkt dat ie safe zit.
Dit is dan natuurlijk niet zo (als je sessieID laat zien dan)

[AW_Bos]

Het lijkt me dat Crisp als hij zin/tijd heeft de ReactID's kan deels voorzien van sterretjes ofzo...
Dat doet BaseGrey in GoT dacht ik ook. Het is dat ik geen abo heb om het te controleren....

[Outerspace]

AW_Bos schreef op dinsdag 13 december 2005 @ 22:43:
Het lijkt me dat Crisp als hij zin/tijd heeft de ReactID's kan deels voorzien van sterretjes ofzo...
Dat doet BaseGrey in GoT dacht ik ook. Het is dat ik geen abo heb om het te controleren....

FYI: met mijn template iig niet en andere ook niet

[ Voor 6% gewijzigd door Outerspace op 13-12-2005 22:48 ]

[justmental]

BasieP schreef op dinsdag 13 december 2005 @ 22:32:
@Harm, als ik niet uitlog, maar vergeet uit te loggen kan die gebruiker dus al! mjin sessies gebruiken..

als ik dan optie 3 gebruik en alle behalve deze sessie uitlog op een andere pc, dan heeft die persoon nog steeds mijn huidige sessie (reactID) in handen, en kan deze misbruiken.

trouwens stel ik deze vraag ook vanuit mijn idee (zie ^^) omdat ik per sessie wil kunnen uitloggen. Zo kan het dus zo zijn dat een user dus zegt 'ow ik log alle sessies uit met het school-ip', en dan denkt dat ie safe zit.
Dit is dan natuurlijk niet zo (als je sessieID laat zien dan)

In zo'n geval kun je toch gewoon alle sessies uitloggen

[crisp]

Sowieso, als je de mogelijkheid hebt, is het verstandig je sessie aan je IP te koppelen.
De frontpage login (wat na de merge de algemene login gaat worden) bied verder ook de mogelijkheid om je maximale sessieduur (kort) in te stellen - ideaal voor openbare gelegenheden.
Sessie-id's in het overzicht deels van sterretjes voorzien is wel een idee though

[BasieP]

crisp schreef op dinsdag 13 december 2005 @ 22:55:
Sowieso, als je de mogelijkheid hebt, is het verstandig je sessie aan je IP te koppelen.
De frontpage login (wat na de merge de algemene login gaat worden) bied verder ook de mogelijkheid om je maximale sessieduur (kort) in te stellen - ideaal voor openbare gelegenheden.
Sessie-id's in het overzicht deels van sterretjes voorzien is wel een idee though

maar hebben ze nog een functie dan?
ik bedoel waarom laat je ze in de eerste plaats zien?

[Erkens]

crisp schreef op dinsdag 13 december 2005 @ 22:55:
Sessie-id's in het overzicht deels van sterretjes voorzien is wel een idee though

en dat vind ik dan weer niet handig.
Ik gebruik die ID's namelijk voor een scriptje wat ik geschreven heb (voor mijn sig o.a.) en daar moet ik dus dat reactid invullen. En dan kan het wel handig zijn als ik weet hoe dat ID geheel is

Overigens lijkt me dat als je al vergeten bent uit te loggen dat je dan toch echt zelf een probleem hebt gecreerd. Iedereen die dan gebruik maakt van die PC kan dan al je account gebruiken. En ja, ook die ReactID's lezen. Maar zodra je bij logout zegt alles uitloggen behalve deze (wat je imo ook moet doen als je vergeten bent uit te loggen) dan is er niks meer aan de hand en kan die persoon er ook niets meer mee

[Voutloos]

Als je snapt dat alle reactId's exposed kunnen zijn, lijkt mij het gewoon meer dan logisch dat je alles uitlogt.

Dit is net alsof ik 1 sleutel van je sleutelbos kopieer en dat jij dan alle sloten behalve 1 gaat vervangen.

[ Voor 35% gewijzigd door Voutloos op 13-12-2005 23:03 ]

[crisp]

BasieP schreef op dinsdag 13 december 2005 @ 22:59:
[...]


maar hebben ze nog een functie dan?
ik bedoel waarom laat je ze in de eerste plaats zien?

Voor sommigen is het toch een herkenningspunt, maar dat hebben we ondertussen al geprobeert te ondervangen met een optioneel 'locatie'-veld bij het inloggen op de frontpage.

Erkens: er zijn meer manieren om je huidige ReactID te achterhalen hoor

[ Voor 10% gewijzigd door crisp op 13-12-2005 23:05 ]

[Erkens]

BasieP schreef op dinsdag 13 december 2005 @ 22:59:
ik bedoel waarom laat je ze in de eerste plaats zien?

om de verschillende sessies te kunnen identificeren, en voor het gebruik in custom scriptjes voor de XML/RSS feeds

[Harm]

Mjah, daarvoor zijn dus ook wel andere manieren te vinden .

[BasieP]

Erkens schreef op dinsdag 13 december 2005 @ 23:01:...
Overigens lijkt me dat als je al vergeten bent uit te loggen dat je dan toch echt zelf een probleem hebt gecreerd. Iedereen die dan gebruik maakt van die PC kan dan al je account gebruiken. En ja, ook die ReactID's lezen. Maar zodra je bij logout zegt alles uitloggen behalve deze (wat je imo ook moet doen als je vergeten bent uit te loggen) dan is er niks meer aan de hand en kan die persoon er ook niets meer mee

das dus niet waar, lees me post maar even door hierboven

verder zijn er idd meer manier om achter een react ID te komen (cookie bijv), en dan bedoel ik dus alleen het reactID van de HUIDIGE sessie, en niet ALLE

dat is nl. wat gevaarlijk is.

[Valor]

Ik zie het nut er niet echt van in om reactID weer te geven. Net of een gebruiker geinterresteert is in een een of andere hash

[Erkens]

BasieP schreef op dinsdag 13 december 2005 @ 23:18:
das dus niet waar, lees me post maar even door hierboven

dan zeg je dat je alles wilt uitloggen als je zo paranoide bent
je hebt immers zelf de fout gemaakt om niet uit te loggen toch?
En waarom lock je je sessies niet op IP? Dan heb je _dat_ probleem ook niet

Ik zou het persoonlijk jammer vinden als dit overzicht zal verdwijnen, want ik gebruik het nog wel eens.

Valor schreef op dinsdag 13 december 2005 @ 23:25:
Ik zie het nut er niet echt van in om reactID weer te geven. Net of een gebruiker geinterresteert is in een een of andere hash

ja, dus wel

[ Voor 21% gewijzigd door Erkens op 13-12-2005 23:30 ]

[Valor]

Erkens schreef op dinsdag 13 december 2005 @ 23:30:
[...]

ja, dus wel

Uhm hier heb je wat aan. Geef tekst en uitleg waarom je dat vind. Aan "ja, dus wel" heb je geen reet

En het overzicht kan best blijven alleen is de hash weergeven een niet logische stap. Je geeft vitale informatie vrij die het forum gebruikt om bij te houden wij jij bent. Dat moet een gebruiker helemaal niet weten!

[ Voor 32% gewijzigd door Valor op 13-12-2005 23:36 ]

[_eXistenZ_]

Even voor de duidelijkheid, gaat het over het sessieID?

[Valor]

eXistenZ_NL schreef op dinsdag 13 december 2005 @ 23:36:
Even voor de duidelijkheid, gaat het over het sessieID?

SessionID en reactID is niet gelijk. als je het over PHPSESSIONID hebt teminste

[crisp]

eXistenZ_NL schreef op dinsdag 13 december 2005 @ 23:36:
Even voor de duidelijkheid, gaat het over het sessieID?

jep, dat ding heet in je cookie 'ReactID' (en na de merge 'TNETID')

Valor schreef op dinsdag 13 december 2005 @ 23:37:
[...]


SessionID en reactID is niet gelijk. als je het over PHPSESSIONID hebt teminste

Wij gebruiken geen PHP sessions maar een eigen sessie-systeem, waarvan de ReactID de sessie-identifier is

[ Voor 41% gewijzigd door crisp op 13-12-2005 23:38 ]

[moto-moi]

crisp schreef op dinsdag 13 december 2005 @ 22:55:
Sessie-id's in het overzicht deels van sterretjes voorzien is wel een idee though

Het is denk ik logischer om alle sessie-id's visueel te maskeren, op de huidige na, dan heeft iemand die het nodig heeft ( a la Erkens ) ook geen problemen om erachter te komen en is het effect, zolang iemand maar op IP locked nihil.

Dat IP locken, kan dat niet es standaard aangezet worden?

[Superdeboer]

moto-moi schreef op woensdag 14 december 2005 @ 00:23:
Dat IP locken, kan dat niet es standaard aangezet worden?

Daar ben ik het volledig mee eens. Het schept een stuk extra veiligheid en we mogen aannemen dat inmiddels verreweg de minderheid via proxies met wisselende IP's of inbeldverbindingen surft. Die mensen moeten dan maar de moeite nemen om dat vinkje uit te zetten IMO.

Safety first.

[BasieP]

Superdeboer schreef op woensdag 14 december 2005 @ 00:30:
[...]

Daar ben ik het volledig mee eens. Het schept een stuk extra veiligheid en we mogen aannemen dat inmiddels verreweg de minderheid via proxies met wisselende IP's of inbeldverbindingen surft. Die mensen moeten dan maar de moeite nemen om dat vinkje uit te zetten IMO.

Safety first.

leuk voor mensen met laptops die af en toe toch echt een ander ip hebben

(maar hij kan natuurlijk ook uitgevinkt worden)

[Erkens]

moto-moi schreef op woensdag 14 december 2005 @ 00:23:
Het is denk ik logischer om alle sessie-id's visueel te maskeren, op de huidige na, dan heeft iemand die het nodig heeft ( a la Erkens ) ook geen problemen om erachter te komen en is het effect, zolang iemand maar op IP locked nihil.

ehm, de huidige reactid boeit met niet, ik wil namelijk voor mijn script een andere sessie hebben waardoor ik inlog en dan mijn cookies trash, zodat ik hem eenvoudig er weer uit kan vissen.
Persoonlijk zie ik het hele probleem ook niet eigenlijk. Als je al zo dom geweest bent om niet uit te loggen en verder niet locked op IP dan is het imo je eigen domme schuld. Maar gelukkig is er dan nog de optie om alle sessies uit te loggen, waardoor niemand nog wat aan die sessie ID's heeft.

Valor schreef op dinsdag 13 december 2005 @ 23:32:
Uhm hier heb je wat aan. Geef tekst en uitleg waarom je dat vind. Aan "ja, dus wel" heb je geen reet

anders lees je het topic even

En het overzicht kan best blijven alleen is de hash weergeven een niet logische stap. Je geeft vitale informatie vrij die het forum gebruikt om bij te houden wij jij bent. Dat moet een gebruiker helemaal niet weten!

nou, vitale informatie is dat hoor
kijk in je cookies en je ziet je huidige reactid, kijk in de cookies van alle browsers waar je bent ingelogt en je hebt ze allemaa in theorie
Daarnaast zijn wij tweakers

[chem]

moto-moi schreef op woensdag 14 december 2005 @ 00:23:
[...]

Dat IP locken, kan dat niet es standaard aangezet worden?

Nou dat heeft wel voeten in de aarde hoor... helemaal een checked="checked" toevoegen, the horror!

ja dus, en tegenwoordig is het aantal gebruikers met een dynamisch IP op een hand te tellen (hoop ik voor die doelgroep).

[BasieP]

Erkens schreef op woensdag 14 december 2005 @ 09:09:
nou, vitale informatie is dat hoor
kijk in je cookies en je ziet je huidige reactid, kijk in de cookies van alle browsers waar je bent ingelogt en je hebt ze allemaa in theorie
Daarnaast zijn wij tweakers

lees jij het hele topic anders ook ff.
de enige plek waar ik react id's kan zien van andere logins (andere pc's) is in dat scherm.
de huidige is vaker op te vragen, en daar maak ik me ook niet zo druk over. het gaat juist om die andere.

verder zit je de hele tijd over je script enzo te 'zeuren', maar ik kan zo al 2 manieren bedenken hoe je het netjes kan oplossen.
1: gewoon je script laten inloggen (zodat je cookie ontvangt etc.)
2: voor het veranderen van je sig heb je sowieso reactID niet nodig, je kan ook gewoon je password versturen (vanuit hier dus: http://gathering.tweakers.net/forum/edit_user)

[ Voor 15% gewijzigd door BasieP op 14-12-2005 09:53 ]

[crisp]

chem schreef op woensdag 14 december 2005 @ 09:41:
[...]

Nou dat heeft wel voeten in de aarde hoor... helemaal een checked="checked" toevoegen, the horror!

gewoon checked is genoeg hoor, wij doen niet mee aan de XHTML-farce

BasieP schreef op woensdag 14 december 2005 @ 09:52:
[...]

lees jij het hele topic anders ook ff.
de enige plek waar ik react id's kan zien van andere logins (andere pc's) is in dat scherm.
de huidige is vaker op te vragen, en daar maak ik me ook niet zo druk over. het gaat juist om die andere.

verder zit je de hele tijd over je script enzo te 'zeuren', maar ik kan zo al 2 manieren bedenken hoe je het netjes kan oplossen.
1: gewoon je script laten inloggen (zodat je cookie ontvangt etc.)
2: voor het veranderen van je sig heb je sowieso reactID niet nodig, je kan ook gewoon je password versturen (vanuit hier dus: http://gathering.tweakers.net/forum/edit_user)

Je hebt wel degelijk een geldig ReactID nodig, anders wordt het formulier afgekeurd...

[chem]

crisp schreef op woensdag 14 december 2005 @ 09:54:
[...]

Je hebt wel degelijk een geldig ReactID nodig, anders wordt het formulier afgekeurd...

idd, automatisch inloggen (wat in 194 bij alle acties kan) vereist nog altijd eerst een geldig reactid.

[Erkens]

BasieP schreef op woensdag 14 december 2005 @ 09:52:
lees jij het hele topic anders ook ff.
de enige plek waar ik react id's kan zien van andere logins (andere pc's) is in dat scherm.
de huidige is vaker op te vragen, en daar maak ik me ook niet zo druk over. het gaat juist om die andere.

ja maar alleen _jij_ kan die zien, tenzij je een domme fout hebt gemaakt, en daarom moet die handige feature maar weg welke _jij_ toevallig niet gebruikt

verder zit je de hele tijd over je script enzo te 'zeuren', maar ik kan zo al 2 manieren bedenken hoe je het netjes kan oplossen.
1: gewoon je script laten inloggen (zodat je cookie ontvangt etc.)
2: voor het veranderen van je sig heb je sowieso reactID niet nodig, je kan ook gewoon je password versturen (vanuit hier dus: http://gathering.tweakers.net/forum/edit_user)

1. Lekker handig iedere keer opnieuw inloggen ipv gewoon 1 req naar de server, en hoe wil je dat doen met RSS readers bijvoorbeeld? of XML parsers
2. die heb je dus ook nodig, dat had ik al geprobeerd.

[Bor]

Kan iemand misschien uitleggen wat uberhaubt het nut is van het laten zien van het reactid bij het uitlogscherm?

[chem]

Bor de Wollef schreef op woensdag 14 december 2005 @ 10:56:
Kan iemand misschien uitleggen wat uberhaubt het nut is van het laten zien van het reactid bij het uitlogscherm?

vanaf 1.9.4 kan je specifieke sessies uitloggen.

[silverstorm]

/me kijkt parse lief aan
krijgen we ook een locatie veldje zoals als op de frontpage van T.net? Ik vind hem persoonlijk wel handig.

[crisp]

silverstorm schreef op woensdag 14 december 2005 @ 12:35:
/me kijkt parse lief aan
krijgen we ook een locatie veldje zoals als op de frontpage van T.net? Ik vind hem persoonlijk wel handig.

Die krijg je sowieso aangezien na de merge enkel de frontpage login nog maar gebruikt gaat worden

[silverstorm]

/me aait crips
Ohhjah is waar ook.

[BasieP]

Erkens schreef op woensdag 14 december 2005 @ 10:14:
[...]

ja maar alleen _jij_ kan die zien, tenzij je een domme fout hebt gemaakt, en daarom moet die handige feature maar weg welke _jij_ toevallig niet gebruikt

um is leuk dat je nu alles op mij gooit, maar ikzelf heb er nooit problemen mee, maar ik ben wel iemand die meedenkt met anderen.
Ik kan me voorstellen dat iemand het idee heeft dat ie veilig is als ie 'overal behavle hier' uitlogt. terwijl dit dus niet zo is.

1. Lekker handig iedere keer opnieuw inloggen ipv gewoon 1 req naar de server, en hoe wil je dat doen met RSS readers bijvoorbeeld? of XML parsers
2. die heb je dus ook nodig, dat had ik al geprobeerd.

1: welk deel van 'cookie' is nou niet duidelijk?
2: die staat dus IN dat cookie

[crisp]

[Erkens]

BasieP schreef op woensdag 14 december 2005 @ 22:57:
um is leuk dat je nu alles op mij gooit, maar ikzelf heb er nooit problemen mee, maar ik ben wel iemand die meedenkt met anderen.
Ik kan me voorstellen dat iemand het idee heeft dat ie veilig is als ie 'overal behavle hier' uitlogt. terwijl dit dus niet zo is.

die optie moet je dus ook alleen gebruiken als je huidige sessie gelocked is op je IP

1: welk deel van 'cookie' is nou niet duidelijk?

welk deel van 'extra requests naar de server terwijl dat overbodig is' is nou niet duidelijk?

2: die staat dus IN dat cookie

nee, jij zei dat je daar geen reactid nodig had, nu moet je het niet gaan verdraaien

Het feit is gewoon dat sommige mensen gewoon dat lijstje willen hebben. Het is helemaal niet onveilig, iig niet zolang je je sessies locked op je IP en bovenal uiteraard altijd uitloggen op public pc's.

Wat wel kan (en ook al genoemd is) is het default locken op IP.
Verder zou er misschien een optie kunnen komen speciaal voor public pc's zoals je die ook op andere sites tegen komt, waarbij je sessie loopt tot het afsluiten van de browser (browser sessies) waarbij je ook dat puntje van "ben per ongeluk nog ingelogt" oplost. (eventueel voor de paranoide personen dat zodra je die optie aan hebt dat je geen reactid's ziet)

[ Voor 3% gewijzigd door Erkens op 14-12-2005 23:06 ]

[Erkens]

crisp schreef op woensdag 14 december 2005 @ 23:04:
<input type="button" value="Wat is mijn ReactID?" style="background-color:#cecece" onclick="alert('Je ReactID is: '+GetCookie('ReactID'))">

en nu van mijn andere sessies, wat dus niet kan zonder dat lijstje.
De huidige is niet zo boeiend voor mij, ik wil namelijk alles een beetje gescheiden houden

[Bor]

chem schreef op woensdag 14 december 2005 @ 11:22:
[...]

vanaf 1.9.4 kan je specifieke sessies uitloggen.

Dat weet ik maar is een ip adres niet veel makkelijker als identificatie van de sessie? Een reactid zegt de gemiddelde GoT user niets denk ik.

[Erkens]

Bor de Wollef schreef op woensdag 14 december 2005 @ 23:09:
[...]


Dat weet ik maar is een ip adres niet veel makkelijker als identificatie van de sessie? Een reactid zegt de gemiddelde GoT user niets denk ik.

Nee een IP is handig als je meerdere browsers/pc's hebt via NAT of een proxy Daarnaast staat dat IP er al als je de sessie locked, anders weet React natuurlijk niet welk IP erbij hoort, behalve het laatst gebruikte.

[BasieP]

Bor de Wollef schreef op woensdag 14 december 2005 @ 23:09:
[...]


Dat weet ik maar is een ip adres niet veel makkelijker als identificatie van de sessie? Een reactid zegt de gemiddelde GoT user niets denk ik.

mja zo zit zoiets nou eenmaal niet in elkaar.
je kan wel een ip adres hashen ofzo, maar als je puur op ip doet betekent dat dat alle users op dat ip opeens dezelfde sessie hebben

en als jij een laptop heb en dan hier dan daar je internet uit de lucht haalt dan heb je niet hetzelfde ip.

ik denk dat de hash nu zoiets is als userid, password en een time ofzo
dat hash je samen, en dan kom je tot een unique hash per gebruiker op dat moment.
verder kan je dus dmv dat vinkje, je ipadres mee laten hashen, en dan moet je dus ook nog op die connectie zitten.

@erkens, met jouw praat ik niet meer, jij verdraait mijn worden en zegt ondertussen dat ik het van jouw doe.. lees nou eens mens

[crisp]

Erkens: misschien moet je het geheel in een wat groter plaatje zien en niet alleen denken aan je eigen belang waarbij het wat lastiger wordt om een sessie-id te achterhalen die je voor je eigen tool wilt gebruiken.

Een gulden middenweg - naast het default locken op IP - zou zijn enkel sessie-id's die niet gelocked zijn op IP (deels) te maskeren in het overzicht.

[Erkens]

BasieP schreef op woensdag 14 december 2005 @ 23:13:
@erkens, met jouw praat ik niet meer, jij verdraait mijn worden en zegt ondertussen dat ik het van jouw doe.. lees nou eens mens

ik wil hier geen ruzie maken, maar ten eerste verdraai ik jouw woorden niet en zeg ik al helemaal niet dat jij mijn woorden verdraaid. Verder kan je wel even wat vriendelijker reageren.

[Erkens]

crisp schreef op woensdag 14 december 2005 @ 23:14:
Erkens: misschien moet je het geheel in een wat groter plaatje zien en niet alleen denken aan je eigen belang waarbij het wat lastiger wordt om een sessie-id te achterhalen die je voor je eigen tool wilt gebruiken.

Als ik niet aan mijn eigen belang denk, dan doet niemand dat en zal deze feature kunnen verdwijnen.
Ik zie uiteraard wel dat het een security probleem _kan_ zijn. Maar ik zie ook dat dat probleem niet ligt bij de software hier maar bij de gebruiker die niet zijn sessies locked en tevens onzorgvuldig met zijn sessies omgaat.

Een gulden middenweg - naast het default locken op IP - zou zijn enkel sessie-id's die niet gelocked zijn op IP (deels) te maskeren in het overzicht.

mja, kan, maar ik heb zelf mijn bot een non-locked reactid gegeven vanwege mijn o zo mooie "vaste ip" van chello. dus ik zou er dan persoonlijk niks aan hebben.

Wat vond je van mijn idee met die tijdelijke "public pc" sessies?

[Bor]

BasieP schreef op woensdag 14 december 2005 @ 23:13:
[...]

mja zo zit zoiets nou eenmaal niet in elkaar.
je kan wel een ip adres hashen ofzo, maar als je puur op ip doet betekent dat dat alle users op dat ip opeens dezelfde sessie hebben

Dat snap ik natuurlijk. Wat ik bedoel is dat je de sessies "cosmetisch" identificeert aan de hand van het ip adres waarvan deze is gestart. Een ip adres zegt een user meer dan een reactid neem ik aan. Dat er aan die cosmetische waarde een reactid hangt is voor een user niet interessant. Het zegt mij namelijk niet of dit bv op mijn werk is, in het internet cafe waar ik vergat uit te loggen etc.

[ Voor 10% gewijzigd door Bor op 14-12-2005 23:24 ]

[BasieP]

Erkens schreef op woensdag 14 december 2005 @ 23:20:
[...]

Als ik niet aan mijn eigen belang denk, dan doet niemand dat en zal deze feature kunnen verdwijnen.
Ik zie uiteraard wel dat het een security probleem _kan_ zijn. Maar ik zie ook dat dat probleem niet ligt bij de software hier maar bij de gebruiker die niet zijn sessies locked en tevens onzorgvuldig met zijn sessies omgaat.

ergens heb je daar gelijk, maar zullen we dan ook direct maar het bevestig veldje bij het wijzigen van profiel maar weghalen? en ach expire time kan dan ook wel op oneindig.. want he.. het is toch dom als je vergeet jezelf uit te logen?

ow btw, waarom zou je dan remote moeten kunnen uitloggen? zoiets doe je toch voordat je van die pc wegloopt? anders ben je maar dom en is het je eigen schuld..

zoiets is gewoon vragen om problemen imho

Bor de Wollef schreef op woensdag 14 december 2005 @ 23:23:
Dat snap ik natuurlijk. Wat ik bedoel is dat je de sessies "cosmetisch" identificeert aan de hand van het ip adres waarvan deze is gestart. Een ip adres zegt een user meer dan een reactid neem ik aan. Dat er aan die cosmetische waarde een reactid hangt is voor een user niet interessant.

ah zo, dan begreep ik dat idd verkeerd

ja ik ben het er mee eens, maar dan moet je wel expliciet erbij zetten dat het het start-ip is.
(trouwens heb ik dat ook zelf zo op me eigen forumpje in ontwikkeling)

[ Voor 26% gewijzigd door BasieP op 14-12-2005 23:25 ]

[Erkens]

Bor de Wollef schreef op woensdag 14 december 2005 @ 23:23:
Dat snap ik natuurlijk. Wat ik bedoel is dat je de sessies "cosmetisch" identificeert aan de hand van het ip adres waarvan deze is gestart. Een ip adres zegt een user meer dan een reactid neem ik aan. Dat er aan die cosmetische waarde een reactid hangt is voor een user niet interessant. Het zegt mij namelijk niet of dit bv op mijn werk is, in het internet cafe waar ik vergat uit te loggen etc.

crisp schreef op dinsdag 13 december 2005 @ 23:03:
Voor sommigen is het toch een herkenningspunt, maar dat hebben we ondertussen al geprobeert te ondervangen met een optioneel 'locatie'-veld bij het inloggen op de frontpage.

wat na de merge natuurlijk ook voor GoT geld

[Erkens]

BasieP schreef op woensdag 14 december 2005 @ 23:24:
ergens heb je daar gelijk, maar zullen we dan ook direct maar het bevestig veldje bij het wijzigen van profiel maar weghalen? en ach expire time kan dan ook wel op oneindig.. want he.. het is toch dom als je vergeet jezelf uit te logen?

ow btw, waarom zou je dan remote moeten kunnen uitloggen? zoiets doe je toch voordat je van die pc wegloopt? anders ben je maar dom en is het je eigen schuld..

zoiets is gewoon vragen om problemen imho

Die opties zijn er natuurlijk omdat er altijd wel een mogelijkheid is dat je het vergeet om uit te loggen, heb het zelf ook gehad lang geleden, en dan is het fijn om die optie te hebben.
Gezien het feit dat er bij het lijstje tijden van de laatste request staan kan je eenvoudig zien of iemand je sessie heeft gebruikt, dus aan de hand daarvan kan je bepalen om al je sessies te beeindigen of alleen die ene (wat nu nog "alle andere" is).

[eamelink]

Erkens schreef op woensdag 14 december 2005 @ 23:20:
Maar ik zie ook dat dat probleem niet ligt bij de software hier maar bij de gebruiker die niet zijn sessies locked en tevens onzorgvuldig met zijn sessies omgaat.

Dat ben ik niet met je eens. De optie "Alles uitloggen behalve deze PC" suggereert dat je account veilig is als je dat doet. En die veiligheid is er dus niet, want iemand kan je ReactID overgeschreven hebben.

Onterecht veiligheid suggereren is wel degelijk een software probleem.

Niet zo ernstig though .

Als we toch aan het featurerequesten zijn zou de mogelijkheid tot het toevoegen van meerdere ip's aan één sessie wel handig zijn; ik verhuis met mijn laptop tussen twee locaties, dus ik kan niet op ip locken.

[crisp]

Erkens schreef op woensdag 14 december 2005 @ 23:20:
[...]

Als ik niet aan mijn eigen belang denk, dan doet niemand dat en zal deze feature kunnen verdwijnen.
Ik zie uiteraard wel dat het een security probleem _kan_ zijn. Maar ik zie ook dat dat probleem niet ligt bij de software hier maar bij de gebruiker die niet zijn sessies locked en tevens onzorgvuldig met zijn sessies omgaat.

Maar hoe kom je nu dan aan dat sessie-id? Ik neem aan dat je daarvoor inlogt en daarna je cookie trashed? Dan kan je toch voordat je de cookie trashed daaruit de ReactID halen? Waarvoor heb je daarna dan nog het overzicht nodig - je weet het ID dan toch?

Wat vond je van mijn idee met die tijdelijke "public pc" sessies?

Op zich is de inlog optie vwb sessie-duur op de frontpage wel uit te breiden met een optie 'alleen deze browsersessie' - de cookie wordt dan niet permanent opgeslagen. Wel moeten we dan serverside toch een expiration geven aan de sessie zodat hij ook serverside na verloop van x tijd wordt opgeruimt, maar dat is ook nog wel te doen.

[crisp]

eamelink schreef op woensdag 14 december 2005 @ 23:32:
[...]
Als we toch aan het featurerequesten zijn zou de mogelijkheid tot het toevoegen van meerdere ip's aan één sessie wel handig zijn; ik verhuis met mijn laptop tussen twee locaties, dus ik kan niet op ip locken.

Dat is technisch gezien niet echt haalbaar, zeker vanuit performance oogpunt niet.

[NMe]

crisp schreef op woensdag 14 december 2005 @ 23:14:
Erkens: misschien moet je het geheel in een wat groter plaatje zien en niet alleen denken aan je eigen belang waarbij het wat lastiger wordt om een sessie-id te achterhalen die je voor je eigen tool wilt gebruiken.

Een gulden middenweg - naast het default locken op IP - zou zijn enkel sessie-id's die niet gelocked zijn op IP (deels) te maskeren in het overzicht.

Waarom niet standaard de sessie-ID's geheel weglaten in dat overzicht, en deze daarna opvraagbaar maken op een andere pagina waarvoor je eerst je wachtwoord moet invullen?

[Erkens]

crisp schreef op woensdag 14 december 2005 @ 23:34:
Maar hoe kom je nu dan aan dat sessie-id? Ik neem aan dat je daarvoor inlogt en daarna je cookie trashed? Dan kan je toch voordat je de cookie trashed daaruit de ReactID halen? Waarvoor heb je daarna dan nog het overzicht nodig - je weet het ID dan toch?

heb je opzich gelijk in natuurlijk, alleen dat is veel meer werk dan inloggen, cookies trashen, inloggen en dan copy/pasten van de logout page. En waarom zou ik dat lijstje moeten bijhouden als jullie die ook hebben (en die van jullie klopt altijd)

Verder vraag ik me af hoeveel misbruik er op deze manier mee geweest is?
Als ik nogmaals de TS lees, is het probleem eigenlijk alleen de optie "alle behalve de huidige" is. Wellicht die optie uitschakelen als de huidige sessie _niet_ gelocked is?