Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Pro » Maatschappij » Privacy & beveiliging » Website Hi.nl bleek inloggegevens als plain text te verzenden

Website Hi.nl bleek inloggegevens als plain text te verzenden

Door Wilbert de Vries, donderdag 19 mei 2011 17:17, views: 29.053

De website van Hi.nl blijkt inlognamen en wachtwoorden onversleuteld te hebben verzonden. De inlogmodule en een Flash-banner wisselden deze gegevens als plain text uit met de server. KPN heeft de auto-inlogfunctie inmiddels uitgeschakeld.

Beveiligingsonderzoeker ObAt heeft onderzoek gedaan naar de veiligheid van de website van Hi.nl en concludeert dat deze vatbaar is voor zogenoemde man-in-the-middle-aanvallen. Hieruit blijkt dat de gebruikersnaam en het wachtwoord van een gebruiker met relatief weinig moeite achterhaald konden worden.

De auto-inlogfunctionaliteit van de website van Hi blijkt geruime tijd de inlognaam en het wachtwoord als plain text te hebben verzonden. "Bij het inloggen worden de gebruikersnaam en het wachtwoord dus onversleuteld verstuurd naar de servers van Hi, de gebruiker wordt hierna doorgelinkt naar het beveiligde deel van de site", aldus ObAt tegenover Tweakers.net.

Hoewel een dergelijke beveiligingsfout niet direct grote gevolgen heeft, kan het lek wel door kwaadwillenden worden misbruikt als zij in staat zijn om het netwerkverkeer te bekijken, zoals bijvoorbeeld bij openbare wifi-netwerken het geval is. Met de inloggegevens kunnen klanten op een persoonlijke omgeving hun Hi-account beheren, hun telefoonrekeningen inzien en hun bundel aanpassen.

Ook ontdekte ObAt op de indexpagina van Hi.nl een Flash-uiting die dusdanig was ontworpen dat deze meermaals het wachtwoord en de gebruikersnaam van de gebruiker onversleuteld opvroeg. "Dit is onnodig, aangezien de banner ook te bekijken is voor niet ingelogde gebruikers", aldus de beveiligingsonderzoeker.

KPN heeft na een tip van Tweakers.net de auto-inlogfunctie uitgeschakeld. "Klanten kunnen nu dus nog wel inloggen, maar niet meer automatisch", aldus een zegsman van de telco. "In dit geval geldt dat veiligheid boven gemak gaat." KPN heeft inmiddels ook de Flash-uiting aangepast.

Volgende 17:32 Facebook: er zijn geen problemen met privéfoto's
Vorige 16:28 Voldoende steun voor GroenLinks-voorstel netneutraliteit
Advertentie

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 79 reacties zichtbaar790 Off-topic / Irrelevant: 77 reacties zichtbaar77+1 On-topic: 47 reacties zichtbaar47+2 Informatief: 8 reacties zichtbaar8+3 Spotlight: 2 reacties zichtbaar2
«  1  2  3  4  »

Door calvinturbo, donderdag 19 mei 2011 17:19

Score: 0
Zijn de programmeurs nou gewoon lui of naïef?
Of vergeten ze het gewoon?

Naja, telkens blijken er weer sites te zijn met zwakke beveiliging

[Reactie gewijzigd door calvinturbo op donderdag 19 mei 2011 17:19]

Door yobikap, donderdag 19 mei 2011 17:35

Score: 1
Meestal is het snel snel afronden, waarom extra functionaliteit inbouwen als de klant er toch niet van merkt?

Bij Eneco gaat het één en een ander ook mis, laatst was ik mijn wachtwoord vergeten, en kreeg ik mijn ingevulde wachtwoord per e-mail toegestuurd, op zn minst had ik verwacht dat ik een nieuwe gegenereerde wachtwoord zou ontvangen, helaas kreeg ik zelfde wachtwoord die ik tijdens registratie had opgegeven. Ze worden dus niet met een hash opgeslagen.

Door Gert, donderdag 19 mei 2011 17:59

Score: 1
Je kan het wachtwoord toch versleuteld opslaan en weer ontsleutelen op het moment dat het nodig is?

Door Tha_TE, donderdag 19 mei 2011 18:11

Score: 1
hash is niet hetzelfde als versleutelen he, bovendien waarom zou je een wachtwoord encrypten en dan weer decrypten, het hele idee is dat niemand achter je wachtwoord komt.

Door hackerhater, donderdag 19 mei 2011 18:13

