Zegt het artikel hierboven nou dat de beveiliging van Office 2016 documenten beter is dan die van passwordmanagers? Dat mag in de krant!

Lijkt me sowieso logisch dat je een sterk wachtwoord moet kiezen als master wachtwoord, maar wanneer je dit als lastig ervaart, dan zou je dat toch ook moeten kunnen ondervangen door naast een wachtwoord een key-file te gebruiken zoals bijv. KeePass dat ondersteund zolang je deze maar niet samen met je keepass bestand op slaat.

Jammer dat niet duidelijk is of KeePass 1 danwel 2 is getest (terwijl Oleg Afonin ze beiden noemt in zijn blog).

In KeePass kun je overigens dictionary attacks zo moeilijk maken als je zelf wilt, met als prijs dat je zelf ook langer moet wachten tot KeePass, na het invoeren van jouw wachtwoord, de database met succes ontsleutelt of een "verkeerd wachtwoord" foutmelding geeft. Zie http://keepass.info/help/base/security.html#secdictprotect.

Overigens moet een aanvaller wel een databasefile in handen krijgen om zo'n brute force aanval uit te kunnen voeren.

De reden dat KeePassDroid de database bewaart in de, voor andere Apps toegankelijke plaats "/storage/emulated/0/keepass/keepass.kdbx", zou kunnen zijn dat de tablet/smartphone eigenaar er dan zelf eenvoudig kopiën van kan maken. Want wachtwoorden kwijtraken is, zeker als er geen "password reset" optie voor bestaat (zoals voor versleutelde ZIP bestanden), is ook heel sneu.

Onder Windows is het overigens ook heel gebruikelijk dat alle bestanden, waaronder KeePass databases, door elke applicatie benaderbaar zijn. En als op jouw PC de Server Service (SRV.SYS) draait en een aanvaller een admin wachtwoord kent, deze bestanden ook via het netwerk en de bekende "hidden shares" als C$, D$ etc. bereikbaar zijn.

Het staat in de nieuwe versie van de krant.. Internet.
Office gebruikt als encryptie aes dat lijkt me veilig genoeg. Het is ook zwaar en log dus ik kan begrijpen dat het brute force proberen niet snel gaat. Elk nadeel heeft zo zijn voordeel.

En hoe staat het met de brute force snelheid van .7z bestanden?
Als men beveiligde RAR5 bestanden noemt, hoort men eigenlijk ook beveiligde .7z bestanden te noemen.

De brute force snelheid hangt af van hoe de software het wachtwoord opslaat.
Dat kan bijv. een hash zijn, maar ook een veelvoud van hashes waarbij een hash nog eens wordt gehasht en nog eens en nog eens etc.

Een veelvoud van hashes verdient de voorkeur, want dit kost bij elkaar meer rekentijd.
En als er meer rekentijd per wachtwoord nodig is, kan je uiteraard minder wachtwoorden per seconde uitproberen,
en dus gaat je "passwords per second" omlaag.
Wel vervelend als je je wachtwoord kwijt bent, want dan kan je het ook met brute force niet meer boven water halen. ;)

Iemand enig idee hoe een beveiligd .7z bestand hier presteert?

Baseline: Zwakke wachtwoorden zijn te kraken, de snelheid waarmee varieert (te kraken) is bij software x groter dan bij software y.

Daarvoor heb je geen Elcomsoft nodig met domme quotes als:

""Zijn wachtwoordmanagers veiliger dan het bijhouden van een lijst met wachtwoorden in een Excel-bestand? Niet per definitie"

Excel is een spreadsheet, na authenticatie is alle informatie beschikbaar tot de spreadsheet of Excel wordt afgesloten.
Een wachtwoord copy pasten: data blijft beschikbaar. tot de volgende copy/paste/cut. Gewoon uitleesbaar uit het geheugen.

Deze hele test is waardeloos, want het enige waar het over gaat is het aantal wachtwoorden dat simultaan kan worden getest, als invoer. Het zegt niet over de cryptografische of programmatische bescherming van het bestand zelf. Een XLS wachtwoord dat was vroeger: open openoffice -> laad xls -> geen wachtwoord

Tegenwoordig heb je de volledige UTF-8 ter beschikking met iets van ongeveer 11000+ codepoints. Laat ons er even vanuit gaan dat het er 11000 zijn. Dat geeft bij een wachtwoord van 10 karakters 11000^10 mogelijkheden:

