Vorige aflevering | Search TidBITS | Volgende aflevering
TidBITS English | TidBITS Nederlands

TidBITS Logo

TidBITS#1166, 25 maart 2013

"Je bent niet wantrouwend, ze hebben het echt op je gemunt". Dat is de les in het nummer van deze week, dat (we zweren dat we het niet van plan waren) vooral over beveiligingsvraagstukken gaat. Ten eerste: Glenn Fleishman legt uit hoe je door een kwetsbaarheid in Apples iForgot de wachtwoord-pagina opnieuw kon instellen als je alleen de geboortedatum kende. Apple repareerde dat meteen, maar wie weet hoe lang het mogelijk is geweest? Apple publiceerde ook iOS 6.1.3 ter reparatie van een bug van een maand oud, waardoor iemand met toegang tot je iPhone de toegangscode kon omzeilen en in de Telefoon-app kon komen. Apple is vorige week zo voortvarend geweest dubbele verificatie voor Apple ID's in te voeren om ongeautoriseerde wijzigingen van wachtwoorden, aankopen en verzoeken tot ondersteuning te voorkomen. Glenn Fleishman heeft alle details en de nodige instructies. En als laatste bijdrage over beveiliging aan deze aflevering, ontkracht Joe Kissell in zijn FlippedBITS-column vier wijdverspreide wachtwoordsprookjes. Andere onderwerpen dan beveiliging: Glenn gaat in op nieuws over de toekomst van RSS-lezer NetNewsWire, en Adam Engst deelt de resultaten mee van zijn tests aan de nieuwe mogelijkheid van PDFpen 6.0, om naar Word te exporteren. Belangrijke software-updates van deze week zijn Skype 6.3 en PopChar X 6.2.
 
Artikelen
 

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de VS.

Er is ook een iPhone-versie van TidBITS-NL op <http://nl.tidbits.com/TidBITS-nl-1166i.html>
En als je de volgende koppeling opneemt als bladwijzer in Safari op je iPhone, iPad of iPod touch, heb je altijd de nieuwste aflevering:
<http://nl.tidbits.com/TidBITS-nl-i.html>


Deze editie van TidBITS werd gedeeltelijk gesponsord door:
Help TidBITS te ondersteunen door onze sponsors te sponsoren!

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

Hoe je ons kunt bereiken kun je lezen op:
<de contactpagina>


iOS 6.1.3 blokkeert toegangscode-omzeilbug

  door Adam C. Engst: [email protected], @adamengst
  1 reactie (Engelstalig)

[vertaling: MSH]

Bij Apple verscheen stilletjes iOS 6.1.3, ter reparatie van een bug waardoor iemand de toegangscode van een iPhone kon omzeilen en de Telefoon-app kon gebruiken. De enige andere verandering, behalve meerdere beveiligingsreparaties, werd slechts vermeld als "Verbeteringen in de Kaarten-app voor Japan". De toegangscode-omzeilfout zou iemand met de iPhone kunnen bellen, contactgegevens kunnen inzien en foto's kunnen bekijken. Hij werd meer dan een maand geleden gepubliceerd.

De update is beschikbaar voor alle iOS-apparaten met iOS 6, inclusief de iPhone 3GS en later, de iPad 2 en later, en de vierdegeneratie-iPod touch en later. Zoals altijd zal een over-the-air-update vanuit Instellingen > Algemeen > Software-update op het apparaat zelf sneller te downloaden en te installeren zijn, maar je kunt natuurlijk ook downloaden en installeren via iTunes. De over-the-air-versie is slechts 18,2 MB voor mijn iPhone 5.

Aangezien geen van de opgeloste beveiliging-bugs ernstig is, stel ik voor dat je deze update vermijdt totdat anderen hebben bepaald of het nieuwe problemen introduceert (tenzij u Kaarten wilt gebruiken in Japan).

Een extra waarschuwing. Een van de beveiligings-gaten die gesloten werden in iOS 6.1.3 is nodig voor de jailbreak evasi0n, dus als je je iOS-apparaat wilt jailbreaken, upgrade dan niet. Dat laat je natuurlijk ook kwetsbaar blijven voor de toegangscode-bug, maar dat is een van de afwegingen bij het jailbreaken.

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


Black Pixel over de toekomst van NetNewsWire

  door Glenn Fleishman: [email protected], @glennf
  8 reacties (Engelstalig)

[vertaling: DPF]

Veel Macintoshgebruikers richten zich op Black Pixel nu Google heeft aangekondigd dat ze stoppen met de ontwikkeling van Google Reader. Black Pixel is de huidige eigenaar van NetNewsWire, de populairste Mac software voor het lezen van RSS-feeds, maar deze software is afhankelijk van Google Reader voor het synchroniseren tussen Macs en iOS-apparaten. Black Pixel zegt op hun eigen blog dat men druk bezig is met een nieuwe versie van NetNewsWire voor de Mac en iOS, en heeft bovendien plannen om te beginnen met een eigen synchronisatiedienst. (Voor andere opties verwijzen we je naar "Alternatieven voor Google Reader onderzoeken", 18 maart 2013, en lees ook "Overpeinzingen bij het verscheiden van Google Reader", 14 maart 2013.)

NetNewsWire werd oorspronkelijk ontwikkeld door Brent Simmons en uitgebracht in 2002. Hij verkocht het programma aan NewsGator in 2005, maar bleef zelf wel ontwikkelaar en bracht ook iOS-versies uit. In 2008 stapte NewsGator over van een betaalde en een gratis "lite" release over op een enkele gratis versie met advertenties, waarbij je kon betalen om die advertenties te verwijderen. Het was daarna Simmons' eigen idee om NetNewsWire aan Black Pixel te verkopen. Dat gebeurde in juni 2011. Black Pixel heeft het programma sindsdien onderhouden.

In de tussenliggende tijd, schrijft Daniel Pasco (baas van Black Pixel), heeft het bedrijf de Mac-versie flink herzien en de iOS-versies volledig herschreven. Simmons zag aankomen dat dat te veel werk was voor een eenmansbedrijf, en het leek hem dus een goede stap om de software door te geven aan een groep ontwikkelaars.