Score: 1
ja, maar de gebruikelijke manier is hashen. one way, niet terug te draaien.

Door SuperDre, donderdag 19 mei 2011 20:41

Score: 0
Je moest eens weten hoe vaak er niet gebruik gemaakt wordt van hashen...

Door T-MOB, vrijdag 20 mei 2011 12:22

Score: 3
Je kan het wachtwoord toch versleuteld opslaan en weer ontsleutelen op het moment dat het nodig is?
Dat kan, maar dat betekent dat iemand die toegang heeft tot de server het wachtwoord kan ontsleutelen. Die heeft dan immers zowel het versleutelde wachtwoord als de code om het te ontcijferen. Dat maakt het versleutelen nogal zinloos...

De gangbare oplossing is het opslaan van een zogenaamde hash. Dat is de uitkomst van een berekining waarbij data verloren gaat. Omdat er data verloren gaat kun je van een hashwaarde nooit meer terugrekenen naar de invoer. Je kunt echter wel controleren of iemand het wachtwoord kent: je voert de hashbereking uit met de gebruikersinvoer en controleert of de berekende hash overeenkomt met die in je database.

Maar goed het probleem bij hi.nl betreft niet zozeer het opslaan, maar het versturen van het wachtwoord. Als dat onversleuteld gebeurt dan maakt het weinig uit hoe de wachtwoorden zijn opgeslagen. Je kunt dan "gewoon" de inloggegevens afluisteren. Om dat te vookomen gebruik je ofwel SSL (versleuteling van je hele http-verbinding) ofwel een challenge-response systeem (of beide).

Door doctormetal, donderdag 19 mei 2011 17:44

Score: 1
Als ik kijk hoe slecht de Hi site werkt zou ik ze eerder incompetent noemen.
Geen beveiligde erbinding is l fout, maar dan ook nog plain text i.p.v. digest.

Door FragFrog, donderdag 19 mei 2011 17:59

Score: 1
Om het geheel wellicht wat te nuanceren:
Hieruit blijkt dat de gebruikersnaam en het wachtwoord van een gebruiker met relatief weinig moeite achterhaald konden worden.
Met "relatief weinig moeite" bedoelen ze: indien je een publiek WiFi netwerk hebt en iemand maakt daar gebruik van om in te loggen op de Hi website en je zit al zijn verkeer af te luisteren en die persoon maakt niet toevallig gebruik van een dienst als Tor, dan kun je wellicht in die brei data een username en wachtwoord vinden.

Natuurlijk, een programma als wireshark geeft voldoende mogelijkheden om verkeer te filteren zodat je alleen de wat relevantere pakketjes onderschept, maar zelfs dan moet je al redelijk gericht gaan zoeken en hopen dat in de tijd die jij aan het luisteren bent toevallig een nuttig stuk informatie voorbij komt. Ja, het is relatief eenvoudig in zoverre dat het een stuk makkelijker is dan een wachtwoord te bruteforcen, maar nog vele malen simpeler is om domweg een telecomwebsite te maken, gebruikers daarvoor gratis te laten registreren en vervolgens te gaan checken hoeveel username/password combo's ook werken op de Hi website. Denk dat je er een stuk meer onderschept ;)

[Reactie gewijzigd door FragFrog op donderdag 19 mei 2011 18:04]

Door Zoefff, donderdag 19 mei 2011 18:34

Score: 3
Desondanks wordt het "onveilig" versturen van data wel degelijk een steeds groter probleem. Ik denk dat je bang wordt van de hoeveelheid data die je kan opvissen als je een laptopje 24 uur op een onbeveiligd netwerk laat sniffen ergens in de stad of bij een druk café / restaurant.

Ik heb zelf onlangs op een conferentie m'n MacBook ongeveer een uur laten meeluisteren met FireSheep. De vangst was overweldigend; geen Facebook en Twitter logingegevens, maar wel een stuk of 50 sessies waarmee ik zonder problemen de betreffende gebruikers kon imiteren. Het mag duidelijk zijn dat ik daar geen misbruik van heb gemaakt, maar dat het eenvoudig is wordt wel geïllustreerd.

Op Tweakers.net wordt het wachtwoord bij inloggen wel versleuteld, maar eenmaal ingelogd vliegt de sessie ook plain-text door de lucht en heeft vergrendelen aan een IP geen zin omdat het gelijk zal zijn.

Het is met tools als Wireshark "kinderspel" om een scriptje te schrijven wat de meest voorkomende termen (username / nickname / password / pwd / session / etc.) uit de requestdata vist en ergens op te slaan.