25937424601000000000000000000000000000000 of 25 duodecillion 937 undecillion 424 decillion 601 nonillion

Of je dan 129000 wachtwoorden per seconde kan kraken of 20000 of 2000, dat maakt niets uit. Zelfs honderd miljoen wachtwoorden per seconde is een druppel in de zee.

Typisch verhaal slappe marketing: als je wachtwoord 123azertyis kunnen wij het sneller kraken en nu ook in password managers :-)

AES is juist NIET zwaar en log, dat was het al niet toen het ontworpen werd en dat is het zeker niet op moderne CPU's die daar speciale instructies voor aan boord hebben.

En dat het zo snel is, is nou PRECIES het probleem.

Ook is AES helemaal niet per definitie veilig. Dat is afhankelijk van de gebruikte mode (ECB, CBC, XTS, CGM etc.), de kwaliteit van de random number generator (en wel/geen backdoors daarin) voor de IV's en, niet te vergeten, de mate van zorgvuldigheid van de implementatie (bugs, side channel leaks etc).

Microsoft staat er nou niet bepaald om bekend sterke encryptie te bieden (bijv. Bitlocker heeft zij op een gegeven moment verzwakt door de Elephant Diffuser eruit te slopen). Op een enkele uitzondering na (de rechtszaken over e-mails op een Microsoft server in Dublin, en dat was vermoedelijk een schijnvertoning) zie je de Amerikaanse geheime diensten nooit over straat rollen met Microsoft - terwijl het overgrote deel van de wereld hun meuk gebruikt. Rara hoe kan dat...

Of denk je serieus dat ze in Redmond extreem gedetailleerde gegevens van 70% van de wereldwijde Windows gebruikers nodig hebben "om het product Windows te verbeteren"?

Lees je eens serieus in op encryptie voor je raaskalt - of droom verder...

Leek op dit gebied, maar wel geïnteresseerd, en ik lees alleen maar dat het aantal (brute-force) pogingen om het wachtwoord te kraken er voor Office 2016 maximaal 7300 pogingen per seconde mogelijk zijn.
Vergeleken bij de anderen, steekt dat er opvallen positief bovenuit.
Hoe is het mogelijk dat de makers van speciaal bedoelde bescherming voor wachtwoorden in hun programma geen vertragende optie hebben aangemaakt, waardoor het aantal pogingen per second minimaal worden.

Echter wat is de tijdlijn dat nodig is voor het kraken van een willekeurig gegenereerd hoofd wachtwoord van zeg maar 8 karakters (a-z A-Z 0-9 and speciale characters). Is dat gebaseerd op de snelste computers die we momenteel kennen, twee weken, of een jaar, of misschien 100 jaar.
Als dat het laatste is, waar maken wij ons dan druk over.

Natuurlijk Quantum computers mogen we niet meerekenen, die zijn er nog niet, en helemaal niet ter beschikking van individuen. De toekomstige encryptie zal zo lees ik zal als tegenmaatregel op de Quantum computer een vertragende functie voor het pogingen moeten implementeren.

Je hebt vrijwel helemaal gelijk, alleen net niet op dit punt dat de snelheid van AES het probleem is.

De traagheid (of niet) van wachtwoord test pogingen wordt bepaald door de gebruikte password afleiding (en parameters ervan), en niet door het encryptie algorithme dat de hash uitkomst verder als sleutel gebruikt .