Pasco schrijft verder dat Black Pixel zich ervan bewust was dat het bedrijf een alternatief moest zien te vinden voor Google Reader: met het verschijnen van Google+ en het daaropvolgende verdwijnen van deelmogelijkheden in Google Reader was het duidelijk voor analisten dat Google Reader ten dode was opgeschreven.

Black Pixel was in eerste instantie van plan om iCloud met zijn ondersteuning van Core Data te gaan gebruiken voor het synchroniseren. Zoals we echter van veel ontwikkelaars horen is het bouwen van diensten op iCloud nogal teleurstellend. De dienst is misschien robuust, maar de interface en de mogelijkheden komen slecht overeen met de behoeften van ontwikkelaars. Black Pixel zal in plaats daarvan een eigen synchronisatiemogelijkheid gaan bouwen.

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


Beveiligingslek liet makkelijk opnieuw instellen van Apple ID-wachtwoord toe

  door Glenn Fleishman: [email protected], @glennf
  2 reacties (Engelstalig)

[vertaling: HR]

The Verge meldde dat Apples pagina om het wachtwoord van je Apple ID opnieuw in te stellen, iForgot, een zwakheid bevatte, waarvan de instructies beschreven waren in een openlijk beschikbaar document. Er was een aangepaste URL nodig om de iForgot-pagina te openen, samen met kennis van het e-mailadres van een gebruiker en de geboortedatum. (The Verge geeft geen link naar de instructies, en wij ook niet.) Apple sloot snel de iForgot-pagina, en heropende later op de dag een versie met een aangepaste procedure.

