[Openstandaarden] nieuws van het front (over hotmail etc.)

Mon Jan 31 16:17:59 CET 2005

On Mon, Jan 31, 2005 at 01:23:46PM +0100, cobaco (aka Bart Cornelis) wrote:
> On Monday 31 January 2005 11:19, Peter Vandenabeele wrote:
> > * leeftijd van de deelnemer
> > * een "MD5" van de ID van de andere partij
> >
> > Dit laat je toe:
> >
> > * te weten als je niet met een volwassene te doen hebt die zich om
> >   verkeerde redenen als jongere uitgeeft
> > * te garanderen dat je telkens met _dezelfde_ persoon spreekt
> >   (maar je weet niet exact met wie)
> weet je dan nog niet: 
> wat zegt je dat de persoon niet net even weg is, of vergeet uit te loggen en 
> iemand anders dan iets stuurt zich voordoende als die persoon?

Je hebt volledig gelijk. Maar het geeft toch wel een serieuze hint. 
Als het correct is geimplementeerd, is het toch niet triviaal om een 
correct geauthenticeerde sessie over te nemen zonder in de buurt te
komen.

Anderzijds, ik wil ook niet stellen dat dit de enige en beste
oplosing is voor mijn probleem dat hotmail/msn nu een de facto
monopolie op online identiteit aan het krijgen is bij veel mensen.
Dat monopolie vervangen door een monopolie of verplichting
om alles via eID te doen (in de zin van die chip in je ID kaart), 
is niet beter. Maar het kan een interessante _optie_ zijn om als 
startpunt te gebruiken voor een betere, optionele authenticatie. 
Het mag zeker geen universele verplichting zijn, want het moet 
ook mogelijk blijven om perfect anoniem te kunnen blijven.

> Als ik kijk naar de situatie bij mijn ouders thuis heb je 1 (XP) systeem 
> waar iedereen een account waarop geen wachtwoord ingesteld is. Die computer 
> staat dikwijls de hele dag aan met iedereen aangemeld, met z'n mail 
> (gelukkig geen hotmail) en msn open. Idem bij mijn oom. 
> 
> -> je weet enkel dat het van een bepaalde account komt, wie er fysiek aan de 
> pc zit weet je nog steeds niet. 

Inderdaad, maar als bewezen kan worden dat er vanop die PC iets
verkeerd is gebeurd, is er toch al een serieuze hint.

> Het is zowieso een 'oplossing' die enkel 'werkt':
> 1) voor belgen. -> dus geen chat met buitenlandse vriendjes die op vakantie 
> ontmoet zijn? (i.e. gooi het globale en interculture aspect van Internet 
> maar weg)

Behalve als die ook ooit een soort eID krijgen (hoeft niet noodzakelijk
hetzelfde te zijn, als het maar open is). Misschien lost het idee 
hieronder [1] dit op ?

> 2) voor kinderen ouder dan 12 (dat was wanneer ze dat eid ding kregen niet?)

Idd. Misschien ook met het idee [1] op te lossen ?

> 3) in chatrooms die eid ondersteunen (gegarandeert enkel een kleine 
> minderheid), of hoe dacht je kinderen tegen te houden naar een random 
> website met chatbox te gaan?

Kan je niet technologisch. Maar je kan wel je kids vragen om alleen
met ernstig geauthenticeerde personen te spreken of alleen in. En 
hiermee geef je hen een extra middel om dat te verifieren.

De analogie met Caller ID op gsm lijkt me redelijk accuraat. Het blijft
optioneel, maar het geeft wel meer vetrouwen in de andere kant als je 
dat wil. Maar dan moeten ze niet software gaan bouwen (a la DRM) die
alleen maar werkt als je een harde authenticatie van de andere kant
hebt.

> 4) wanneer kinderen dat eid lezertje bij zich hebben (en het dus niet 
> stuk/verloren/vergeten is) EN ze de moeite doen het uit te halen, aan te 
> koppelen (wat dikwijls wil zeggen onder tafel kruipen zodat je bij de 
> juiste aansluitpoort komt, inhoud dat ze moeten weten welk poortje ze het 
> moeten aansluiten [1])

Die lezers verdeeld krijgen, is inderdaad niet simpel en te beperkend.
Het is deze opmerking die mijn idee [1] heeft getriggered.

> 5) kinderen nooit hun account open laten staan (iets wat de meeste mensen in 
> mijn ervaring juist wel doen)

Doen ze wel (net vooral de kids en minder ervaren personen). Maar zoals
hierboven vermeld, vormt het toch wel een extra belemmering voor
verkeerd gebruik.