Ik kan je niet 123 getallen overleggen, maar het merendeel van de sites verstuurt inloggegevens plain-text in plaats van HTTPS. Als 2% het via HTTPS zou doen verbaast me dat al. Dat de andere 98% geen high profile sites zijn maakt natuurlijk weinig uit. Als je eenmaal een wachtwoord of login combinatie hebt en vervolgens een encrypted hit op een high profile site langs ziet komen heb je bij de gemiddelde gebruiker een bijzonder grote kans dat het wachtwoord gelijk is.

Kortom, los naast het feit dat websites de verantwoordelijkheid moeten gaan nemen om verkeer "gewoon" over HTTPS te gaan sturen (inloggegevens, maar het liefst ook alle data zoals Facebook, Twitter, Foursquare inmiddels aanbieden), moet de consument ook bewust worden van de beveiligingsrisico's die het makkelijk beschikbare internet met zich mee brengen. Dat laatste is bij de gemiddelde gebruiker helaas een utopie, dus blijft de verantwoordelijkheid mijns inziens liggen bij de ontwikkelaars.

[Reactie gewijzigd door Zoefff op donderdag 19 mei 2011 18:43]

Door ronde joop, donderdag 19 mei 2011 22:00

Score: 1
Wat mij betreft zit de fout hem al in het gebruiken van een unsecure wireless netwerk. Ookal zit je op een website die de authenticatie via HTTPS doet, iedereen kan letterlijk met al je verkeer meekijken, en dus ook zijn eigen TCP/IP packets ertussen stoppen. Zolang deze maar eerder aankomen dan de packets van de echte server kan je dus gewoon wat extra scriptjes op de pagina injecteren die ingevoerde inloggegevens doorsturen naar een server die van jou is. Dus dan helpt die HTTPS verbinding niet.

Door The Zep Man, vrijdag 20 mei 2011 08:11

Score: 1
Dus dan helpt die HTTPS verbinding niet.
Ik zou je toch wat meer gaan verdiepen in de werking van SSL/TLS. Dan zal je leren dat het daadwerkelijk wel helpt tegen eavesdropping en packet injection. ;)

Door ronde joop, vrijdag 20 mei 2011 13:21

Score: 1
Wat ik probeer te zeggen is dat hier wordt gesuggereerd dat het wel veilig zou zijn als je op een onbeveiligd wireless netwerk zit en wanneer de authenticatie via SSL gaat, wat dus niet perse hoeft te zijn. Stel b.v. dat je binnenkomt op de homepage die niet via HTTPS gaat (of zelfs via google). Op dat moment kunnen er dus wel packets geinject worden, en kan je dus bijvoorbeeld uitgaande links op de pagina aanpassen. Dan zijn er dus een legio mogelijkheden, waarvan een bijvoorbeeld zorgen dat de authenticatie niet via HTTPS verloopt (als dat mogelijk is).

Door Yggdrasil, vrijdag 20 mei 2011 11:31

Score: 2
HTTPS (SSL) beveiligt de verbinding tussen jouw browser (of andere applicatie) en de server, zogenaamde end-to-end encryptie dus. De pakketjes zijn al versleuteld voordat ze je computer verlaten. Of je op een beveiligd of onbeveiligd wireless netwerk zit maakt dan ook niks uit, want als de SSL encryptie van voldoende hoog niveau is kan men aftappen wat men wil, maar de pakketjes zijn onleesbaar. Ook het 'injecteren van wat extra scriptjes' zal dan niet mogelijk zijn.

Het enige dat een beveiligd WiFi netwerk je aan extra bescherming oplevert is dat niet iedere aanvaller je verkeer kan afluisteren. Maar dat beschermt je niet per definitie tegen een man-in-the-middle aanval. Andere gebruikers die verbonden zijn met hetzelfde WiFi netwerk kunnen nog steeds toegang krijgen tot jouw netwerkverkeer. Je bent dus alleen beschermd tegen aanvallers van buiten het netwerk. Helaas komt, met name in het bedrijfsleven, een groot deel van de aanvallen van binnenuit. Gebruik dus ook SSL op je LAN en WiFi.