Er zijn een hoop password hash implementaties zodanig gekozen dat ze zelfs op handige hardware extreem traag zijn .
Hoewel het mogelijk is om binnen de hash AES als werkpaard te gebruiken (elk blockcipher is tot een hash te construeren) wordt meestal iets anders gebruikt.
(zie bv https://en.wikipedia.org/wiki/PBKDF2 ,https://en.wikipedia.org/wiki/Bcrypt - op basis van blowfish , https://en.wikipedia.org/wiki/Scrypt ) .
Ik verwacht niet 'gebruikt AES' van Office slaat op de gebruikte password hash , maar op de bulk encryptie .

Kortom - een snelle encryptie/decryptie kan prima samengaan met een bijzonder trage key-test .

de encryptie methode boeit meestal niet veel met kleine text bestanden zoals password files, wordt pas werkelijk interessant zodra je bestanden van meerdere gb's groot hebt, maar ik snap waar je heen wilt, het hangt van heel veel dingen af.


over het artikel, gewoon met keepass het iteratie niveau omhoog schroeven, probleem opgelost.

Wat ik in ieder geval zeker weet is dat blinde ms hast zeker NIET bijdraagt tot betere informatieveiligheid. Ik zie genoeg ellende in de dagelijkse praktijk door die kortzichtigheid.
Het is het redactieartikel waarin een vergelijk gemaakt wordt tussen passwordmanagers en office wat betreft brute force aanval. Valt nogal nadelig uit voor passwordmanagers.
Bedenk open office heeft niet eens bestandencryptie.

Kijk eens wat beter naar de situate en gebruik de informatie beter. Je raaskalt nu zelf door je ms bashing.

Hee, zie ik daar egoos vliegen?

[met rood hoofd van schaamte] I stand corrected 8-(

Juist omdat AES zo snel is, is het geen voor de hand liggende kandidaat voor een opzettelijk trage KDF (Key Derivation Function), dat is de functie die een wachtwoord omzet naar een afgeleide waarde (zodat niet jouw wachtwoord zelf, maar die afgeleide, in een database hoeft te worden opgeslagen). De reden om een KDF traag te maken is om makers van rainbow tables het leven zuur te maken juist door in zo'n KDF gigantisch veel CPU-cycles te laten verbranden.

Overigens, om precies dezelfde reden (ze zijn te snel) wordt het gebruik van cryptografische hashes als MD5 en SHA-1 als KDF de laatste jaren afgeraden - niet omdat ze "gekraakt" zouden zijn.

De term "gekraakt" is dus deels onjuist voor MD5 en SHA-1. Deze hashes zijn ongeschikt bevonden voor het aantonen dat de input niet door een andere input is vervangen, omdat het aanzienlijk eenvoudiger leek dan aanvankelijk gedacht om 1 of meer andere inputs te vinden die dezelfde MD5 of SHA-1 hashwaarde opleveren. Daarmee zijn deze hashes ongeschikt voor gebruik in digitale handtekeningen (certificaten, bestanden (exe, PDF, XML etc.) en e-mails. Maar hoewel collisions bij wachtwoorden niet kunnen worden uitgesloten, is de kans daarop, zeker bij wachtwoorden korter dan de lengte van de hash, extreem klein - waarmee "gekraakt" dus niet de reden is om ze niet meer als KDFs te gebruiken (recentere hash functies die niet gekraakt maar wel snel zijn, zijn ook ongeschikt voor dit doel).

Anyway ik dwaal af. Mea culpa!

Toegegeven, dat Office2016 EINDELIJK lastig te kraken encryptie zou ondersteunen, is nieuw voor mij (ik moet dat overigens nog zien, en ga er voor de zekerheid maar vanuit dat hier een backdoor in zit en/of het wachtwoord via "Office Telemetry" naar Redmond wordt gestuurd elke keer dat je dit invoert). Maar sowieso ben ik de misleidende (want doodsimpel kraakbare) "encryptie" in eerdere MS Office versies nog niet vergeten.

En ook dat je bij Windows 95, 98 en ME een wachtwoord kon gebruiken bij inloggen. Slechts bedoeld om onwetende gebruikers te laten denken dat dit ongeautoriseerde toegang tot hun bestanden zou voorkomen.

En ook dat je bij alle latere Windows versies een wachtwoord kunt gebruiken bij inloggen. Slechts bedoeld om onwetende gebruikers te laten denken dat dit ongeautoriseerde toegang tot hun bestanden zou voorkomen - wat niet waar is als een aanvaller een admin wachtwoord of exploit kent en via het netwerk (vanwege het bestaan van "hidden shares" - don't tell anyone) daar toch bij kan. Maar ook als een aanvaller fysieke toegang heeft tot de PC en de schijf niet is versleuteld.

En dat laatste is zelfs niet waar als de schijf wel versleuteld is, maar je daar geen wachtwoord of zelfs een pincode op hebt gezet omdat de NSA^h^h^h^h^h^h Microsoft zei dat dit niet nodig was [1].

[1] https://blogs.technet.microsoft.com/askpfeplat/2014/07/13/bitlocker-pin-on-surface-pro-3-and-other-tablets/

De moraal van dit verhaal, als je zorgt dat je "manager" er langer over doet om een nieuwe poging te kunnen ondernemen ben je veiliger?
Tja, beetje rare redenering, een beetje hacker heeft wel geduld.

Maar goed, keypas kun je met keyfile en wachtwoord beveiligen, kan dat met excel ook? Of is dit weer zo'n momentje van gratis reclame voor een booh roeper?

keepass kan je zo instellen dat er maar 1 of 2 wachtwoorden per minuut getest kan worden,hoe omzeilt de kraker dit..

Heel simpel, door niet keepass zelf aan te roepen als men een password wil testen maar de functie direct te implementeren en los te laten op de database, die gewoon een apart bestand is. Keepass is open source dus die code is voor iedereen beschikbaar zonder moeilijke dingen als reverse engineering.

Inderdaad. En dan doet de kraker het testen ook nog met een dikke videokaart om zoveel mogelijk wachtwoorden te kunnen proberen.
En is het dus zaak voor het programma om de wachtwoord bewerking zodanig te kiezen dat *zelfs* met die dikke hardware de snelheid beperkt blijft.

(even lachen : waarom haalt een hacker niet even de vertraging uit de bitcoin mining zodat je meer coins kunt maken en rijk wordt... )

Bij .7z wil je niet eeuwig wachten tot je bestand ontsleuteld is. Daar zal voor een codering gekozen zijn die ook snel gaat.


Hoezo is dat een rare redenering. Dit is dezelfde reden waarom je lange wachtwoorden moet gebruiken. Daarbij duurt het ook langer voordat je alle mogelijkheden geprobeerd hebt. Hoe de wachtwoorden versleuteld worden heb je als gebruiker niet in de hand, daarom zie je dat ook niet in wachtwoord adviezen. Software schrijvers behoren hier wel rekening mee te houden. Bij wachtwoord managers is snelheid van ontsleutelen nooit een issue omdat het maximaal om één wachtwoord-zin gaat. Dus heeft een traag algoritme de voorkeur.

Staat dat niet los van elkaar?
Stel ik heb 100 deuren vlak naast elkaar, en de enige passende sleutel zit in 1 van de miljoen puttten verspreid over het veld waar je even in moet graven om bij de sleutel te komen. (er zit een sleutel in elke put, maar slecht eentje past)

Iemand die weet in welke put de sleutel ligt, heeft de sleutel al snel te pakken,
en kan daarna ook heel vlot al die 100 deuren naast elkaar openmaken.
Maar voor iemand die niet weet in welke put de juiste sleutel ligt kost het heel veel tijd om de hem te vinden.
Gemiddeld moet hij in 500.000 putjes graven, de sleutel pakken, naar de deuren lopen, uitproberen, en teruglopen naar het volgende putje....

In computers gaat dat zogenaamd "putjegraven" veel sneller, en kunnen er bijv. 10 sleutels per seconde worden "opgegraven" en uitgeprobeerd. De computer doet dus maar 0,1s om het wachtwoord te controleren, maar als dit het juiste wachtwoord blijkt, kan de computer daarna als een razende het bestand ontsleutelen.

Nee, dat is onjuist.

Jouw wachtwoord wordt door een (eventueel bewust langzaam gemaakte) KDF gehaald. Het resultaat wordt gebruikt om de werkelijke sleutel (bij AES 128, 192 of 256 bits) te genereren of (als die sleutel zelf versleuteld als een soort "bijlage" bij de versleutelde database is opgeslagen) te decrypten.

Het klopt dat je de database ook kunt decrypten als je op andere wijze achter de sleutel kunt komen, maar dat hoort niet mogelijk te zijn door de source van software te kunnen inzien. Je hebt dus juist KeePass niet zelf nodig om zo'n database te decrypten. Encryptie is alleen maar goed als er niets geheim aan is, behalve het wachtwoord (en de uiteindelijk gebruikte sleutel, maar dat lijkt me evident).

Bijv. Veracrypt gaat nog een stapje verder. Daarbij kun je, naast jouw wachtwoord, een "PIM" waarde opgeven die tot een specifiek aantal iteraties in de KDF leidt. Hoewel ook Veracrypt open source is, zul je als aanvaller toch echt zowel het wachtwoord als de PIM waarde moeten kennen om, op welke wijze dan ook, een met Veracrypt versleuteld bestand of schijf te decrypten (ervan uitgaande dat er geen implementatie- en/of logische fouten in Veracrypt zitten).

Oei, ik vrees dat je hier nog een keer op een verkeerd spoor zit .
(caveat : ik ken keepass niet in detail , maar lees de vraag op dezelfde manier als degene die dit antwoord gaf).

Ik las het antwoord als uitleg dat keepass *naast* een 'trage' KDF ook een software matige vertraging heeft op het invoeren van wachtwoorden . Net zoals de unix/pam modules dat hebben , bijvoorbeeld .

Een softwarematige vertraging op 3 pogingen per minuut helpt niets tegen offline hackers, maar wel tegen collega's (of kinderen, partner) die even achter je openstaande computer kruipen om wat te proberen .
Niet iedereen is slim/goed/geïnteresseerd genoeg om het bestand te nemen, de elcomsoft software te _kopen_ en dan offline te gaan zitten kraken . Een trage KDF is bedoeld tegen offline aanvallers, een software beperking is niet perfect maar wel een nuttige hindernis tegen de matig capable/matig gemotiveerde online 'aanvaller' .

Je kunt een KDF niet worst-case supertraag maken (10 seconden op een dikke videokaart), omdat de functie 'acceptabel snel genoeg' moet zijn op de range aan systemen van normale gebruikers . Oftewel, een KDF moet binnen , zeg, seconde per key blijven op een wat oudere PC (of soms : oudere smartphone)

Op basis van het "3 per minuut" statement denk ik dat dat een softwarematige beperking (sleep 20) betreft , geen KDF met waanzinnig aantal rounds.

Heb je de info, waar ik gisteren 17:03 al naar verwees (http://keepass.info/help/base/security.html#secdictprotect), gelezen?
Het gaat hier echt niet om "pause 1" of iets dergelijks...

Vóór klikken op "1 second delay": https://imgur.com/a/KEQvN
En daarna: https://imgur.com/a/CQgDv

Ok, die had ik niet gelezen , dus ik moet me inderdaad op de caveat beroepen dat ik keepass niet kende.

Ik ging ervan uit dat de vraag van potshot gebaseerd was op een feature dat je letterlijk maar 1 of 2 keer per _minuut_ kunt inloggen.
Nu zou je zo'n tijd ook nog wel uit een KDF kunnen halen, maar voor z'n vertraging verwachtte ik een software optie (if fout sleep (20) )

Deze vertragings optie is inderdaad het tunen van de KDF op de CPU van de gebruiker.

Keypass 2 heeft veel extra beveiligingsmaatregelen
- master wachtwoord
- certificaat
- sleutelbestand
- windows gebruikersaccount karakteristieken
Daarnaast
- bescherming tegen keyloggers
- bescherming tegen brut force
En een ton aan add-ons

Makkelijk in gebruik, maar dat geldt niet voor de inrichting

Al die spookverhalen heb ik van beheerders en marketing mensen zien komen. Echte security is te duur dus mogen wel wat faken naar de vinkenlijstjes van auditors. Aan die houding, daar heb ik een hekel aan. Het staat los van een OS, daarvoor moet je iets veder kijken.
De oasis specficatie ofwel ODT geeft xml-tags voor wachtwoorden aan. Dat zijn ook in het vrijwel identieke ECMA office, er is nauwelijks onderscheid. Dat AES gedoe is specfiek voor het hele bestand, je kunt het dan ook niet meer uzip openen. Google docs etc kunnen er ook niets meer mee.
De fud over ww met telemetry is gewoon fud. Hoe zou je ooit iets later moeten gaan koppelen. Als we fud kunnen gebruiken dan is niets meer zeker ook linux OSS etc niet. Er is atlijd wel ets onbekends.

Ook a gebruik je brute force een office bestand zal veel malen groten zijn dan een kdb van een passwordmanager.. Die omvang is voldoende argument voor een vertraging.

Hier een werkend (in elk geval t/m Excel 2010) spookverhaal uit https://uknowit.uwgb.edu/page.php?id=28850:

Ah, gevonden!
https://security.stackexchange.com/questions/29375/is-7-zips-aes-encryption-just-as-secure-as-truecrypts-version

Hier wordt een vergelijk gemaakt tussen een wachtwoordafgeleide met Truecrypt, en een wachtwoordafgeleide met 7-zip. Truecrypt gebruikt de PBKDF2-functie als wachtwoordafgeleide functie.
7-zip daarentegen gebruikt salted SHA256 hashes, en je kan zelf instellen hoe vaak. (aantal iteraties) zegt iemand.
Er wordt ook aangegeven dat 7-zip tot wel 524.288 iteraties kan doen van een SHA256 hash op het wachtwoord,
maar dat Truecrypt het doet met slechts 1000 of 2000 iteraties in PBKDF2, afhankelijk van de daarin gebruikte hashfunctie.

Interessant... Het wachtwoord van Truecrypt is sneller te kraken dan het ...w...a...c...h...t...w...o...o...r...d... van 7-zip?

(dit gaat dus niet over de snelheid van het decoderen van het bestand, maar over de snelheid van de wachtwoordcontrole!)

Ah, ik zag daarnet nog dat de PBKDF2 iteration count van veracrypt stukken beter is dan truecrypt.

Zowel OOXML en ODF zijn doodgewone ZIP-bestanden met daarin een directory-structuur, XML-bestanden voor metadata en inhoud, en ingevoegde bestanden zoals afbeeldingen.

MS Office gebruikt een OLE compound document (iets dat qua structuur lijkt op een FAT-filesysteem) als container om het integrale ZIP-bestand versleuteld in op te slaan, alsmede de parameters van de gebruikte encryptie.

Bij ODF heeft men het ZIP-bestand zelf als container gebruikt. In plaats van de integrale inhoud worden alle afzonderlijke bestanden versleuteld, met uitzondering van een manifest-file waarin per versleuteld bestand de checksum, initialisatievector, de kenmerken van het hash- algoritme waarmee de sleutel uit het wachtwoord is afgeleid en de SALT zijn opgeslagen.

Je zegt dat open office "niet eens" bestandenencryptie heeft, maar dat is er dus wel. Niet het hele ZIP-bestand, maar wel alle daarin opgeslagen bestanden. Is daar iets mis mee?

Persoonlijk vind ik het wel zo snugger om te onderkennen dat een ZIP-bestand al een containerformaat is en dat er geen andere container meer omheen geplaatst hoeft te worden, laat staan in een ander formaat. De oplossing van Microsoft komt nogal rommelig over in vergelijking, alsof ze bij het opstellen van de standaard in alle haast even vergeten waren dat dat er ook nog iets voor encryptie geregeld moest worden en dat quick&dirty hebben toegevoegd. Of misschien is het binnen Windows logisch om OLE compound documents te gebruiken, maar dan sloegen ze even over dat een open formaat ook op andere platforms terecht komt, wat op mij al even slordig overkomt.

Ze zijn echt niet zo stom geweest om wachtwoorden bij de versleutelde inhoud te voegen. In de manifest-file staan dan ook geen XML-tags voor wachtwoorden. Hiervoor somde ik al op wat er wel in de manifest-file staat. Die gegevens zullen ook in het OLE compound document moeten staan, al zullen het daar het geen XML-tags zijn.

Waarom zou de omvang een argument zijn voor een vertraging? Het argument voor een vertraging is dat dat het bruteforcen van het wachtwoord bemoeilijkt.

Als je bedoelt dat een groter bestand meer vertraging oplevert sla je de plank mis. OOXML slaat de volledige ZIP-file op in het OLE compound document, en de eerste twee bytes van elke ZIP-file, ook die van ODF- en OOXML-documenten, bevatten de letters 'PK'. Een aanvaller hoeft alleen het eerste blok van het bestand te ontsleutelen om te zien of het wachtwoord klopt, ongeacht hoe groot het bestand verder is.

De vertraging zit niet in de omvang van het versleutelde bestand maar in hoeveel rekenkracht het vergt om een wachtwoord om te zetten in een sleutel.

Spreek anderen alsjeblieft niet op het verspreiden van FUD aan als je eigen weergave van de werkelijkheid stijf staat van de onjuistheden.

Met fud op open source is betrouwbaar omdat iedereen de code kan zien moet je de zaak wel nakijken.
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416138_2538929
13.5.4<form:password>
The <form:password> element defines a control that hides text a user inputs using an echo character.
In de praktijk tegen aan gelopen door gewoon te kijken hoe het zit.... Hacking? Nee problemen zien op te lossen.
Gewoon even in het manifest kijken. Je bewering is busted.

Als een office bestand met een password manager bekijkt is er een groot verschil in omvang. We hebben het niet over een vergelijk met open office. Enkel beschermen met wachtwoorden. Gaarne on topic blijven.

De discussie ging over het versleutelen van documenten. Dit is een UI-element dat je in formulieren op kan nemen die onderdeel zijn van het document. Dat heeft niets, maar dan ook niets te maken met die versleuteling. Omdat die versleuteling het onderwerp was kwam ik niet op het idee dat je er zaken bij ging halen die er geen relatie mee hebben.

Wat moet ik hiervan denken? Dat je werkelijk zo slecht snapt waar je het over hebt dat je dit niet door had of moet ik denken dat je het wel snapt en bewust met misleidende argumenten strooit? Is dit onkunde of FUD, karma? Of had je een paar glaasjes teveel op, misschien?

Ik had nagekeken wat ik opschreef, trouwens.

Nog een puntje: de webpagina waar je aan refereert bevat niet de broncode van OpenOffice of LibreOffice, die bevat een specificatie van het documentformaat. Dat is geen open source maar een open standaard, en je keek niet naar de code maar naar de specificatie van die standaard.

Ik was on topic. De omvang van de versleutelde data doet er niet toe als de aanvaller aan het eerste blok al kan zien of het ontsleuteling geslaagd is. Volgens de documentatie van Microsoft is een versleuteld office-bestand een OLE compound file met daarin, naast metadata over de encryptie, "an encrypted stream of bytes containing the entire ECMA-376 source file [ECMA-376] in compressed form". Dat is het Office-document, waarvan de gecomprimeerde vorm een ZIP-bestand is. Volgens mij staat daar dat het integrale ZIP-bestand is opgeslagen in de OLE compound file (als dat niet zo is verzuimen ze namelijk om te vermelden wat ze dan wel doen). Een ZIP-bestand begint altijd met 'PK' in de eerste twee bytes, en dat kan de aanvaller al verifiëren als hij één blok ontsleuteld heeft. De omvang doet er dan niet toe.

https://msdn.microsoft.com/en-us/library/cc313071.aspx
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

http://www.spreadsheet1.com/sheet-protection-2013.html laat weten dat er verschil is tussen een eeuwigdurende Office 2016 licentie, en een Office 2016 in een Office365-subscriptie. Dit is op te maken uit deze regel:
Alleen voor een Office-versie uit een Office365-abonnement zou er een betere wachtwoordprotectie bestaan met salt en 100.000 SHA512 hashes.

De vraag is nu voor welke Office 2016 die 7300 wachtwoorden per seconde geldt. (die je ziet staan in de tabel van het security.nl-artikel bovenaan). Geldt het voor een Office 2016 die je koopt "as is" met de oude wachtwoordprotectie?
Of voor de Office 2016 die bij een Office 365 abonnement hoort, en die is geüpgrade naar betere wachtwoordprotectie?

Kennelijk niet. Het artikel heeft het enkel over een vergelijk tussen opslaan in een passwordfile en opslaan in office.
Met dat vergelijk houd ik me aan die voorwaarden.

We hebben het enkel over een office encrypted bestand. ODT libre office ondersteunt dat niet en is daarmee off-topic.

Extra toevoegingen mag het zou anders te beperkend worden in verbeteringen en vasthouden aan fouten.
https://msdn.microsoft.com/en-us/library/dd907883(v=office.12).aspx Even kjken of ik een PK aanduiding zie .... Ja je hebt gelijk, daarmee heb je na het er doorheen halen 1 snelle controle of je een werkbaar iets hebt.

Hmm besef je dat je een algemene kwetsbaarheid voor AES benoemd. https://nl.wikipedia.org/wiki/Rijndael_(cryptografie) als je het met de zelfde sleutel op de eerste 32 bytes als blok snel een resultaat kan halen omdat die eerste 32 bytes niet zo random zijn, tja wat dan? .

Een "Known plaintext attack" is in theorie mogelijk bij alle encryptiemethodes (behalve bij zeer korte plaintext en OTP) dus dat is off topic.

In de benchmark hebben ze MS Office meegenomen en daar de documentversleuteling van Office 2016 in meegenomen ter vergelijking. Jij bent zelf degene die dat met OpenOffice/LibreOffice/ODT/Oasis begon te vergelijken, dus kom niet aanzetten met dat ik me niet bij het onderwerp houd door daarop te reageren; als dat een argument is had je er zelf niet over moeten beginnen. En mijn reactie sneed hout: de tag die je noemde heeft niets met documentencryptie te maken en zegt er dus ook niets over.

Ik herhaal: je begon zelf over ODT. En je reageert niet op wat ik schreef, namelijk dat je de termen "open source" en "code" gebruikte voor een open standaard en de specificatie daarvan. Het verschil doet er toe.

De manier waarop je reageert wekt de indruk dat je er zo slecht tegen kan niet de autoriteit te zijn die altijd gelijk heeft dat je koste wat het kost met kulargumenten gaat strooien om jezelf maar wijs te blijven maken dat je het beter weet. Best zielig, eigenlijk.

Nee hoor, ik noem geen algemene kwetsbaarheid van AES en het eerste blok is echt niet van random te onderscheiden in versleutelde vorm. Het punt is dat AES een blokvercijferingsalgoritme is en daarmee alleen maar gaat over het versleutelen en ontsleutelen van die kleine blokken data. Opschalen naar grotere hoeveelheden data gaat zo:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
En bij al die methoden om versleuteling van meerdere blokken te doen geldt dat als je begint te ontsleutelen één blok het eerste is. En als daar iets voorspelbaars in staat dan weet een brute force-aanvaller snel of een sleutel zoals die in de blokvercijfering wordt gebruikt goed is of niet. De verdediging daartegen is het traag maken van het afleiden van die sleutel uit een wachtwoord, zoals anderen al hebben uitgelegd, en dat is precies het punt waarvan geconstateerd is dat wachtwoordbeheerprogramma's te wensen overlaten.

Wat betreft Keepass is het maar de vraag hoe je Keepass instelt. Leuke marketing, de praktijk is anders. https://www.linkedin.com/pulse/dear-keepass-user-you-safe-ton-snoei

Huh? Libre office ondersteunt gewoon passwords op bestanden hoor.
https://listarchives.libreoffice.org/global/users/msg18342.html
Een encrypted Libreoffice-bestand is encrypted met AES-256-CBC, na 1000 maal SHA256 hashes van het password.
(als het onlangs niet is veranderd)
Het kan zijn dat daarbij (nog steeds) PBKDF2 wordt gebruikt.

Duizendmaal SHA256 van het password is tegenwoordig niet heel veel vertraging voor brute force, maar dat kan je opvangen door een langer wachtwoord. (bijv. 4 karakters langer)

Dank je voor de link. Goede toevoeging je hebt daar gelijk in.
Het toont tevens de incompatibiliteit met oudere versies. Die toevoeging vond ik niet in het Oasis manifest. Die zou dan aangepast moeten worden of er moet acceptatie zijn dat het niet aan die standaard voldoet.

Nee, Neb is het niet. En verder bevestig je het beeld dat ik inmiddels van je heb alleen maar. Je doet me denken aan die ridder uit Monty Python and the Holy Grail die maar bleef volhouden dat hij aan de winnende hand was terwijl al zijn ledematen werden afgehakt.

Bij de 1Password test is de oude versie van de database gebruikt. Elcomsoft heeft inmiddels de excuses aangeboden aan Agilebits en ook het rapport aangepast. https://blog.elcomsoft.com/2017/08/attacking-the-1password-master-password-follow-up/
Er is nu sprake van de volgende waarneming (Citaat):
"We bring our apologies to AgileBits, the developers of 1Password, for letting the wrong number creep in to our benchmark. Can we still break into 1Password by attacking the master password? Please bear with us for up-to-date information and detailed technical discussion."

"Long story short, we re-run the benchmark using the latest 1Password 6.8. Now it uses PBKDF2-HMAC-SHA512; iOS version database (extracted from iTunes backup) has 100,000 rounds, while DropBox-synced file opted for 60,000 rounds on our test iPhone 6S (hard to say how much iterations you will get, for example, when syncing older/slower iPhone models, but you can check that yourself, that’s pretty easy).

With these parameters, we came up with 3200 and 6000 passwords per seconds respectively using the same NVIDIA GeForce GTX 1080 board. Much, much better (for customers, I mean)."