> -> het is absoluut niet waterdicht, duur (hoeveel kost het om alle kinderen 
> zo'n dingetje te geven, + vervangingen wanneer dit stuk gaat/verloren 
> wordt), en onnodig restrictief (zie 1,2 hierboven)
> 
> Wie was het ook al weer die zei dat:
> "there is never a good technical solution to a social problem"
> 
> Een "sociale" oplossing is veel effectiever, m.a.w. net zoals je kinderen 
> aanleert dat ze niet met vreemden in de auto stappen dien je ze aan te 
> leren dat:
> 1) je _nooit_ een 'Real Life' ontmoeting regelt met online kennis zonder dat 
> je ouders hiervan op de hoogte zijn.
> 2) je _nooit_ adres/telefoon/foto... doorgeeft online

Wel, ik vermoed dat een flink pak mensen, naast de sociale oplossingen
die evident nodig zijn, toch geinteresseerd zullen zijn in een systeem
dat garandeerdt dat:

  * de online ID steeds met dezelfde persoon gekoppeld is
  * je een indicatie kan hebben van de leeftijd van die persoon

maar dan ook weer zonder een volledig M$ of staatscontrole erop 
te organizeren. Maar die indicatie van leeftijd vereist uiteindelijk 
wel ergens een koppeling met een "officiele" registratie of een 
peer-to-peer controle systeem zoals met key-rings. En als het te 
rigoureus is, kom je weer in de problemen die je hierboven beschrijft 
en een te strikte controle op identiteit.  

Niet makkelijk ...

Mijn idee [1]: OpenID
=====================

Ik luister met interesse naar de fouten die hier weer kunnen 
inzitten ... Dit is evident niet voor alle gevallen bruikbaar, 
maar het lijkt me toch al een minder slechte implementatie dan 
eenvoudigweg de eID direct laten gebruiken voor alle chat 
communicatie door kids (niet erg haalbaar, zoals hierboven 
duidelijk is geworden). 

Gebruik een systeem van key-rings, die je op bepaalde plaatsen gaat
seeden met eID's, of je kan het ook second level CA's noemen. 

* dus, ik (40 jaar) heb een door de Belgische staat gecertifieerde
  eID (nog niet, maar dat komt), en ben bereid om een certificaat te 
  tekenen voor mijn 6 kids dat hun leeftijdsgroep vermeldt (dat
  ze in de loop van 2005 nog minder dan 16 jaar of 18 jaar zijn 
  is al genoeg om een "kids-only" chat-room te maken), samen met hun 
  nick. Dus in dat certificaat zit:

  * nick (bijv. "koekje-1003835")
  * leeftijd (bijv. "< 16 jaar")
  * relatie van de uitgever van het certificaat tot het subject
    (bijv. "{ouder|groutouder|voogd|broer/zus} van")
  * mijn volledige naam en leeftijdsgroep en mijn 
    volgnummer in het OpenID systeem 
    (volgnummer dient om een lokale name space te genereren)
    (bijv. "Peter Vandenabeele", "> 18 jaar", "1003835")
  * een checksum die ik met mijn eID getekend heb
  * mijn certificaat (of een pointer ernaartoe), 
    getekend door de Belgische staat

  Daar zijn kids tussen die minder dan 12 zijn, maar het is
  mijn keuze om hun al dan niet een OpenID te geven. Het certificaat 
  vermeldt uiteraard niet hun echte naam etc. (dus al veel veiliger 
  dan xxx_vanxxx#@hotmail.com)

* dat certificaat is publiek beschikbaar, maar bevat geen verdere
  informatie over mijn kids. De correctheid wordt niet gegarandeerd 
  door de server die de certificaten verdeeld (daar kunnen er veel 
  parallelle van zijn en die kunnen niet veel fout doen als het root 
  certificate van de Belgische staat bekend is). De correctheid
  wordt wel gegarandeerd door de het feit dat alleen iemand met een 
  echt eID dit kon tekenen. 

* Ik heb er geen probleem mee dat _mijn_ identiteit bekend is. Ik 
  sta dus "garant" voor de accuraatheid van die info en als er 
  vanop die nicks iets fishy gebeurt, zullen ze het wel aan mij 
  komen vragen (dus mijn kids zullen wel snugger genoeg zijn om 
  acties die het daglicht schuwen niet met die gecertifieerde 
  nicks te doen).

* de kids hebben zelf "ergens" op 1 of enkele plaatsen een 
  private key die hen toelaat om zich te authenticeren. Vermits
  deze key maar een beperkte juridische waarde heeft, is het
  voor deze 2e orde key _wel_ acceptabel om die op een 
  centrale authenticatie server geencrypteerd op te slaan. 
  Hiermee los je het probleem op dat je altijd die eID moet 
  meehebben en het voor kids veel te lastig is om die bij te 
  houden.

* Als die authenticatie servers https gebruiken en je daarover
  met een eerste paswoord je encrypted private key gaat 
  downloaden, die je dan met een lokaal paswoord decrypteert en 
  beschikbaar stelt om authenticatie te doen om je bijv. op 
  een "OpenID only" chat room aan te melden, dan concentreert 
  de noodzaak aan beveiliging zich hoofdzakelijk in de client 
  die het paswoord van de gebruiker ontvangt, de encrypted 
  private key daarmee gaat decrypteren en zich hiermee aanmeldt 
  op de "OpenID only" chat ruimte.  

  Dit is niet perfect veilig tegen een fishing attack, maar ja, 
  het is al minstens even goed als gewoon inloggen op een hotmail 
  server. 

  Alternatieven zijn:
  * de private keys versleuteld op de systemen zetten die de
    kids gebruiken
  * toch weer zelf deze keys op een smart card gaan zetten ??

* Als ik het goed begrijp, is dit helemaal met Open Source SW
  te implementeren (er is geen nood voor secrecy in de 
  implementatie in software). 

  Er is ook geen strikte nood aan een "centrale" authenticatie 
  server. Je kan voor het gemak een aantal authenticatie servers 
  opzetten, maar je zou de sleutel net zogoed gewoon prive kunnen 
  bewaren. 

  De beheerder van zo'n centrale authenticatie server heeft niet
  de harde verantwoordelijkheid over de identiteit van zo'n OpenID,
  want ze zijn nog altijd encrypted.

  Dus het lost wel mijn probleem op dat M$ of eender welke
  organisatie (commercieel, vzw of de staat) een "centraal
  punt van authenticatie moet zijn" (naast natuurlijk eID 
  dat nu wel al bestaat).