Dit soort aanvallen komen regelmatig voor op beveiligde WiFi netwerken in hotels of luchthavens. Ondanks de met WPA beveiligde verbinding zitten alle gebruikers op hetzelfde netwerk, en kan men verschillende soorten man-in-the-middle aanvallen op poten zetten. Het is daarom altijd verstandig op zoveel mogelijk sites SSL te gebruiken, en indien mogelijk een VPN op te zetten naar een vertrouwd netwerk voordat je niet-versleuteld verkeer over een niet-vertrouwd netwerk stuurt. Voor dat doel heb ik bijvoorbeeld een simpele PPTP VPN ingericht op mijn privé servertje.

Door Glashelder, zaterdag 21 mei 2011 12:42

Score: 1
Andere gebruikers die verbonden zijn met hetzelfde WiFi netwerk kunnen nog steeds toegang krijgen tot jouw netwerkverkeer
Dat gaat niet op met WPA2(-PSK). Ieder apparaat heeft daar een andere session key. Met wat trucs is het wel mogelijk om de juiste keys te achterhalen, maar een kwestie van alleen maar sniffen is het zeker niet. Combineer je WPA2 met een RADIUS server, dan wordt het helemaal onmogelijk omdat de benodigde sleutels dan over een door SSL gecodeerd kanaal naar de client verstuurd worden.

Door CptChaos, vrijdag 20 mei 2011 12:30

Score: 1
Desondanks wordt het "onveilig" versturen van data wel degelijk een steeds groter probleem. Ik denk dat je bang wordt van de hoeveelheid data die je kan opvissen als je een laptopje 24 uur op een onbeveiligd netwerk laat sniffen ergens in de stad of bij een druk café / restaurant.
Dit stuk verbaast mij helemaal niets en het leuke is, mensen trappen er ook heel makkelijk in, zie ook deze pagina van de Consumentenbond.

Door doeternietoe, donderdag 19 mei 2011 19:15

Score: 1
Sommige programmeurs vertikken het gewoon om de minste moeite te doen voor beveiliging. Ik maak gebruik van een website die bij iedere request twee cookies stuurt met daarin het e-mailadres en het wachtwoord. Toen ik de de developper (die ik persoonlijk ken) erop attent maakte dat dit bepaalde risico's met zich meebracht, was zijn reactie dat het wel mee zou vallen. Wie zou zo'n man-in-the-middle-attack in vredesnaam willen uitvoeren? |:(

Zolang er nog mensen rondlopen die niet bereid zijn om de minste moeite te steken in veiligheid blijven dit soort problemen spelen.

Door jj71, vrijdag 20 mei 2011 08:22

Score: 0
Ik denk dat heel veel programmeurs naïef zijn op dit gebied. Misschien hebben ze ooit op school iets over beveiliging geleerd maar dat zijn ze voor het grootste deel alweer vergeten. Dus er wordt niet (voldoende) over nagedacht wat voor beveiliging er in de applicatie moet worden toegepast.

Het is ook iets wat snel "vergeten" kan worden. Tijdens het ontwikkelen van een stuk software wordt het dan eerst op de simpele manier gedaan, zonder beveiliging, want dan is het makkelijker te testen, en dan wordt vervolgens vergeten om als het product bijna klaar is de encryptie nog toe te voegen.

Door donny007, vrijdag 20 mei 2011 08:50

Score: 0
Het is een combinatie van druk van de baas (project moet snel af) en prioriteitstelling, beveiliging staat meestal als laatst op de agenda "als er nog tijd over is". Alles wat op de achter grond gebeurt "waar de gebruiker niks van ziet" is voor de baas verloren tijd.

Door CptChaos, vrijdag 20 mei 2011 12:33

Score: 1
Ik denk dat heel veel programmeurs naïef zijn op dit gebied.
De manier van opslaan is aan de programmeur, hier wordt echter niet gesproken over de manier van opslaan, maar over de manier van versturen. Dat stuk ligt toch echt bij de systeembeheerder. Jammer dat velen daar anders over denken.

Door nXXt, donderdag 19 mei 2011 17:19

Score: 1
Wat een bizarre basisfout! Kan niet anders zeggen dan dat iemand hier blijkbaar heeft lopen slapen. Natuurlijk kan er altijd een bepaald aspect onopgemerkt blijven, maar dit is een enorm gapend gat.

Door BoomTakZaag, donderdag 19 mei 2011 17:21

Score: 1
Als een hacker je netwerk is binnengedrongen dan zal versleuteld verzenden weinig uitmaken: het type mens dat zijn netwerk slecht beveiligd zal ook niet in de gaten houden of hij/zij via https werkt. Dan is het alleen nog een kwestie van Ettercap en SSLStrip.

Door Keypunchie, donderdag 19 mei 2011 17:26

Score: 1
Zeker telefoons zijn nog wel eens "te gast" op netwerken van derden, die meer of minder beveiligd kunnen zijn.

Door Zoop, donderdag 19 mei 2011 17:22

Score: 1
Even over het hoofd gezien? Dat is niet best, zijn toch wel een van de simpelste dingen om misbruik van te maken, net als sql-injections op formulieren. Zijn gewoon dingen die je MOET beveiligen. Lijkt mij nalatigheid, maar wel goed dat ze een melding gelijk serieus nemen.

... nu maar wachten op de eerste psn opmerking :P

[Reactie gewijzigd door Zoop op donderdag 19 mei 2011 17:23]

Door nielsk89, donderdag 19 mei 2011 17:22

Score: 2
Je krijgt je eigen wachtwoord ook gewoon via wachtwoord vergeten binnen op je mobiel. Dit is al zo lang als ik het me kan herinneren dus petje af voor de 'beveiligingsonderzoeker' dat ze er zolang over gedaan hebben

Door mokkol, donderdag 19 mei 2011 17:26

Score: 1
meen je dat serieus? .... Dus het was al bekend dat de passwords niet encrypt waren opgeslagen.... Of heb ik het mis? Ze denken zeker. het gaat via mobiel dus het is veilig... Wat een kneuzen zeg. Valt me nog mee dat ze het niet via mail versturen.

Zo zie je maar weer waarom het ow zo belangrijk is dat je overal een ander wachtwoord hebt....

Door nielsk89, donderdag 19 mei 2011 17:29

Score: 1
Er zullen hier vast wel meer Hi! klanten zijn die dit kunnen bevestigen ;) Je kunt gewoon je wachtwoord opvragen en dan krijg je je eigen wachtwoord terug, dus niet een die gegenereerd is.