Jammer genoeg is iemands geboortedatum makkelijk te vinden. Er wordt naar gevraagd door sociale-netwerkdiensten zoals Facebook en Google+, en hij is op die manier vaak beschikbaar voor onze online "vrienden". (Je gaat je afvragen of het "bevrienden" van al die mensen die je nauwelijks kent wel zo'n goed idee was, niet?) Het is ook makkelijk om op Twitter te zoeken naar verjaardagswensen en om dan een onderbouwde gooi te doen naar iemands geboortejaar. En dat alles zonder rekening te houden met het feit dat onze informatie wellicht reeds in bezit is van hackers, gezien de gepleegde inbraken in kredietkaartgegevens en andere bestanden. Geboortedatuminformatie kan ook verkregen worden via goedkope online identiteitszoekbestanden.

Tegen het eind van de dag nadat het nieuws was verschenen had Apple iForgot weer heropend, met twee opties om een wachtwoord opnieuw in te stellen: of via het herstel-e-mailadres, voor zover ingesteld in een Apple ID-account of via de beantwoording van een aantal beveiligingsvragen en antwoorden gemaakt tijdens het aanmaken van een account (of later, nadat Apple deze zwakke verificatie-optie had toegevoegd aan alle accounts).

Gebruikers die zijn overgestapt naar dubbele verificatie, door Apple slechts een dag eerder geïntroduceerd in een aantal Engelstalige landen (zie "Apple voert dubbele verificatie in voor Apple ID's", 21 maart 2013) werden niet geraakt door het gat in de beveiliging. In Apples dubbele-verificatiesysteem kan een wachtwoord alleen opnieuw worden ingesteld via een apparaat dat is geverifieerd met een Apple ID-account en een herstelsleutel. (Verlies van een wachtwoord en van een van de twee andere onderdelen zal een Apple ID-account permanent afsluiten!)

The Verge en andere websites leggen niet uit waarom het nuttig zou zijn voor iemand die toegang zoekt tot je account om je wachtwoord opnieuw in te stellen. Het is toch zeker zo dat als instructies voor een nieuw wachtwoord naar je e-mailadres worden gestuurd, de aanvaller reeds je logingegevens heeft? Niet noodzakelijkerwijs.

De aanvaller zou een manier gevonden kunnen hebben om je e-mail te lezen doordat hij een van je apparaten heeft gestolen of daar tijdelijk toegang tot heeft. Of door het kraken van een willekeurig e-mailaccount waar de mail van het hoofdadres naartoe wordt doorgestuurd. In dat soort gevallen kan hij niet inloggen in een van de andere services of een aankoop doen met dat e-mailaccount.

Maar als het wachtwoord van een Apple ID, waarvan de aanvaller de e-mail kan lezen (zelfs tijdelijk), opnieuw kan worden ingesteld, dan zou dat toegang geven tot aankopen via iTunes, contacten en kalendergegevens opgeslagen in iCloud, Vind Mijn iPhone en andere gerelateerde gegevens. Natuurlijk wordt de truc ontdekt zodra de eigenaar het goede wachtwoord moet invoeren en merkt dat het niet werkt. Maar tegen die tijd zou er al zoveel schade kunnen zijn aangericht, dat het een zorgelijke of kostbare zaak wordt.

Daarom is het enigszins vreemd dat via de nieuwe iForgot-pagina instructies om een wachtwoord te vernieuwen naar een apart e-mailadres kunnen worden gestuurd, aangezien veel mensen meerdere adressen hebben ingesteld in een e-mailprogramma. Als de slechterik fysieke toegang heeft tot een apparaat, en nog niet helemaal heeft uitgevogeld hoe hij een specifiek e-mailaccount moet binnenkomen, zouden de instructies ook voor hem beschikbaar zijn. Maar meer kan Apple niet doen. Het moet mogelijk zijn om een wachtwoord opnieuw in te stellen, en het sturen van instructies per e-mail is een van de aanvaardbare mogelijkheden.

Om eerlijk te zijn zou het soort lek dat Apple dicht eerder gebruikt kunnen worden door iemand in je nabijheid (die de mogelijkheid heeft om je geboortedatum te ontdekken en die bij je e-mail kan komen op precies het goede moment om de instructies voor het opnieuw instellen te ontvangen) dan door een anonieme boosdoener. Tieners en jonge mensen lopen waarschijnlijk het meeste risico, gezien het ongebreideld delen van apparatuur en informatie, inclusief gevoelige gegevens. Stel je het drama voor van een afgewezen minaar die deze techniek gebruikt om de andere persoon op te sporen via Vind Mijn iPhone!

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


FlippedBITS: vier wachtwoordsprookjes

  door Joe Kissell: [email protected], @joekissell
  13 reacties (Engelstalig)

[vertaling: RAW, JO, LmR]

Tijdens het schrijven van "Take Control of Your Passwords" kwam ik nogal wat mythes tegen over wachtwoordbeveiliging die ik geprobeerd heb te ontkrachten. Natuurlijk wil ik je aanmoedigen om het boek te kopen en de details van wachtwoordproblemen en mijn aanbevolen oplossingen te lezen, maar voor deze aflevering van FlippedBITS wilde ik me richten op vier zeer wijdverspreide misvattingen over wachtwoorden die allemaal kunnen leiden tot gevaarlijk gedrag.

1: negen is genoeg -- Ik wil beginnen met een sprookje dat ik zelf verspreidde met mijn nu achterhaalde boek "Take Control of Passwords in Mac OS X" uit 2006. Hoewel wat ik in dat boek zei redelijk was gezien de toen beschikbare gegevens, heb ik destijds de snelheid van technologische vooruitgang zwaar onderschat. Dus ik trek hierbij met excuses een specifiek advies in dat ik toentertijd gaf: ik zei dat als je een willekeurig wachtwoord van 9 tekens koos met hoofd- en kleine letters, cijfers en leestekens, je feitelijk beschermd zou zijn tegen alle aanvallen, omdat het gemiddeld eeuwen zou duren voordat zelfs een supercomputer zo'n wachtwoord met brute kracht zou kunnen breken.

Nou, het blijkt dat ik er meerdere ordes van grootte naast zat. Vandaag de dag, met standaard apparatuur en gratis beschikbare kraaksoftware, kan een wachtwoord van 9 tekens gekraakt worden in maximaal vijf en een half uur (dat is maximaal, niet minimaal!). Als je wachtwoord negen of minder tekens bevat, ongeacht hoe willekeurig die mogen zijn, is het ongeveer net zo onveilig als een draadloze verbinding die met WEP beveiligd is, dus alleen bestand tegen het oppervlakkigste neuzen.

Als negen tekens tegenwoordig te weinig voor een goed wachtwoord is, hoeveel moeten het er dan wel zijn? Ik wou dat ik je een simpel antwoord kon geven. De waarheid is, dat het er maar van afhangt. Het zou bijvoorbeeld niet raar zijn om te stellen dat een wachtwoord van 14 willekeurige tekens, gezien de huidige technieken, veilig genoeg is om een aanval met brute kracht te weerstaan. Maar dan moet ik er een paar dingen bij vertellen.

Ten eerste heb ik geen idee hoe de techniek zich in de toekomst zal ontwikkelen. Misschien ontwikkelt iemand binnen een paar jaar een kwantum-computer die een willekeurig wachtwoord van 14 tekens in een tel kraakt. Ik verwacht niet dat dit zo snel zal gebeuren, maar ik zou wel gek zijn om te wedden op het tegendeel.

Ten tweede zijn niet alle versleuteltechnieken even veilig. Een wachtwoord dat wordt versleuteld met een zwak algoritme kan soms in enkele seconden gekraakt worden, terwijl hetzelfde wachtwoord onder een beter algoritme jarenlang opgewassen is tegen iedere aanval met brute kracht. Hiermee samenhangend: er zijn beveiligingssystemen voor wachtwoorden die bepaalde lagen van beveiliging toevoegen, die het raden van wachtwoorden sterk vertragen. Hoewel deze systemen niet foolproof zijn (zoals ik hieronder verder zal toelichten) versterken ze in bepaalde situaties de effectiviteit van simpele wachtwoorden.

Ten derde is de lengte van een wachtwoord niet de enige factor die zijn kracht bepaalt. Zoals op een briljante manier geïllustreerd wordt in de xkcd-strip Password Strength, kan zelfs een wachtwoord dat uit alleen maar kleine letters en gewone Engelse woorden bestaat (zoals "correct horse battery staple") even sterk zijn als een korter, volkomen willekeurig wachtwoord met een sterke mix van tekens. Dat komt doordat de entropie van een wachtwoord (de wiskundige benadering van de moeite die het kost om een wachtwoord te raden) het product kan zijn van lengte, de complexiteit van de verzameling tekens, de toevalligheid, of van iedere combinatie hiervan. Wachtwoorden met een hogere entropie zijn beter bestand tegen geautomatiseerde aanvallen, maar er zijn verschillende manieren om die entropie te verkrijgen. (Als je de entropie van een gegeven wachtwoord wilt testen, dan kan je daarvoor online veel testmethodes vinden. Ik gebruik het hulpmiddel zxcvbn nogal graag).

Geruststellend is het feit dat elk teken dat je toevoegt aan je wachtwoord een exponentieel sterker wachtwoord oplevert. Als je uitgaat van slechts 26 (niet hoofd-) letters in het alfabet, dan is een wachtwoord met tien tekens niet tien procent sterker dan één van negen, het is 26 keer zo goed! Er zijn meer dan vijf biljoen mogelijke wachtwoorden samen te stellen uit negen kleine letters (26 tot de macht 9). En tien letters levert 141 biljoen mogelijkheden op. Dat betekent dat een systeem dat een wachtwoord van negen letters kan kraken in 5,5 uur, meer dan 500 uur nodig heeft voor een wachtwoord van tien willekeurige tekens, en dat maakt een enorm verschil.

Dan nog, vind ik 500 uur niet erg geruststellend. Je kan daar eenvoudig 500 jaar van maken door een 12-cijferig wachtwoord te kiezen, en dan lijkt het zeker veilig genoeg voor de dagelijkse praktijk. Maar aan de andere kant dacht ik zeven jaar geleden hetzelfde van 9-cijferige wachtwoorden. Dus als ik een aantal van veertien aanraad als een veilig aantal tekens, dan bouw ik daarmee een buffer in voor de komende paar jaar technologische ontwikkeling. (Maar daarmee zou ik niet durven beweren dat zo'n wachtwoord onkraakbaar is voor de komende 4.000 millennia die het met de huidige stand van zaken zou kosten om 'm te ontcijferen ...)

2: Van een sluwe oude vos en moderne jachttechnieken -- Ik heb nogal wat mensen ontmoet, waaronder een aantal bekenden uit de Mac-wereld die de lezer ook zou kennen, die door de tijd heen geheugentrucjes ontwikkelden om wachtwoorden te maken en deze te kunnen herinneren (met het idee dat dit dan ook sterke wachtwoorden waren). Hoewel ieder het weer op z'n eigen manier doet, wordt meestal een steeds terugkerend element gebruikt, of een eenvoudig patroon dat terugkomt in elk wachtwoord gecombineerd met een onderdeeltje dat verwijst naar de site waar het bij hoort. Zo zou ik bijvoorbeeld zombieGooCats voor Google en zombieAppCats voor Apple kunnen gebruiken. In werkelijkheid gebruiken deze mensen veel doordachter technieken, maar je begrijpt waar ik heen wil.

Ikzelf (ahum) adviseerde vroeger ook een dergelijke benadering, maar ik heb ondertussen het licht gezien. Het probleem met al deze trucjes is, (en dat geldt ook voor bijvoorbeeld "leet" of 1337, waarbij je letters vervangt door cijfers die op letters lijken, het gebruik van patronen op je toetsenbord, et cetera), dat hoe slim je ook doet, hackers en hun uitgebreide kraak-algoritmes altijd slimmer zijn. Die algoritmes kunnen een ontzettende grote variëteit aan subtiele patronen uitproberen, patronen die mensen zelf vaak niet eens herkennen, en dit betekent dat zelfs een vrij lang, tamelijk random-uitziend wachtwoord misschien in feite heel makkelijk te raden is. Want realiseer je dit: we zijn niet zozeer beducht voor mensen die je wachtwoord zouden kunnen raden, maar vooral voor machines die dit doen. Want machines testen als eerste al die lage-entropie-wachtwoorden, vooral de soort die gebaseerd is op veel voorkomende geheugentrucjes, lang voordat ze zich bezig hoeven te houden met de moeilijker wachtwoorden. En als je dus eenzelfde techniek gebruikt om al je wachtwoorden volgens een patroon te creëren, dan zal een aanvaller die een of meer van jouw wachtwoorden in handen heeft het nog veel makkelijker hebben bij het raden van de rest.

Meer specifiek: iedere techniek die steunt op het vermogen van je hersenen om al je wchtwoorden te onthouden is mijns inziens een verspilling van energie die beter voor iets anders gebruikt zou kunnen worden zoals het verzinnen van slechte grappen. We hebben computers, iPads, iPhones en andere apparaten om dit soort dingen voor ons te doen en die zijn er veel beter in dan wij. Als je een wachtwoordbeheerprogramma zoals 1Password of LastPass gebruikt voor het genereren, onthouden en invoeren van wachtwoorden, dan kan je ze zo lang en willekeurig maken als je wilt. Het is voor een app niet meer moeite om een wachtwoord van 32 karakters te maken dan een van 10. Natuurlijk zal je een paar wachtwoorden moeten blijven onthouden maar als je het goed doet hoeven dat er slechts een paar te zijn. (Ik onthoud maar 5 wachtwoorden van de meer dan 600.)

3: Eén wachtwoord dat heerst over alle andere -- Over wachtwoordbeheerprogramma's gesproken: deze maken het makkelijk om voor iedere website of dienst die wachtwoorden gebruikt een uniek en willekeurig wachtwoord aan te maken. Ik raad dan ook aan om dat te doen. Ik kan niet genoeg benadrukken hoe onverstandig het is om hetzelfde wachtwoord op meer dan één plek te gebruiken, zelfs als het een geweldig wachtwoord is. Het feit dat het hergebruik van wachtwoorden geheel overbodig is als je gebruikmaakt van geautomatiseerde software, maakt deze fout eigenlijk alleen maar erger.

Waarom is het zo slecht om wachtwoorden te hergebruiken? Welnu, het lijkt wel alsof er iedere week wel ergens in de kranten staat dat een of ander bedrijf een beveiligingslek heeft aangetroffen waardoor er duizenden of miljoenen wachtwoorden zijn verdwenen, gestolen, uitgelekt of gehackt. Onlangs gebeurde dit bij Evernote, en daarvoor was er een lange lijst van bedrijven waarbij wachtwoorden waren ontvreemd: Facebook, LinkedIn, Twitter en vele anderen. Je kunt er rustig vanuit gaan dat deze trend zich voort zal zetten.

Als iemand nu de servers van Amazon.com hackt en jouw wachtwoord te pakken krijgt is dat natuurlijk een probleem. Maar als je allemaal unieke wachtwoorden gebruikt, dan blijft de schade tenminste beperkt tot dat ene account. Als je aan de andere kant hetzelfde wachtwoord hebt gebruikt voor iCloud, PayPal, Twitter, Gmail enzovoort, loop je het niet ondenkbare risico dat de aanvaller jouw wachtwoord ook op al die sites gaat gebruiken, waardoor de schade aanzienlijk toeneemt.

Ik zeg niet dat het gebruik van unieke wachtwoorden (zelfs sterke unieke wachtwoorden) veiligheid garandeert. Maar het zorgt er wel voor dat je de schade kan beperken tot die site die gekraakt is. De mensen die de meeste kans lopen het slachtoffer te worden van het kraken van wachtwoorden zijn zij die de gevaren van wachtwoord-hergebruik niet kennen. Wees niet een van hen!

4: Online en offline aanvallen -- Eerder sprak ik al over hoe sommige sites en diensten stappen hebben ondernomen om automatische aanvallen af te remmen of te blokkeren. Bijvoorbeeld als je een typefout maakt in je wachtwoord, krijg je misschien maar één of een paar keer de mogelijkheid om het opnieuw in te voeren, maar met steeds grotere tussenpozen. En als je het een aantal keer achter elkaar verkeerd invoert wordt je dan afgesloten voor een langere tijd of totdat je zelf stappen onderneemt om te bevestigen dat jij het bent. De bedoeling van dit soort barrières is om te voorkomen dat een automatisch systeem talloze wachtwoorden per seconde kan proberen tot het je account binnenkomt.

Hoewel het een uitstekend idee is als ontwikkelaars dit soort barrières opwerpen, zijn ze niet zo sterk als ze lijken. Want de meeste succesvolle aanvallen gaan niet via de voordeur, als het ware. Het echte gevaar is als iemand door een lek het versleutelde bestand of de database te pakken krijgt waar alle wachtwoorden van een site in zijn opgeslagen. Hebben ze dit bestand dan kunnen ze een zogenaamde "offline" aanval uitvoeren: ze bestoken het bestand met geautomatiseerde programma's die miljarden mogelijke wachtwoorden per seconde proberen. Omdat ze de beveiliging die het invoeren van wachtwoorden vertraagd, hebben omzeild kunnen ze in korte tijd mogelijk enorme hoeveelheden wachtwoorden ontsleutelen. (Ik schilder het iets eenvoudiger af dan het in werkelijkheid. Slimme ontwikkelaars kunnen ook een combinatie van technieken gebruiken - de termen waar je op moet letten zijn "salting" en "hashing" - om offline aanvallen tegen te werken maar vaak genoeg laten programmeerfouten of een onhandige beveiligingskeuze enorme gaten laten die de hacker kan misbruiken.)

Dus ga er niet vanuit dat je een kort, simpel wachtwoord kan gebruiken omdat jij niet ziet hoe een aanvaller miljarden wachtwoorden per seconde kan proberen. Je zal nog verbaasd staan wat iemand allemaal kan, vooral als deze fysieke toegang heeft tot de computer waar het wachtwoord is opgeslagen. Je beste verdediging is om een hoogwaardig wachtwoord te gebruiken (dat moeilijker te raden is) en ervoor te zorgen dat ieder wachtwoord uniek is.

Don't Worry, Be Happy Als ik je nu bang heb gemaakt voor wachtwoorden door te vertellen wat er mis is met de technieken die je nu gebruikt, dan spijt dat mij zeer. Nou ja, een beetje, want ik wil dat je je net ongemakkelijk genoeg voelt om je wachtwoordbeveiliging te verbeteren en de kans te verkleinen dat er iets naars gebeurt in je digitale leven. Voor uitgebreide details over wachtwoorden, waaronder bijkomende risico's die je bedreigen, en mijn stress-vrije driestappenstrategie voor wachtwoordbeveiliging, moet je een exemplaar aanschaffen van "Take Control of Your Passwords".

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


Apple voert dubbele verificatie in voor Apple ID's

  door Glenn Fleishman: [email protected], @glennf
  22 reacties (Engelstalig)

[vertaling: RAW, TK, HV]

Apple heeft vorige week in stilte de mogelijkheid tot dubbele verificatie voor Apple ID-accounts ingevoerd en zich daarmee gevoegd bij Google, Dropbox, PayPal, Facebook en een steeds groeiend aantal andere websites. Deze extra verificatielaag helpt om de steeds belangrijkere Apple ID-accounts te beschermen waarop miljoenen Mac- en iOS-gebruikers vertrouwen voor hun aankopen in de iTunes Store en App Store, het inloggen bij iCloud en het delen van gegevens, ondersteuning van Apple, enzovoort.

Hoewel het niet verplicht is, raden we je aan om dubbele verificatie zo snel als jou dat uitkomt aan te zetten. Omdat cybercriminelen gekraakte Apple ID-accounts kunnen gebruiken om geld weg te sluizen van kredietkaarten en je digitale identiteit over te nemen, is het niet langer paranoïde om bezorgd te zijn dat je wachtwoord gestolen wordt. Hoewel het gedoe lijkt en de instelling zorgvuldig dient te gebeuren, zal Apples dubbele verificatie geen groot effect op je leven hebben. Apple zegt dat er maar drie situaties zijn waarin dubbele verificatie zal worden gevraagd:

De beveiligingsvergelijking factoriseren -- De "factoren" van een dubbele verificatie ["two-factor authentication" - nvdv] verwijzen naar twee afzonderlijke privĂ©-elementen die je moet kennen of waarover je moet beschikken om te kunnen inloggen. De eerste factor is doorgaans een wachtwoord, zoals dit ook nog het geval is bij Apple ID's. De tweede is een extern element: een code die alleen bekend is of gecreëerd kan worden met afzonderlijk voorziene hardware of afzonderlijk geregistreerde software. Dit externe deel is belangrijk om ervoor te zorgen dat iemand die je wachtwoord al kent of toegang heeft gekregen tot je computer via hetzelfde medium geen toegang heeft tot de tweede factor.

Dubbele verificatie was vroeger lapwerk, maar met de stijging van onlinemisdaad, is er steeds meer ondersteuning voor. Ik heb twee aparte digitale sleutels, één voor PayPal/eBay en een andere voor E*Trade, en om in te loggen op deze diensten moet ik een getal met zes cijfers invoeren dat op de sleutel verschijnt. Dat getal verandert elke minuut. Google biedt Google Authenticator aan, een mobiele app voor iOS, Android en BlackBerry die hetzelfde type code op een praktischer manier kan bieden, wanneer je het hebt gekoppeld aan je Google-account. Dropbox kan ook werken met Google Authenticator, wat wel praktisch is. Dit is gebaseerd op een afzonderlijk geregistreerd en gegenereerd item in de app. Zelfs Facebook biedt dubbele verificatie via een combinatie van sms-berichten en de Facebook iOS-app. Veel andere diensten zonder apps werken voor de externe component ook met sms-berichten met een code naar een mobiel apparaat waarover jij de controle hebt.


Deze dubbele methode vervangt de "beveiligingsvragen" die Apple en veel andere ondernemingen lange tijd hebben gebruikt. Deze vragen komen gewoonlijk uit een lijst met mogelijkheden zoals "Wie was je beste vriend op school?" Maar deze vragen kunnen dubbelzinnig zijn en kunnen vaak gemakkelijk worden gehackt door identiteitsdieven die je persoonlijke details bijeensprokkelen via Google, Facebook of andere diensten met persoonlijke informatie. (In "Take Control of Your Passwords" raadt Joe Kissell aan om een paszin te gebruiken, en niet een juist antwoord, voor elke beveiligingsvraag.)

Erger nog, zoals Mat Honan uitgebreid heeft beschreven toen zijn eigen accounts waren gekaapt: krakers kunnen soms een account overnemen met een combinatie van social engineering en logische tekortkomingen in procedures voor het opnieuw instellen van een wachtwoord. Vroeger kon je in Amazon via telefoon een e-mailadres toevoegen als je de laatste vier cijfers van een geregistreerde kredietkaart kende. Maar een kredietkaart kon je ook telefonisch toevoegen. Krakers realiseerden zich dat zij eerst de kredietkaart konden toevoegen, ophangen, en dan opnieuw bellen om een eigen e-mailadres toe te voegen met het gestolen (maar nog niet geblokkeerde) of verzonnen (maar wel correct gevormde) kaartnummer dat ze net hadden doorgegeven. Vervolgens konden ze een bericht naar hun e-mailadres laten sturen om een wachtwoord opnieuw in te stellen.

Honan beschreef dat een aanvaller bij een Amazon-account dan de vier laatste cijfers van andere opgeslagen kredietkaartnummers voor dat account kon zien, en met die informatie wachtwoorden opnieuw kon instellen of e-mailadressen kon toevoegen aan een Apple ID of accounts bij andere sites.

Dergelijke aanvallen mislukken wanneer de dief zowel het wachtwoord opnieuw moet instellen als fysiek in het bezit moet zijn van een onvergrendeld apparaat dat eigendom is van het slachtoffer of sms-berichten voor die persoon moet onderscheppen. Voor gesofisticeerde aanvallen op een persoon (laat ons zeggen iemand die actief is in spionage door de overheid of een onderneming of zelfs een heel slechte scheiding) volstaat zelfs dubbele verificatie misschien nog niet, maar voor gewone aanvallen op je identiteit is het meer dan voldoende.

Factoriseer je beslissing -- Voor je de dubbele verificatie van Apple instelt, denk je best na over hoe de toekomst eruitziet na de overstap, aangezien er voor- én nadelen aan de nieuwe methode zijn.

Voordelen:

Maar er zijn ook wel enkele nadelen:

Bovendien zijn er twee soorten toegang die niet beschermd worden door dubbele verificatie:

O, en als je de afgelopen dagen belangrijke wijzigingen hebt aangebracht in je Apple ID-account kun je drie dagen lang dubbele verificatie niet aanzetten. En als het wachtwoord van je Apple ID niet sterk genoeg is volgens Apple (zie "FlippedBITS: vier wachtwoordsprookjes", 20 maart 2013), wordt je gedwongen om het te wijzigen, en vervolgens om drie dagen te wachten.

Apples dubbele verificatie activeren -- Als je zover bent kun je de stappen in Apples handleiding volgen als je in een ondersteund land verblijft, of onze versie, verderop, gebruiken. (Apple heeft dubbele verificatie voorlopig mogelijk gemaakt in de Verenigde Staten, Groot-Brittannië, Australië, Ierland en Nieuw Zeeland. Andere landen volgen later. Wellicht een lokalisatie-kwestie.) [Dit werkt dus niet vanuit Nederland, dan wel vanaf een Nederlands Apple ID-account - nvdv]

  1. Ga naar de Mijn Apple ID-website, klik op Beheer uw Apple ID, en log in met je huidige ID en wachtwoord.

  2. Klik op Wachtwoord en beveiliging (links), geef antwoord op de getoonde beveiligingsvragen, en klik op Doorgaan.

  3. Klik onder het kopje "Twee-staps-verificatie" en de bijbehorende tekst de koppeling "Aan de slag".


  4. Apple toont je vervolgens drie schermen met informatie, voordelen, en waarschuwingen. Lees ze allemaal en klik Ga verder op de eerste twee schermen, en Aan de slag op het laatste.


  5. Vervolgens toont Apple een lijst met alle iOS-apparaten die aan je account gekoppeld zijn en laat je sms-nummers invoeren voor mobiele telefoons. Als je al je apparaten geverifieerd hebt, klik je op Ga verder.

  6. Apple verstrekt je een herstel-code van 14 tekens die nooit meer te achterhalen is als je hem kwijtraakt. Klik op Ga verder of op Print Key om door te gaan. Apple raadt je aan om deze herstel-code op te schrijven, en om hem niet op je Mac te bewaren. Dat is een verstandig raad. Aan de andere kant: als je een programma hebt om zaken als wachtwoorden versleuteld te bewaren (zoals 1Password of Yojimbo) en je daarvoor een veilig wachtwoord gebruikt (dat je dan inderdaad niet op je computer moet bewaren), ben je toch wel veilig bezig.

  7. Vervolgens moet je de herstel-code intikken, om te bewijzen dat je hem inderdaad ergens opgeslagen hebt! Tik hem in en klik op BEvestigen. Die koppeling wordt alleen actief als je de correcte code hebt ingetikt.

  8. Je krijgt dan nog een laatste scherm met waarschuwingen te zien, waarop nogmaals wordt uitgelegd wat een problemen je hebt als je, na activatie van dubbele verificatie, twee van de drie zaken verliest die je nodig hebt om je account opnieuw in te stellen. Klik op "Ik begrijp bovendtaande voorwaarden" en vervolgens op "Schakel twee-staps verificatie in". De pagina Veiligheidsinstellingen beheren meldt dan "Twee-staps verificatie ingeschakeld".


Meteen daarna krijg je een bevestiging per e-mail van de wijziging in alle bijbehorende accounts. En dan bedoel ik ook meteen. Bij mij binnen een paar seconden.

Vanaf dat moment wordt je elke keer als je een beveiligde Apple-dienst benadert, zoals de pagina Uw Apple ID beheren van de Mijn Apple ID-website, gevraagd welke methode je wilt gebruiken om jezelf te identificeren. Selecteer de gewenste methode en ga door. Er wordt een code verstuurd langs de gekozen weg. Vul die code in om verder te gaan.



Geen universele oplossing -- Dubbele verificatie lost niet alle problemen op met identificatie en diefstal van identiteit, maar wel de belangrijkste: het wijzigen van wachtwoorden om een account te kapen, aankopen bij Apple-diensten vanaf onbekende apparaten, en "social engineering" via de telefoon.

Ik heb het geactiveerd voor het account dat ik gebruik voor het doen van aankopen, en ik raad iedereen aan hetzelfde te doen. Zorg wel dat je van te voren alles (inclusief je apparaten, en de bijbehorende Apple ID's) op een rijtje hebt!

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


PDFpen 6.0 kan nu naar Word exporteren

  door Adam C. Engst: [email protected], @adamengst
  8 reacties (Engelstalig)

[vertaling: JWB, GvH, PAB]

Het EPUB-formaat mag dan in de e-boekenwereld de meeste persaandacht krijgen, maar onder de professionals in de zakenwereld die zich met documenten bezighouden, is PDF nog steeds koning en blijven gereedschappen als Smiles PDFpen en PDFpenPro essentieel. Smile komt nu met versie 6.0 van beide versies van PDFpen, die nu ook in staat zijn om PDF's om te zetten in Word-documenten, de PDF-bewerking vereenvoudigen met een nieuwe werkbalk, ondersteuning bieden voor Automatisch bewaren en Versies en meer. De updates kosten $ 30 of $ 40, afhankelijk van de versie en de manier van upgraden. PDFpen 6.0 vereist OS X 10.7 Lion of 10.8 Mountain Lion.

Apples waanzinnige upgrade-dans -- Normaal gesproken bewaar ik upgrade-details voor het eind, maar door Apples ontwikkelaar-vijandige beleid rondom de Mac App Store kan het een beetje verwarrend zijn. Wanneer je rechtstreeks bij Smile hebt gekocht en via hen wilt upgraden, zijn de zaken simpel: de upgrade voor elke versie van PDFpen kost $ 30, en wanneer je tegelijkertijd van PDFpen op PDFpenPro wilt overstappen kost het $ 40. Maar omdat PDFpen en PDFpenPro ook via de Mac App Store verkocht worden, waar Apple betaalde upgrades niet toestaat, heeft Smile compleet nieuwe apps uitgebracht voor PDFpen en PDFpenPro. Om het pijnlijk duidelijk te maken: wanneer je een oudere versie van PDFpen hebt gekocht via de Mac App Store, zul je geen enkel bericht krijgen noch een upgrade-korting. Je moet een nieuw exemplaar kopen om te "upgraden". (Smile had gedurende 48 uur de prijs verlaagd in de Mac App Store, maar die tijd is reeds verstreken.)

Maar wacht, het wordt nog ingewikkelder! Apple staat niet toe dat apps die buiten de Mac App Store om gekocht worden gebruikmaken van document-synchronisatie via iCloud, dus als je van die functionaliteit gebruik wilt maken zul je PDFpen in de Mac App Store moeten kopen, zelfs al heb je het eerder via Smile gekocht. Exemplaren die bij Smile zijn gekocht zullen geen documenten kunnen openen of opslaan in iCloud. Gelukkig is synchronisatie via Dropbox wel gewoon mogelijk, dus als je rechtstreeks zakendoet met Smile (waar zij 20 procent meer aan verdienen) weerhoudt dat je er niet van om documenten via een Cloud-opslagdienst te synchroniseren.

Als je PDFpen bij Smile hebt gekocht op of na 15 oktober 2012, is je upgrade via hen gratis en zou die automatisch moeten plaatsvinden. De interne functie Check for Updates zal de nieuwe versie downloaden en je door het proces heen helpen om je serienummer te updaten.

Theoretisch zou je de probeerversie van PDFpen 6.0 moeten kunnen testen en later kunnen teruggaan naar je oorspronkelijke versie. Het programma voor het automatisch updaten moet in principe de vorige versie van PDFpen in de map Programma's bewaren. Bij één test gebeurde dat hier overigens niet, dus adviseer ik een zip-archief-bestand van de oude versie PDFpen 5.x te maken voordat je het upgrade-proces laat draaien, voor het geval dat. (Klik op PDFpen mét de control-toets en kies "Comprimeer PDFpen".) Of je download gewoon opnieuw een exemplaar vanaf de download-pagina van Smile.

Exporteren naar Word -- Maar dan nu even terug naar de reden waarom je zou willen upgraden van PDFpen 5.x naar 6.0: de '5-sterren-eigenschap' van de nieuwe versie is de mogelijkheid te exporteren naar Microsoft Word-formaat (.doc of .docx). Daarna kun je met de tekst verder werken op elke manier die je wenst, hoewel je misschien niet een nieuw PDF-bestand kunt creëren dat helemaal op de oorspronkelijke versie lijkt.

Deze eigenschap maakt gebruik van de "Cloud Document Conversion Service" van Nuance OmniPage en is alleen beschikbaar voor geregistreerde gebruikers (dat betekent dat het niet zal werken met probeerversies van PDFpen 6.0. Smile heeft een paar voorbeelden van export-bestanden om te bekijken voordat je beslist te kopen.) Misschien was het omdat je de licentie-overeenkomst eerst moet accepteren, dat ik merkte dat ik Archief > Export twee keer moest kiezen voordat het werkte. Dus als je hier de eerste keer problemen mee hebt, probeer het dan nog eens.

Exporteren gaat niet zo snel als "Opslaan als..". Een test-document van zeven bladzijden duurde 20 tot 30 seconden, en als martel-test voerde ik de 226 bladzijden in van "Take Control of Your iPad, Second Edition" en kreeg een schatting terug van ruim 37 minuten. Gelukkig duurde het maar 7 minuten. Bovendien kun je aan de voortgangsbalk en de teller van verstreken tijd zien hoe lang het werkelijk zal gaan duren. Ook al kun je niet verder werken in het document dat bezig is te worden omgezet, je kunt wel andere documenten in PDFpen 6.0 openen en daarin werken terwijl die omzetting plaatsvindt.


De werkelijke vraag is hoe goed de omzetting is. Eerlijk gezegd was ik behoorlijk onder de indruk. Ik heb in de loop der jaren heel wat conversie-programma's getest, en de resultaten daarvan zijn over het algemeen zo bedroevend dat ik moet lachen of huilen, afhankelijk van hoe graag ik wil dat dat programma het doet. Het bestand "Take Control of Your iPad, Second Edition" werd door PDFpen uitzonderlijk goed geconverteerd.

Over het geheel genomen zag het document er "goed" uit. Hierbij moesten tabs en inspring-marges goed ingesteld worden, de juiste lettertypes gebruikt, schermafbeeldingen met de juiste maat ingevoegd, de onderschriften daarvan correct geformatteerd, tabs gebruikt worden in plaats van spaties voor de juiste regelafstand, enzovoort. Natuurlijk was het niet perfect. De omzetting maakte een paar foutjes en minder ideale keuzes, maar geen ervan sprong in het oog. Hier is wat ik gevonden heb:

Als je een conversie van PDF naar Word met PDFpen 6.0 met bescheiden verwachtingen begint, zal het resultaat niet teleurstellend zijn. Als je het omgezette document moet bewerken en opnieuw publiceren, zal je zeker opruimwerk moeten verrichten, maar veel minder dan wanneer je handmatig tekst uit een PDF haalt en dan in Word plakt.

Andere kenmerken -- De meeste van de nieuwe functies in PDFpen 6.0 zijn kleine aanpassingen aan oude functionaliteit of ondersteuning van onderliggende Mac-technieken. De belangrijkste zijn:

Tenslotte: twee nieuwe functies zijn alleen beschikbaar in PDFpenPro, dat zich vooral onderscheidt van zijn kleine broer door de mogelijkheid webpagina's in PDF's om te zetten, het maken van inhoudsopgaven en het maken van PDF-formulieren. Voor hen die veel formulieren maken zal met name de nieuwe detectie-functionaliteit van PDFpenPro 6.0 voor tekstvelden, aanvink-hokjes en radioknopjes interessant zijn. De bijbehorende formulier-elementen worden direct toegevoegd.

De andere nieuwe functie in PDFpenPro 6.0 is het beheer van documentrechten. Als je afdrukken, opslaan en/of bewerken van je PDF wilt beperken, is dat nu mogelijk. Denk alleen niet dat deze PDF-rechten gegarandeerd zijn: er is software in omloop die deze beperkingen kan verwijderen als iemand dit écht wil.

Een laatste opmerking. We kunnen nog geen precieze publicatiedatum noemen, maar Michael Cohen is druk bezig met "Take Control of PDFpen 6", wat een gratis heruitgave zal zijn voor wie "Take Control of PDFpen 5" na 15 oktober 2012 heeft gekocht. Je loopt dus niks mis als je nu al een exemplaar koopt, via ons of via Smile, en alvast alles te weten komt van alle functionaliteit die gelijk blijft in PDFpen 6.0.

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


TidBITS Volglijst: belangrijke software-updates, 25 maart 2013

  van de TidBITS-redactie: [email protected]

[vertaling: DPF]

Skype 6.3 -- Microsoft heeft Skype 6.3 uitgebracht, een onderhoudsversie voor deze app voor internettelefonie, met ook een flink aantal nieuwe mogelijkheden. De app heeft nu een diaweergavemogelijkheid die alle deelnemers aan een gesprek laat zien wanneer jij zelf spreekt in een groepsgesprek (inclusief groepsgesprekken wanneer iemand anders beeld-deelt). Er is nu ook een toetsenbord voor het genereren van DTMF (dual-tone multi-frequency) tonen. Er zijn ook andere verbeteringen, zoals de mogelijkheid om in te loggen in Skype vanuit Call Recorder van Ecamm, en een verbeterd voorkeurenmenu voor de Deense, Italiaanse, Japanse en Koreaanse versies. (Gratis, 37,5 MB, toelichting)

Reacties - Skype 6.3

PopChar X 6.2 -- Ergonis Software heeft PopChar X 6.2 uitgebracht. Deze versie brengt een paar verbeteringen waarmee speciale karakters sneller kunnen worden gevonden. Er is nu namelijk een sneltoets Commando-F, en je kunt ook beginnen met zoeken wanneer de cursor zich in de karaktertabel van PopChar bevindt. Het contextuele menu heeft ook een aantal toevoegingen, zoals een commando "Copy Character Description" waarmee je een korte samenvatting van het geselecteerde Unicode-karakter kunt kopiëren en een commando "Copy Font List" waarmee je de namen van de lettertypen kunt kopiëren. Deze versie ondersteunt ook Unicode 6.2, toont de groep-popupknop nu beter (in het bijzonder voor Retina-schermen), pakt een bug aan waardoor sommige lettertypen nu beter herkend worden in bepaalde apps (zoals Microsoft Word) en biedt een workaround voor het flikkeren van vensters onder OS X 10.8 Mountain Lion. Bovendien kun je nu ook PopChar handmatig starten en het PopChar-venster openen als de app al draait door erop te dubbelklikken in de Finder. Voorheen sloot je dan juist het venster als het al open was. ($ 29,99 nieuwe versie met 25 procent korting voor TidBITS-leden, gratis update, 3,6 MB, toelichting)

Reacties - PopChar X 6.2


ExtraBITS, 25 maart 2013

  van de TidBITS-redactie: [email protected]

[vertaling: DPF]

Eén snelle aanbeveling deze week: een waarschuwing voor Trojaanse paarden gericht op de Mac, die extensies installeren voor het tonen van advertenties in Safari, Chrome en Firefox.

Kijk uit voor Trojaanse paarden met advertenties -- Volgens het Russische veiligheidsbedrijf Doctor Web zijn er steeds meer op de Mac gerichte Trojaanse paarden die extensies installeren voor Safari, Chrome en Firefox. Deze extensies zijn ontworpen om advertenties te plaatsen in webpagina's, waarbij de opbrengsten (na klikken) worden doorgesluisd naar de auteurs van deze software. Er worden verscheidene technieken gebruikt om gebruikers te verleiden om deze programma's te installeren. Ze zijn bijvoorbeeld vermomd als plugins voor video, als mediaspelers, versnellers voor downloaden enzovoort. Vermijd om software te installeren van sites die je daar zelf om vragen. Haal je software altijd van betrouwbare bronnen.

Reacties


Dit is TidBITS, een gratis wekelijkse technologie-nieuwsbrief met recent nieuws, bekwame analyse en grondige besprekingen voor de Apple internet-gemeenschap. Geef het gerust door aan je vrienden; beter nog, vraag of ze een abonnement willen nemen!
Niet-winstgevende en niet-commerciële publicaties en websites mogen artikelen overnemen of een link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We kunnen de precisie van de artikelen niet garanderen. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.
Copyright 2013 TidBITS; reuse governed by this Creative Commons License.

Vorige aflevering | Search TidBITS | Volgende aflevering
TidBITS English | TidBITS Nederlands