* het universele probleem is dat als de client gecompromiteerd
  is, dan de hele security in het water valt. Maar dat valt met
  Linux en Open Source nog redelijk mee. 

* dit model vertoont een sterke parallel met de trust associatie
  die ouders nu ook gebruiken. "Als je met enkele vrienden van je
  klas gaat en als het van de ouders van je vriendje mag, dan mag 
  je van mij ook naar die fuif ..."

* je kan dit natuurlijk ook zonder eID in een gesloten groep
  implementeren, door bijv. alle ouders van een school een 
  certificaat te geven, maar dan moet die school weer CA gaan
  spelen en ook nog geassocieerd worden met alle "OpenID only"
  chat rooms. Je kan ook een klassieke, niet hierarchische
  key-ring gebruiken, maar dan moet je ook al die associaties
  gaan bouwen.

* Als eID er is (voor volwassenen), is het IMHO redelijk 
  realistisch om op die manier de trust voor net voldoende
  informatie (leeftijdsgroep en online identiteit (nick))
  via eID op te bouwen.

Als je dan echt iets wil doen waarbij je op een technische manier
een sociaal probleem wil oplossen, lijkt deze aanpak al veel
minder verregaand en praktischer dan alle kids een originele
eID geven en erop rekenen dat ze die ook zullen gebruiken om
te chatten.

Door hier een optioneel systeem met alleen maar nicks en
leeftijdscategorieeen in te voeren, wordt het misschien wel
werkbaar ?

> > * als er echt strafbare feiten gepleegd worden, heb je toch een
> >   "nummerplaat" die je in je klacht kan vermelden.
> hm, welke strafbare feiten worden er _in_de_chat_ gepleegd? 

Wel, het opzettelijk aannemen van een valse identiteit met de
bedoeling jongeren te benaderen voor het plegen van strafbare feiten,
lijkt me toch wel over de schreef (maar mischien is pas het plegen van 
die feiten strafbaar en niet het proberen te ronselen van jongeren
onder een valse identiteit). Ik vraag dit uit nieuwsgierigheid eens 
na.

> Is op z'n hoogst 
> goed om eens de feiten gepleegd zijn (en vooropgesteld dat het kind een log 
> van conversaties bewaart heeft) de gebruikte account gebruikt van een 
> verdachte te achterhalen (iets dat uiteindlijk relatief los staat van 
> plaats en zelfs persoon)

Als je de policy opstelt dat de kids een log moeten bewaren van de
contacten en/of alleen op "OpenID only" chat rooms komen, dan heb je 
dit toch al als uitgangspunt. 

HTH,

Peter