Door Sorcerer8472, donderdag 19 mei 2011 17:53

Score: 1
De rapen zijn behoorlijk gaar als iemand die database ooit te pakken krijgt. Is nog net een stapje erger dan unsalted md5-hashes...

Door ObAt, donderdag 19 mei 2011 17:57

Score: 2
Dat is inderdaad correct! Eigenlijk moet Hi een nieuw wachtwoord generen en deze te SMS (of beter, via een telefoongesprek) sturen.

Het aparte is, is dat ik niet snap waarom een nutteloos flash bestand de inloggegevens nodig heeft aangezien de aanbiedingen nog niet is persoonsgebonden zijn. Trouwens zat het lek niet alleen in het flashbestand maar ook in de inlogmodule op de homepage van Hi.nl. De homepage is niet beveiligd en stuurt de gegevens ook in plain text naar de servers van Hi.

Conclusie: Haastige spoed is zelden goed! Vooral als je website duizenden mensen vertegenwoordigd :)

Edit:
"De website van Hi.nl blijkt inlognamen en wachtwoorden onversleuteld te hebben verzonden."

Dat wil niet zeggen dat de gegevens onversleuteld in de database staan! Zover heb ik niet kunnen kijken op de servers (en maar goed ook!). Het enige wat ik weet is dat de gegevens onversleuteld worden verzonden naar de servers, iets wat minstens zo erg is.

[Reactie gewijzigd door ObAt op donderdag 19 mei 2011 18:00]

Door Rick2910, vrijdag 20 mei 2011 08:23

Score: 1
Je kunt gewoon je wachtwoord opvragen en dan krijg je je eigen wachtwoord terug, dus niet een die gegenereerd is.
Idem bij T-Mobile. Als je daar je wachtwoord opvraagd wordt die ook netjes in plain text gesmst.
Edit: toch nog even getest, maar ze hebben het aangepast, joehoe! Je krijgt nu een gegenereerd wachtwoord.

[Reactie gewijzigd door Rick2910 op vrijdag 20 mei 2011 08:24]

Door donny007, vrijdag 20 mei 2011 08:56

Score: 1
Ik schrik altijd van websites waar je je wachtwoord in plaintext terugkrijgt, het liefst zie ik een random wachtwoord of een link met een eenmalig token om het wachtwoord te wijzigen. Constructies als "Wat is de naam van je huisdier" zijn zo lek als een mandje, met een beetje social-engineering kom je er zo achter (bijv. op de Hyves pagina van de gebruiker staat: Huisdier: 2 Katten, lolcat, lola) of je stuurt een mailtje als dierenfan en vraagt of de gebruiker een enquête over huisdiernamen in wil vullen...

