Digid
Lambik
poging. Het is niet helemaal on topic maar dit lijkt met toch de meest
geeigende groep op dit soort vragen te stellen.
Wat weten jullie over de techniek achter DigId? Ik weiger dit aan te vragen
om een aantal redenen. Eén van de redenen is deze passage in de voorwaarden:
6. Gebruiker geeft door acceptatie van deze Gebruiksvoorwaarden de
GBO.Overheid toestemming om ongevraagd per e-mail (nieuws)berichten inzake
DigiD-dienstverlening te versturen.
En meer on topic: Een ander is dat ik geen flauw idee heb over de gebruikte
beveiliging. Nergens op de site is technische informatie te vinden. Ik neem
aan dit dit niet meer is dan een simpele ssl beveiliging. Heeft er iemand
meer informatie?
ctjsbduc
> Ik weet niet of er nog mensen leven in deze groep maar we doen maar
> een poging. Het is niet helemaal on topic maar dit lijkt met toch de
> meest geeigende groep op dit soort vragen te stellen.
>
> Wat weten jullie over de techniek achter DigId? Ik weiger dit aan te
> vragen om een aantal redenen. Eén van de redenen is deze passage in
> de voorwaarden:
>
> 6. Gebruiker geeft door acceptatie van deze Gebruiksvoorwaarden de
> GBO.Overheid toestemming om ongevraagd per e-mail (nieuws)berichten
> inzake DigiD-dienstverlening te versturen.
Je geeft ze toestemming het te proberen, maar je bent niet verplicht hun
jouw email adres te geven :-)
{quote}
U bent niet verplicht uw e-mailadres op te geven.
Met het invullen van uw e-mailadres geeft u DigiD toestemming om via uw
e-mailadres op de hoogte
te worden gehouden van ontwikkelingen ten aanzien van DigiD.
{/quote}
Lambik
news:581td0F...@mid.individual.net...
Zoals gezegd heb ik gewoon lekker ouderwets een formulier ingevult. Ik weet
niet waar jouw citaat vandaan komt, maar in de voorwaarde kon ik er niets
van terugvinden.
Los daarvan vertrouw ik de overheid niet om een geheim te bewaren. Er is wat
mij betreft niets bekend over de techniek die wordt gebruikt. Staat het
bijv. plaintext in een database of is het gehasht? Het werd al weer
overduidelijk toen de belastingdienst adviezen ging geven om maar het digid
van iemand anders te gebruiken.
Maar gezien het gebrek aan antwoorden ga ik er maar van uit dat deze groep
dood is.
Ruben van der Leij
> Los daarvan vertrouw ik de overheid niet om een geheim te bewaren. Er is wat
> mij betreft niets bekend over de techniek die wordt gebruikt. Staat het
> bijv. plaintext in een database of is het gehasht? Het werd al weer
> overduidelijk toen de belastingdienst adviezen ging geven om maar het digid
> van iemand anders te gebruiken.
>
> Maar gezien het gebrek aan antwoorden ga ik er maar van uit dat deze groep
> dood is.
Zo te zien heb je alle antwoorden al. Dat vermoedde ik al bij je originele
vraag. Waarom antwoorden als je het allemaal al weet?
--
Ruben
Misfortune, n.: The kind of fortune that never misses.
-- Ambrose Bierce, "The Devil's Dictionary"
Lambik
news:slrnf1tkcs.8...@its.blacklisted.nl...
> On 2007-04-12, Lambik <lam...@kieffer.nl> wrote:
>
> > Los daarvan vertrouw ik de overheid niet om een geheim te bewaren. Er is
wat
> > mij betreft niets bekend over de techniek die wordt gebruikt. Staat het
> > bijv. plaintext in een database of is het gehasht? Het werd al weer
> > overduidelijk toen de belastingdienst adviezen ging geven om maar het
digid
> > van iemand anders te gebruiken.
> >
> > Maar gezien het gebrek aan antwoorden ga ik er maar van uit dat deze
groep
> > dood is.
>
> Zo te zien heb je alle antwoorden al. Dat vermoedde ik al bij je originele
> vraag. Waarom antwoorden als je het allemaal al weet?
Ik had gehoopt dat iemand hier iets meer van de techniek wist.
Encryptiemethodiek (als die er al is, waarschijnlijk alleen ssl),
identificatietechniek ed. Misschien had iemand meegewerkt aan de
ontwikkeling ervan. Ik wilde m'n algemene wantrouwen ombouwen naar
gefundeerde wantrouwen. Misschien een discussie starten maar ik heb het idee
dat het meer praten tegen mezelf word.
Ruben van der Leij
>> Zo te zien heb je alle antwoorden al. Dat vermoedde ik al bij je originele
>> vraag. Waarom antwoorden als je het allemaal al weet?
> Ik had gehoopt dat iemand hier iets meer van de techniek wist.
> Encryptiemethodiek (als die er al is, waarschijnlijk alleen ssl),
> identificatietechniek ed.
Voegt laag-op-laag iets toe? Ja, het is 'gewoon' 'maar' 128-bits SSL, de
overheid heeft een eigen PKI en het is 'gewoon' 'slechts' X.509v3.
> Misschien had iemand meegewerkt aan de ontwikkeling ervan. Ik wilde m'n
> algemene wantrouwen ombouwen naar gefundeerde wantrouwen. Misschien een
> discussie starten maar ik heb het idee dat het meer praten tegen mezelf
> word.
Als er aanleiding voor wantrouwen is, is dat ten aanzien van een specifieke
implementatie. X.500/X.509 is ongebroken, en los van problemen met
specifieke algorithmes als MD5, kun je het als voldoende veilig beschouwen,
volgens de industrie. De overheid gebruikt SHA1, op het moment.
Details over de PKI van de overheid kun je op
http://www.diginotar.nl/common.asp?id=312 vinden.
Allemaal dingen die je met een paar seconden google zelf ook had kunnen
vinden. De URL's staan in de certificaten, en 'digitale overheid PKI' is een
passende toverspreuk voor google.
Lambik
specifieke
> implementatie. X.500/X.509 is ongebroken, en los van problemen met
> specifieke algorithmes als MD5, kun je het als voldoende veilig
beschouwen,
> volgens de industrie. De overheid gebruikt SHA1, op het moment.
>
> Details over de PKI van de overheid kun je op
> http://www.diginotar.nl/common.asp?id=312 vinden.
>
moet googelen. Dat de overheid een niet voorgeinstalleerde CA gebruikt wist
ik ook. MD5 is al jaren niet meer "veilig"
(http://nl.wikipedia.org/wiki/MD5). Perfect geschikt om bijv. bestanden te
indexeren, maar als beveiling onwenselijk. SHA-1 vziw nog wel, hoewel hij in
theorie al kraakbaar zou zijn.
Omdat de overheid al geen voorgeinstalleerde CA gebruikt is het bijzonder
kwetsbaar voor de "man in the middle attack". Zelf zou ik bijv. een java
applet oid gebruiken voor de beveiliging. Zo filosoferend misschien zelfs
een executable maken die als webserver fungeert (via localhost een port
openen). Ik weet niet in hoeverre jij iets weet of gewoon hebt gegoogeld
maar als ik jou mag geloven is er dus geen sprake van een extra beveiling,
anders dan SSL.
Blijft de vraag hoe alles op de servers van de overheid wordt verwerkt. Is
er sprake van één autorisatieserver (een Ideal achtig iets) of zijn er
zoveel kopieen van de database die lokaal draaien.
Ruben van der Leij
>> Als er aanleiding voor wantrouwen is, is dat ten aanzien van een
>> specifieke implementatie. X.500/X.509 is ongebroken, en los van problemen
>> met specifieke algorithmes als MD5, kun je het als voldoende veilig
>> beschouwen, volgens de industrie. De overheid gebruikt SHA1, op het
>> moment.
> Zoals je zelf al vermoedde wist ik dit soort dingen al. Ook ik weet hoe ik
> moet googelen. Dat de overheid een niet voorgeinstalleerde CA gebruikt wist
> ik ook. MD5 is al jaren niet meer "veilig"
> (http://nl.wikipedia.org/wiki/MD5). Perfect geschikt om bijv. bestanden te
> indexeren, maar als beveiling onwenselijk. SHA-1 vziw nog wel, hoewel hij in
> theorie al kraakbaar zou zijn.
MD5 is prima te gebruiken als _hash_-functie, zeker in de context van CA's.
De _key_ kun je niet met MD5 versleutelen, want het is een hash-functie.
Iemand moet onrealistisch veel moeite doen om de zwakte van MD5 tegen je te
kunnen exploiteren. Zoveel moeite dat 'ie beter iets kan doen met je Outlook
of IE. Dat is een stuk makkelijker.
> Omdat de overheid al geen voorgeinstalleerde CA gebruikt is het bijzonder
> kwetsbaar voor de "man in the middle attack".
Het root-certificaat zit pas sinds 2002 in de root-tree, dus als je browser
het niet kent heb je hele andere problemen dan onbetrouwbare cetrificaten.
Zo heb je dan hier en daar een update of 120 gemist, of je gebruikt een
antiek en niet langer ondersteunt OS.
> Zelf zou ik bijv. een java applet oid gebruiken voor de beveiliging. Zo
> filosoferend misschien zelfs een executable maken die als webserver
> fungeert (via localhost een port openen).
Ik zou een overheid die dat soort geintjes flikt trakteren op een paar
honderd kilo kunstmest en een paar liter diesel voor hun datacenter. Oh, en
een echt-werkende ontsteker. Als de overheid denkt dat ik windows ga
installeren om een programma te draaien zodat ik 'veilig' met ze kan
communiceren verdient extreme maatregelen. Als ik een recente live-distro op
een CD zet en in een willekeurige doos steek en reboot kan ik uiterst veilig
met de overheid communiceren.
> Ik weet niet in hoeverre jij iets weet of gewoon hebt gegoogeld maar als
> ik jou mag geloven is er dus geen sprake van een extra beveiling, anders
> dan SSL.
Is er meer nodig dan? Het verkeer tussen jou en de overheid is veilig
gecrypt, en afhankelijk van het soort verkeer kan de overheid je een van de
vier niveau's laten gebruiken voor authenticatie. (username/wachtwoord,
sms-verificatie, vooraf verstrekte certificaten of hardware-tokens, en voor
alle vier is de infrastructuur aanwezig) GBA-gegevens met verificatie en
username/password is wat de overheid betreft voor de meeste transacties
genoeg. Iemand kan met minder moeite de verkeerde naam op z'n
belastingaangifte zetten en dat per post sturen.
> Blijft de vraag hoe alles op de servers van de overheid wordt verwerkt. Is
> er sprake van één autorisatieserver (een Ideal achtig iets) of zijn er
> zoveel kopieen van de database die lokaal draaien.
iDeal is ook 'gewoon' SSL. Wellicht dat de _authenticatie_ die je bank
gebruikt je in verwarring gebracht heeft, maar dat staat los van iDeal.
iDeal gebruikt voor _encryptie_ exact dezelfde infrastructuur als de
overheid, met wellicht 1 klein verschil, en dat is dat het beheer van
certificaten bij commercieele bedrijven gebeurt, en niet in 'eigen beheer'.
Het delegeren van authenticatie is een eitje. Er is een database, en iedere
'afnemer' van digid delegeert authenticatie naar die centrale database, en
doet dat over een beter-beveiligd pad. (ssl, vooraf verstrekte certificaten
en ip-'authenticatie' aan beide zijden..)
Lambik
> Het root-certificaat zit pas sinds 2002 in de root-tree, dus als je
browser
> het niet kent heb je hele andere problemen dan onbetrouwbare cetrificaten.
> Zo heb je dan hier en daar een update of 120 gemist, of je gebruikt een
> antiek en niet langer ondersteunt OS.
Hij staat niet in mijn geupdate win2k met explorer 6. Net nog ff nagekeken.
> Ik zou een overheid die dat soort geintjes flikt trakteren op een paar
> honderd kilo kunstmest en een paar liter diesel voor hun datacenter. Oh,
en
> een echt-werkende ontsteker. Als de overheid denkt dat ik windows ga
> installeren om een programma te draaien zodat ik 'veilig' met ze kan
> communiceren verdient extreme maatregelen. Als ik een recente live-distro
op
> een CD zet en in een willekeurige doos steek en reboot kan ik uiterst
veilig
> met de overheid communiceren.
Nou toch maken er een hoop gebruik van applets. De Postbank bijv.
> > Ik weet niet in hoeverre jij iets weet of gewoon hebt gegoogeld maar als
> > ik jou mag geloven is er dus geen sprake van een extra beveiling, anders
> > dan SSL.
>
> Is er meer nodig dan? Het verkeer tussen jou en de overheid is veilig
> gecrypt, en afhankelijk van het soort verkeer kan de overheid je een van
de
> vier niveau's laten gebruiken voor authenticatie. (username/wachtwoord,
> sms-verificatie, vooraf verstrekte certificaten of hardware-tokens, en
voor
> alle vier is de infrastructuur aanwezig) GBA-gegevens met verificatie en
> username/password is wat de overheid betreft voor de meeste transacties
> genoeg. Iemand kan met minder moeite de verkeerde naam op z'n
> belastingaangifte zetten en dat per post sturen.
Wat een gelul. Ik heb, toegegeven een paar jaar geleden, een scriptje
geschreven die bij een Tiscali IP range controleerde op de ftp port en keek
of er een router antwoord gaf. Vervolgens werd er in een db gekeken (aan de
hand van de response) of daar een standaard wachtwoord bekend was. In de IP
range van 255 bleken er (gemiddeld, bij drie ranges) 15 onbeveiligde (dus
met default password) routers te zitten. Zou ik daarvan de DNS hebben
veranderd dan liep al hun communicatie via mij. Kopie maken van een website
en klaar is Klara. De foutmelding dat er geen trusted CA is wordt weggeklikt
omdat die er altijd is.
> > Blijft de vraag hoe alles op de servers van de overheid wordt verwerkt.
Is
> > er sprake van één autorisatieserver (een Ideal achtig iets) of zijn er
> > zoveel kopieen van de database die lokaal draaien.
> iDeal is ook 'gewoon' SSL. Wellicht dat de _authenticatie_ die je bank
> gebruikt je in verwarring gebracht heeft, maar dat staat los van iDeal.
> iDeal gebruikt voor _encryptie_ exact dezelfde infrastructuur als de
> overheid, met wellicht 1 klein verschil, en dat is dat het beheer van
> certificaten bij commercieele bedrijven gebeurt, en niet in 'eigen
beheer'.
De beveiling van mijn bank maakt integraal deel uit van de beveiling van
iDeal. iDeal is niets meer dan een protocol die de banken hebben afgesproken
over bepaalde responces. Overigens gebruikt de Postbank een java applet. Ik
heb nog nooit gekeken hoe die precies werkt.
> Het delegeren van authenticatie is een eitje. Er is een database, en
iedere
> 'afnemer' van digid delegeert authenticatie naar die centrale database, en
> doet dat over een beter-beveiligd pad. (ssl, vooraf verstrekte
certificaten
> en ip-'authenticatie' aan beide zijden..)
Dat weet je of dat gok je?
Ruben van der Leij
>> Het root-certificaat zit pas sinds 2002 in de root-tree, dus als je
>> browser het niet kent heb je hele andere problemen dan onbetrouwbare
>> cetrificaten. Zo heb je dan hier en daar een update of 120 gemist, of je
>> gebruikt een antiek en niet langer ondersteunt OS.
> Hij staat niet in mijn geupdate win2k met explorer 6. Net nog ff nagekeken.
Je gebruikt een antiek OS wat sinds juli 2006 niet meer geupdate wordt door
Microsoft. Desalniettemin zou het moeten werken. Blijkbaar heb je niet alle
updates. Dat houdt waarschijnlijk ook in dat je windows zonder blikken en
blozen updates die met een 'gestolen' certificaat ondertekend zijn voor je
installeert. En dan kun je je windows niet echt meer vertrouwen.
http://www.digid.nl/burger/vraag-en-antwoord/certificaat/#irfaq1
> Nou toch maken er een hoop gebruik van applets. De Postbank bijv.
http://www.nu.nl/news.jsp?n=536327&c=50
> Wat een gelul. Ik heb, toegegeven een paar jaar geleden, een scriptje
> geschreven die bij een Tiscali IP range controleerde op de ftp port en keek
> of er een router antwoord gaf. Vervolgens werd er in een db gekeken (aan de
> hand van de response) of daar een standaard wachtwoord bekend was. In de IP
> range van 255 bleken er (gemiddeld, bij drie ranges) 15 onbeveiligde (dus
> met default password) routers te zitten.
En dat probleem gaat niet voorkomen met binaries op lekke windows-dozen, en
dat probleem is iets wat de overheid moet fixen? Zelfs het gebruik van java
lost je probleem niet op.
> Zou ik daarvan de DNS hebben veranderd dan liep al hun communicatie via
> mij. Kopie maken van een website en klaar is Klara. De foutmelding dat er
> geen trusted CA is wordt weggeklikt omdat die er altijd is.
Op het moment dat je het verkeer van iemand in handen hebt kun je 'm alles
wijsmaken wat je wilt. De voornaamste vraag is hoeveel moeite je er in wilt
steken. Maar ook weer: is dat een probleem wat de overheid, SSL of
java-applets kunnen verhelpen of niet?
>> iDeal is ook 'gewoon' SSL. Wellicht dat de _authenticatie_ die je bank
>> gebruikt je in verwarring gebracht heeft, maar dat staat los van iDeal.
>> iDeal gebruikt voor _encryptie_ exact dezelfde infrastructuur als de
>> overheid, met wellicht 1 klein verschil, en dat is dat het beheer van
>> certificaten bij commercieele bedrijven gebeurt, en niet in 'eigen
>> beheer'.
> De beveiling van mijn bank maakt integraal deel uit van de beveiling van
> iDeal. iDeal is niets meer dan een protocol die de banken hebben afgesproken
> over bepaalde responces. Overigens gebruikt de Postbank een java applet. Ik
> heb nog nooit gekeken hoe die precies werkt.
Dan moet je dat maar eens doen, want ik krijg het idee dat je er volstrekt
niets van begrijpt. De winkelier geeft een bestellijstje en een bedrag aan
z'n bank. Dat kan als http-post of xml. De bank zoekt contact met de bank
van de klant. Ook dat is gewoon XML over een SSL-verbinding. De bank van de
klant doet wat 'ie normaal gesproken doet voor de klant om betalingen te
verrichten. De bank van de klant meldt succes aan de bank van de winkelier,
via XML, over SSL, en de bank van de winkelier meldt succes aan de site van
de winkelier, via een http-redirect, XML of via email. iDeal heeft geen
flauw idee van hoe jij moet authenticeren bij je bank. Hoeft ook niet. Je
eigen bank regelt dat. De 'beveiliging' van jouw bank wordt nergens gebruikt
door iDeal of de bank van de winkelier. Dat staat er helemaal buiten.
http://www.znmail.nl/ING_iDEAL_Winkel_Integratie_Algemeen_v10.pdf
https://idealtest.secure-ing.com/ideal/docs/ing/iDEAL_Basic_NL.pdf
>> Het delegeren van authenticatie is een eitje. Er is een database, en
>> iedere 'afnemer' van digid delegeert authenticatie naar die centrale
>> database, en doet dat over een beter-beveiligd pad. (ssl, vooraf
>> verstrekte certificaten en ip-'authenticatie' aan beide zijden..)
> Dat weet je of dat gok je?
DigiNotar PKIoverheid certificaten worden gebruikt bij het aansluiten op
digiD. Bent u een gemeente of overheidsinstelling en bent u bezig uw online
dienstverlening in te richten, gebruik dan een DigiNotar PKIoverheid
certificaat.
(https://www.servercertificaat.nl/common.asp?id=269&instantie=0)
http://www.diginotar.nl/files/NIEUW%20Flyer%20PASS%20v8.pdf
http://www.pass.nl/files/Whitepaper%20PASS%20v07mj.pdf
DigiD is een voor de overheid aangepaste implementatie van PASS. De tweede
PDF beschrijft in enig detail hoe PASS en DigiD werken.
Echt, het is allemaal te vinden en niets is geheim. Nouja, de keys. Maar de
protocollen zijn oud, getest, ongebroken en meestal is de veiligheid van de
eindgebruiker een veel groter probleem dan die van de protocollen of de
systemen waarop ze draaien.
Lambik
> > Nou toch maken er een hoop gebruik van applets. De Postbank bijv.
>
> http://www.nu.nl/news.jsp?n=536327&c=50
Dit heeft er niets mee te maken.
> En dat probleem gaat niet voorkomen met binaries op lekke windows-dozen,
en
> dat probleem is iets wat de overheid moet fixen? Zelfs het gebruik van
java
> lost je probleem niet op.
Het probleem zit niet in windhoos maar in kennis van gebruikers. Nou kan je
roepen: dat is niet de verantwoordelijkheid van de toepassing, maar het is
nu eenmaal een voldonge feit.
>
> > Zou ik daarvan de DNS hebben veranderd dan liep al hun communicatie via
> > mij. Kopie maken van een website en klaar is Klara. De foutmelding dat
er
> > geen trusted CA is wordt weggeklikt omdat die er altijd is.
>
> Op het moment dat je het verkeer van iemand in handen hebt kun je 'm alles
> wijsmaken wat je wilt. De voornaamste vraag is hoeveel moeite je er in
wilt
> steken. Maar ook weer: is dat een probleem wat de overheid, SSL of
> java-applets kunnen verhelpen of niet?
Ja. Applets kunnen dat verhelpen door via een andere aparte route nog eens
een keer aan te melden. Open port naar ip x.x.x.x zeg wie je bent en vraag
om een sessie id. Die meld zich aan via internet. Je kunt de port evt.
openhouden.
Dat zei ik. iDeal is de afspraken, bij een geslaagde betaling krijg je x,
bij een onsuccesvolle communicatie krijg je Y enz. Zoiets heet protocol
(www.vandale.nl/opzoeken/woordenboek/?zoekwoord=protocol). Mijn bank is
verantwoordelijke voor de authenticatie. Ik ontken niet dat ssl redelijk
veilig is voor communicatie, alleen niet voor authenticatie. Het werkt
alleen als je al weet dat je met de goede computer praat.
> > Dat weet je of dat gok je?
>
> DigiNotar PKIoverheid certificaten worden gebruikt bij het aansluiten op
> digiD. Bent u een gemeente of overheidsinstelling en bent u bezig uw
online
> dienstverlening in te richten, gebruik dan een DigiNotar PKIoverheid
> certificaat.
> (https://www.servercertificaat.nl/common.asp?id=269&instantie=0)
>
> http://www.diginotar.nl/files/NIEUW%20Flyer%20PASS%20v8.pdf
> http://www.pass.nl/files/Whitepaper%20PASS%20v07mj.pdf
>
> DigiD is een voor de overheid aangepaste implementatie van PASS. De tweede
> PDF beschrijft in enig detail hoe PASS en DigiD werken.
Dat wist ik niet. Ik zal de pdfjes eens lezen. Eens ff kijken wat daar in
staat.
> Echt, het is allemaal te vinden en niets is geheim. Nouja, de keys. Maar
de
> protocollen zijn oud, getest, ongebroken en meestal is de veiligheid van
de
> eindgebruiker een veel groter probleem dan die van de protocollen of de
> systemen waarop ze draaien.
Dat vroeg ik me dus af.
Ruben van der Leij
>> Op het moment dat je het verkeer van iemand in handen hebt kun je 'm alles
>> wijsmaken wat je wilt.
Lees nog eens?
> Ja. Applets kunnen dat verhelpen door via een andere aparte route nog eens
> een keer aan te melden. Open port naar ip x.x.x.x zeg wie je bent en vraag
> om een sessie id. Die meld zich aan via internet. Je kunt de port evt.
> openhouden.
Dat kwartje is dus niet echt gevallen. Als je toegang hebt tot iemands DNS
en ARP of routing zijn alle maatregelen aan die kant zinloos. Je hebt totale
macht over iemands machine.
> Ik ontken niet dat ssl redelijk veilig is voor communicatie, alleen niet
> voor authenticatie. Het werkt alleen als je al weet dat je met de goede
> computer praat.
Ik ontken ten stelligste dat SSL bedoeld is als identificatie. (1) Het is
niet waar! Er klopt helemaal niets van! Leugens! Wat dat betreft is de
nieuwe naam ook beter. Transport Level Security. Het geeft je een veilig pad
naar een specifieke machine, en je kunt via een omweg controleren of die
machine is wie hij zegt te zijn. Waar 'ie staat en wie 'm beheert kun je er
niet mee vaststellen. En omgekeerd kan TLS niet aantonen dat jij Lambik bent
en niet iemand die doet alsof.
http://www.sans.org/reading_room/whitepapers/threats/480.php wellicht?
(1) Waar denk je dat dat gedoe met die activatie en brieven van digid op
slaat? Zou dat iets te maken kunnen hebben met vaststellen van iemands
identiteit? Wellicht dat je even na moet denken over wat 'privacy',
'authenticatie' en 'identificatie' inhouden in een crypto-context.
Stefan Arentz
...
> > Nou toch maken er een hoop gebruik van applets. De Postbank bijv.
>
> http://www.nu.nl/news.jsp?n=536327&c=50
Dit is typische FUD van een Java hater. Misschien kan je uitleggen wat
de relatie is tussen een phishing emailtje en een java applet?
S.
Ruben van der Leij
>> > Nou toch maken er een hoop gebruik van applets. De Postbank bijv.
>> http://www.nu.nl/news.jsp?n=536327&c=50
> Dit is typische FUD van een Java hater. Misschien kan je uitleggen wat
> de relatie is tussen een phishing emailtje en een java applet?
Als je zo snel klaarstaat met de conclusie dat ik een 'java hater' ben is
wat mij betreft de discussie al weer afgelopen ook.
(Hint: misschien heeft de postbank een ander probleem dan een applet? Zou
het rondsturen van brieven met lijsten TAN-codes misschien wel problematisch
kunnen zijn?))
Stefan Arentz
> On 2007-04-16, Stefan Arentz <stefan...@gmail.com> wrote:
>
> >> > Nou toch maken er een hoop gebruik van applets. De Postbank bijv.
>
> >> http://www.nu.nl/news.jsp?n=536327&c=50
>
> > Dit is typische FUD van een Java hater. Misschien kan je uitleggen wat
> > de relatie is tussen een phishing emailtje en een java applet?
>
> Als je zo snel klaarstaat met de conclusie dat ik een 'java hater' ben is
> wat mij betreft de discussie al weer afgelopen ook.
>
> (Hint: misschien heeft de postbank een ander probleem dan een applet? Zou
> het rondsturen van brieven met lijsten TAN-codes misschien wel problematisch
> kunnen zijn?))
Met die beredenatie is ELKE vorm van autorisatie problematisch. Het probleem
van phishing is natuurlijk niet zo zeer de info die de bad guys proberen te
fishen maar de domheid van gebruikers. En die is vrij universeel, ongeacht
me applets, SSL, calculators (ala ABN), SMSjes (Postbank nieuwe stijl) of
wat dan ook gebruikt.
S.