Door ThierryTale, donderdag 19 mei 2011 17:24

Score: 0
Waarom doet KPN dan zo raar met DPI? Blijkt nergens voor nodig, je kan alles zo lezen bij ze :D (dit was als lollig bedoeld, voordat straks de hele Tweakmunity er over valt ;))

[Reactie gewijzigd door ThierryTale op donderdag 19 mei 2011 17:25]

Door Wiejeben, donderdag 19 mei 2011 17:31

Score: 1
Ik vind wel eens tijd voor een Europese wet die websites met een bepaald aantal leden verplicht moeten worden om de gegevens in non-plain tekst te versturen. Als dat niet gebeurt dan moet de website een boete betalen.

Door MSommer, donderdag 19 mei 2011 17:47

Score: 0
De politiek moet zich buiten het internet houden. Punt.

Door mashell, donderdag 19 mei 2011 18:21

Score: 1
Oneens. Het feit dat soort dingen telkens kunnen gebeuren is juist een gevolg van de wetteloosheid op het internet. Ik pleit niet voor een internetpolitie maar onzorgvuldig omgaan met privacy data op het internet moet wel bestraft (kunnen) worden.

Door lukjah, donderdag 19 mei 2011 21:32

Score: 1
Dan word elke amateuristische site gelijk aangeklaagd. Dat heeft geen zin, er moet gewoon in de privacy statement komen te staan hoe de gegevens worden opgeslagen, dan ligt de keuze bij jou.

Door CptChaos, vrijdag 20 mei 2011 12:37

Score: 0
Ik vind wel eens tijd voor een Europese wet die websites met een bepaald aantal leden verplicht moeten worden om de gegevens in non-plain tekst te versturen. Als dat niet gebeurt dan moet de website een boete betalen.
Je bent niet verplicht te registreren voor een website. ;)

EDIT: Er zijn geloof ik weer downmodders aan de gang, zeker op jacht naar boostpunten?

[Reactie gewijzigd door CptChaos op vrijdag 20 mei 2011 12:54]

Door luxar, donderdag 19 mei 2011 17:37

Score: 1
Ja het is ook makkelijk om wachtwoorden uit Flash bestanden uit te lezen.
Heb hier laatst nog een document over geschreven:
Wachtwoorden uitlezen van SWF bestanden.

Door TheBorg, donderdag 19 mei 2011 18:18

Score: 1
Als je een wachtwoord opslaat in Flash ben je knettergek. Daarnaast slaat je zoekopdracht nergens op, 95% van de zoekresultaten zal inlog formulieren bevatten waar helemaal geen wachtwoord in is opgeslagen. Een Flash formulier is kwa beveiliging niet anders dan een HTML formulier. Daarnaast is het in Flash is het juist heel makkelijk om encryptie over een onbeveiligde HTTP verbinding te realiseren (kan met Javascript net zo goed maar dat is meer werk).

Door RubenBentein, donderdag 19 mei 2011 20:59

Score: 0
beetje mager dat artikel :)

Door Darkblaster, donderdag 19 mei 2011 17:54

Score: 0
sorry hoor, maar het is wel een beetje ironisch :P

ik ben zeer benieuwd naar je documenten. je praat over veiligheid, maar je verwacht wel dat we een onbekend zip bestand gaan downloaden :P

Door Wolfos, donderdag 19 mei 2011 17:56

Score: 0
Je kan gewoon de PDF bekijken, gewoon in je browser. Er staat overigens niet bijzonder veel in.

Door Hiub, donderdag 19 mei 2011 20:55

Score: 1
En daarnaast bevat het aardig wat fouten en eigenaardigheden*. Sowieso wel apart om het als losse documenten aan te bieden en niet gewoon als HTML op de website zelf. Het zijn alleen wat alineas dus met een paar h1 en p tags ben je er al :S

* bijv. compileren waar decompileren wordt bedoeld, of de tip om encrypted passwords in de swf op te slaan.. ik zou het uberhaupt niet in de swf opslaan, en alleen de hash van passwords opslaan.

[Reactie gewijzigd door Hiub op donderdag 19 mei 2011 20:58]

Door Darkblaster, donderdag 19 mei 2011 18:01

Score: 0
mijn excuses, die optie zag ik niet staan. ik trek mijn woorden in.
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 17:32 Facebook: er zijn geen problemen met privéfoto's
Vorige 16:28 Voldoende steun voor GroenLinks-voorstel netneutraliteit
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011