Security Professionals
- ipfw add deny all from eindgebruikers to any
7ZIP, welke wachtwoord lengte?
Vorige week noemde ik 7ZIP als mogelijkheid vertrouwelijke informatie uit te wisselen met bijvoorbeeld een notaris. Voor de zekerheid heb ik van de 3-poot algoritme, sleutel en implementatie naar de implementatie van het sleutel afleidingsmechanisme gekeken.
Voorlopige conclusie:
- neem een lang wachtwoord van minimaal 12 willekeurige tekens (letters cijfers) zoals 4y4530g9jblf
- of gebruik voor gemakkelijk uitwisselen een wachtzin van minimaal 5 willekeurige woorden zoals RingRaakteDumpCryptoOpa
De lengte is natuurlijk afhankelijk van de gewenste bescherming. Deze lengtes geven vele decennia bescherming tegen smart brute force aanvallen. Uitgangspunt een kraaksysteem met 8xGPU en AES 256 mode van 7ZIP.
Reden voor voorlopige resultaten is mijn vraag: Heeft iemand al eens naar de source van 7ZIP gekeken op dit punt?
Het blijkt dat de afleidingen van de ZIP, 7Z en RAR formaten verschillen, zie XXXaes.cp en .h files (xxx=7Z,Wz en Rar).
7z formaat gebruikt een 'eigen' afleiding door 524288 sha256 op de al dan niet gezouten sleutel los te laten. ZIP gebruikt PBKDF2 SHA1 met 2000 iteraties en zout. RAR heb ik niet bekeken. Het verschil zal vermoedelijk met uitwisseling tussen 7ZIP en andere zippers te maken hebben.
Op Internet staan verschillende berichten over 7ZIP en het gebruik van zout. Zeker is dat de huidige versie bij het ZIP formaat wel zout gebruikt, zelfs verschillende salts per file in een archief.
Voorlopige conclusie:
- neem een lang wachtwoord van minimaal 12 willekeurige tekens (letters cijfers) zoals 4y4530g9jblf
- of gebruik voor gemakkelijk uitwisselen een wachtzin van minimaal 5 willekeurige woorden zoals RingRaakteDumpCryptoOpa
De lengte is natuurlijk afhankelijk van de gewenste bescherming. Deze lengtes geven vele decennia bescherming tegen smart brute force aanvallen. Uitgangspunt een kraaksysteem met 8xGPU en AES 256 mode van 7ZIP.
Reden voor voorlopige resultaten is mijn vraag: Heeft iemand al eens naar de source van 7ZIP gekeken op dit punt?
Het blijkt dat de afleidingen van de ZIP, 7Z en RAR formaten verschillen, zie XXXaes.cp en .h files (xxx=7Z,Wz en Rar).
7z formaat gebruikt een 'eigen' afleiding door 524288 sha256 op de al dan niet gezouten sleutel los te laten. ZIP gebruikt PBKDF2 SHA1 met 2000 iteraties en zout. RAR heb ik niet bekeken. Het verschil zal vermoedelijk met uitwisseling tussen 7ZIP en andere zippers te maken hebben.
Op Internet staan verschillende berichten over 7ZIP en het gebruik van zout. Zeker is dat de huidige versie bij het ZIP formaat wel zout gebruikt, zelfs verschillende salts per file in een archief.
Reacties (15)
Even los van het technische verhaal kan ik eerlijk gezegd geen reden bedenken waarom je geen wachtzin zou gebruiken. Langere wachtwoorden zijn in beginsel veiliger en het is makkelijker te onthouden en uit te wisselen. Dan gooi je er nog wat willekeurigs doorheen om dictionary attacks te ontwijken en klaar.
Zelfs beschouw ik 16 tekens als minimale veiligheidsgrens vanwege de brute force snelheden van programmatjes en simpelweg omdat outlook en android een wachtwoord van 16 tekens of minder aan mij proberen op te dringen. Meestal doe ik 10 tekens daar bovenop als marge. danisjewachtwoord9@Terveilig
Zelfs beschouw ik 16 tekens als minimale veiligheidsgrens vanwege de brute force snelheden van programmatjes en simpelweg omdat outlook en android een wachtwoord van 16 tekens of minder aan mij proberen op te dringen. Meestal doe ik 10 tekens daar bovenop als marge. danisjewachtwoord9@Terveilig
Door Anoniem: Even los van het technische verhaal kan ik eerlijk gezegd geen reden bedenken waarom je geen wachtzin zou gebruiken. Langere wachtwoorden zijn in beginsel veiliger en het is makkelijker te onthouden en uit te wisselen. Dan gooi je er nog wat willekeurigs doorheen om dictionary attacks te ontwijken en klaar.
Zelfs beschouw ik 16 tekens als minimale veiligheidsgrens vanwege de brute force snelheden van programmatjes en simpelweg omdat outlook en android een wachtwoord van 16 tekens of minder aan mij proberen op te dringen. Meestal doe ik 10 tekens daar bovenop als marge. danisjewachtwoord9@Terveilig
Op de Nationale Verander Je Wachtwoorden Dag ( https://wachtwoordbewust.nl/ ) toch nog even een zijspoor. In de tabel net boven https://en.wikipedia.org/wiki/Password_strength#Human-generated_passwords kan je zien dat langere wachtwoorden niet altijd veiliger zijn. Maar het is een goede duimregel. En wel is het zo dat langere wachtwoorden binnen een gelijke klasse (klassen als woorden, alleen cijfers, letters en cijfers etc) veiliger zijn.Zelfs beschouw ik 16 tekens als minimale veiligheidsgrens vanwege de brute force snelheden van programmatjes en simpelweg omdat outlook en android een wachtwoord van 16 tekens of minder aan mij proberen op te dringen. Meestal doe ik 10 tekens daar bovenop als marge. danisjewachtwoord9@Terveilig
=== toegevoegd
Als voorbeelden de volgende oplopende lengtes en sterktes in bits
03aV4*d#9o4@ (lengte 12, 79 bits)
GP3MC7MK87GN1 (lengte 13, 67 bits)
VolgdePeesJoelde (lengte 16, 38 bits als passphrase)
Ik mis een aantal aandachtspunten:
- Support voor 7zips AES-256 encryptie is stukken slechter dan het klassiek AES-128; misschien heeft je notaris alleen WinZip of ingebouwde Windows ZIP en geen -zip ? En AES-256 ipv AES-128 voegt in deze context weinig toe.
- We hebben het over AES-128 (of AES-256) in CBC mode; data integriteit is dus niet gewaarborgd; AES-GCM/CCM (AEAD; dus authenticatie + integriteit) zou veel veiliger (en sneller !) zijn
- Vertrouwelijkheid: ZIP is een container; de inhoud van alle bestanden is versleuteld; maar de bestandsnamen zijn niet versleuteld; dat kan tot informatie-lekken leiden / privacy schenden. RAR met wachtwoordbescherming laat je dit instellen/kiezen (maar ik weet dat RAR geen optie is; betaald + minder gangbaar)
- Wachtwoord van 12 karakters lijkt me een redelijk minimum, maar zou toch eerder voor minimaal 16 karakters gaan; juist omdat de entropy van het gekozen wachtwoord vaak overschat wordt (lang verhaal, zie ook Wiki pagina)
- Support voor 7zips AES-256 encryptie is stukken slechter dan het klassiek AES-128; misschien heeft je notaris alleen WinZip of ingebouwde Windows ZIP en geen -zip ? En AES-256 ipv AES-128 voegt in deze context weinig toe.
- We hebben het over AES-128 (of AES-256) in CBC mode; data integriteit is dus niet gewaarborgd; AES-GCM/CCM (AEAD; dus authenticatie + integriteit) zou veel veiliger (en sneller !) zijn
- Vertrouwelijkheid: ZIP is een container; de inhoud van alle bestanden is versleuteld; maar de bestandsnamen zijn niet versleuteld; dat kan tot informatie-lekken leiden / privacy schenden. RAR met wachtwoordbescherming laat je dit instellen/kiezen (maar ik weet dat RAR geen optie is; betaald + minder gangbaar)
- Wachtwoord van 12 karakters lijkt me een redelijk minimum, maar zou toch eerder voor minimaal 16 karakters gaan; juist omdat de entropy van het gekozen wachtwoord vaak overschat wordt (lang verhaal, zie ook Wiki pagina)
Bedoel je de entropy gerelateerde opmerkingen in de encryption section op de pagina over het 7z formaat? https://en.wikipedia.org/wiki/7z#Encryption
Het ging mij overigens ook om de 7Z software, welke 3 formaten ondersteunt, elke met een andere sleutel afleidingsfunctie.
Het ging mij overigens ook om de 7Z software, welke 3 formaten ondersteunt, elke met een andere sleutel afleidingsfunctie.
Door Dick99999: Bedoel je de entropy gerelateerde opmerkingen in de encryption section op de pagina over het 7z formaat? https://en.wikipedia.org/wiki/7z#Encryption
Het ging mij overigens ook om de 7Z software, welke 3 formaten ondersteunt, elke met een andere sleutel afleidingsfunctie.
Het ging mij overigens ook om de 7Z software, welke 3 formaten ondersteunt, elke met een andere sleutel afleidingsfunctie.
Ik ben niet anoniem 26-11 , maar het is duidelijk dat de opmerking over entropie niet slaat op de technische implementatie, maar op het overschatten door mensen van hoe ver een password buiten de range van dictionary zoektochten ligt.
Dat is feitelijk de 'entropie' van een password, hoeveel werkelijke 'informatie' erin zit . Kies je een woord uit een woordenboek is dat hooguit 15-17 bits aan informatie - (30.000 - 100.000 woorden ). De gebruikelijke variaties (hoofdletters, cijfers) voegen in 'entropie' minder toe dan je zou hopen, omdat de meeste mensen dat op een manier doen die de password kraak programma's ook proberen.
De *boven* grens aan entropie voor een password/passphrase ( som [ <beschikbare karakterset> ^ mogelijke lengtes ] ) wordt vrijwel nooit gehaald.
Wat de afleidingsmethoden doen is de zoektocht met een constante factor per poging vertragen.
Om van dit soort moeilijk gedoe af te zijn is nu juist public key cryptografie uitgevonden. Dan hoef je je hierom niet meer druk te maken.
Verder is het van belang wat je threat model is. Wie wil die informatie bemachtigen? Is het de maffia, dan slaan ze jou of die notaris net zo lang op je gezicht totdat je je wachtwoord geeft. Daar helpt geen enkele encryptie tegen. Is het de overheid, dan hebben die weer andere middelen om je af te persen. Een andere partij komt waarschijnlijk niet eens bij de informatie. Een kort wchtwoord is waarschijnlijk niet de zwakste schakel.
Verder is het van belang wat je threat model is. Wie wil die informatie bemachtigen? Is het de maffia, dan slaan ze jou of die notaris net zo lang op je gezicht totdat je je wachtwoord geeft. Daar helpt geen enkele encryptie tegen. Is het de overheid, dan hebben die weer andere middelen om je af te persen. Een andere partij komt waarschijnlijk niet eens bij de informatie. Een kort wchtwoord is waarschijnlijk niet de zwakste schakel.
Door johanw: Om van dit soort moeilijk gedoe af te zijn is nu juist public key cryptografie uitgevonden. Dan hoef je je hierom niet meer druk te maken.
Voor transport van data is public key inderdaad veiliger dan wanneer dat afhankelijk is van een matig gekozen wachtwoord.
Qua security heb je dan de noodzaak om redelijk zeker te zijn dat je het encrypt aan de werkelijke key van de ontvanger - waarvoor de techniek wel beschikbaar is (keysigning, of in persoon key signatures verifieren) maar het leren gebruiken door normale mensen niet hard opschiet.
En het tweede aspect , "software die gewoon 'bekend' is op een _notariskantoor_ " , dan valt inderdaad alles behalve een zip varient eigenlijk wel af.
Iets wat heel behoorlijk is _gebruiken_ wint het tenslotte van praten over een perfecte oplossing maar die niet gebruiken.
Verder is het van belang wat je threat model is. Wie wil die informatie bemachtigen? Is het de maffia, dan slaan ze jou of die notaris net zo lang op je gezicht totdat je je wachtwoord geeft. Daar helpt geen enkele encryptie tegen. Is het de overheid, dan hebben die weer andere middelen om je af te persen. Een andere partij komt waarschijnlijk niet eens bij de informatie. Een kort wchtwoord is waarschijnlijk niet de zwakste schakel.
En ook dat is een heel terecht punt. Voor de meeste threat models , zeker in de context "correspondentie met notaris" lijkt het transport pad me uberhaupt een laag risico - het lijkt me niet het soort correspondentie wat vaak gedaan wordt op momenten en plaatsen waar je via een erg untrusted netwerk werkt.
Heb je een overheidsdienst of erg geavanceerde partij als tegenstander zodanig dat je je normale vaste netwerk ook als onbetrouwbaar moet beschouwen, dan valt te betwijfelen of je eigen systemen, en zeker die van een normale notaris daartegen bestand zijn.
30-11-2015, 09:27 door
Dick99999
Door johanw: Om van dit soort moeilijk gedoe af te zijn is nu juist public key cryptografie uitgevonden. Dan hoef je je hierom niet meer druk te maken.
Als ik de post Contact met de rechtbank en lokale gemeente https://www.security.nl/posting/451083 lees, kom ik tot de conclusie dat praktisch gezien een symmetrische oplossing veel bruikbaarder is in dit soort gevallen.Verder is het van belang wat je threat model is. Wie wil die informatie bemachtigen? Is het de maffia, dan slaan ze jou of die notaris net zo lang op je gezicht totdat je je wachtwoord geeft. Daar helpt geen enkele encryptie tegen. Is het de overheid, dan hebben die weer andere middelen om je af te persen. Een andere partij komt waarschijnlijk niet eens bij de informatie. Een kort wachtwoord is waarschijnlijk niet de zwakste schakel.
Als ik me niet tegen de overheid en maffia wil beschermen, is een kort wachtwoord dan toch niet de zwakste schakel? Email bijlagen en pakketten via speciale file transfer/share services blijven vaak een onbepaalde tijd op servers staan. Andere partijen, ook insiders kunnen bij die informatie komen. Een zwak wachtwoord helpt je niet die informatie te beschermen.Door Dick99999:
Verder is het van belang wat je threat model is. Wie wil die informatie bemachtigen? Is het de maffia, dan slaan ze jou of die notaris net zo lang op je gezicht totdat je je wachtwoord geeft. Daar helpt geen enkele encryptie tegen. Is het de overheid, dan hebben die weer andere middelen om je af te persen. Een andere partij komt waarschijnlijk niet eens bij de informatie. Een kort wachtwoord is waarschijnlijk niet de zwakste schakel.
Als ik me niet tegen de overheid en maffia wil beschermen, is een kort wachtwoord dan toch niet de zwakste schakel? Email bijlagen en pakketten via speciale file transfer/share services blijven vaak een onbepaalde tijd op servers staan. Andere partijen, ook insiders kunnen bij die informatie komen. Een zwak wachtwoord helpt je niet die informatie te beschermen.Als de gecrypte data toegankelijk blijft (zoals bij een file transfer service) is de sterkte van het password inderdaad van belang.
Voor een insider attack bij de ontvangende partij ga je bijna zeker toch nat : De kans is bijna 100% dat de inmiddels gedecrypte bestanden daar binnen de IT systemen gewoon in werkmappen gezet zijn.
Het zijn heel zeldzame omstandigheden waarin de bestanden intern dan alleen verder verwerkt worden op een IT eiland/cel die nog verder afgeschermd is van de generieke infrastructuur .
Als een notaris digitale dingen wil doen, misschien moet die notaris dan eens leren hoe dat digitaal moet.
Thunderbird met enigmail installeren en PGP gebruiken.
Dat is wel veilig.
Thunderbird met enigmail installeren en PGP gebruiken.
Dat is wel veilig.
03-12-2015, 00:35 door
iSeeSharpAndJava
Door Anoniem:
Dat is wel veilig.
Dat is wel veilig.
In deze context, computers, netwerk, veiligheid en cryptografie,
Zullen altijd wel mazen, lekken of exploits gevonden worden.
Zo niet, dan stijgt de rekenkracht 2x per 2 jaar. (Verdubbelt om het jaar), dat is dus expotentioneel. Dus, niks is veilig.
"Alles is relatief" - Albert Einstein.
De veiligheid is ook relatief.
Maar wel goede tip van je.
03-12-2015, 09:38 door
Dick99999
Door Anoniem: Als een notaris digitale dingen wil doen, misschien moet die notaris dan eens leren hoe dat digitaal moet.
Thunderbird met enigmail installeren en PGP gebruiken.
Dat is wel veilig.
Wel veilig, Dus het andere is dan niet veilig? Waarom?Thunderbird met enigmail installeren en PGP gebruiken.
Dat is wel veilig.
Door Dick99999:
Niks is veilig als je computer onbeheerd zonder wachtwoord toegangkelijk is, of je NAS waar een backup op staat, of je gebruikt Windows OS met een virus, of.....Door Anoniem: Als een notaris digitale dingen wil doen, misschien moet die notaris dan eens leren hoe dat digitaal moet.
Thunderbird met enigmail installeren en PGP gebruiken.
Dat is wel veilig.
Wel veilig, Dus het andere is dan niet veilig? Waarom?Thunderbird met enigmail installeren en PGP gebruiken.
Dat is wel veilig.
Met PGP maak je gebruik van een private en public key (dat is ook hoe ransomware werkt).
Je versleutelt je bestand/e-mail met de public key en het bestand/e-mail kan alleen met de private key ontsleutelt worden.
De private key heeft een wachtwoord wat alleen jij weet in je hoofd.
De public key kan iedereen verkrijgen zonder ook maar een wachtwoord.
Voordeel is dat je geen wachtwoord deelt met de andere partij. Want als je wachtwoord deelt via e-mail/telefoon/whatsapp of enige andere vorm, kan iemand die dus inpikken en je data ontsleuten.
De notaris heeft dus een PGP public & private key gemaakt voor zichzelf.
De public sleutel heeft hij op internet gezet via één of meerdere keyrings (bijvoorbeeld keys.gnupg.net)
Jij download de public sleutel en gebruikt die om e-mails aan de notaris te versleuten.
Alleen hij kan dan je e-mail lezen.
10-12-2015, 23:56 door
Erik van Straten
10-12-2015, 21:37 door Anoniem: De notaris heeft dus een PGP public & private key gemaakt voor zichzelf.
De public sleutel heeft hij op internet gezet via één of meerdere keyrings (bijvoorbeeld keys.gnupg.net)
Jij download de public sleutel en gebruikt die om e-mails aan de notaris te versleuten.
Alleen hij kan dan je e-mail lezen.
Hoe weet je zeker dat de public key die jij downloadt vanaf bijvoorbeeld keys.gnupg.net van jouw notaris is?De public sleutel heeft hij op internet gezet via één of meerdere keyrings (bijvoorbeeld keys.gnupg.net)
Jij download de public sleutel en gebruikt die om e-mails aan de notaris te versleuten.
Alleen hij kan dan je e-mail lezen.
In elk geval van Jürgen Schmidt (redacteur van c't) zijn valse public keys gepubliceerd (zie mijn bijdrage van 15-11-2015, 11:59 onder https://www.security.nl/posting/451083/Contact+met+de+rechtbank+en+lokale+gemeente+plain+text).
Naast dat je met zo'n valse sleutel vertrouwelijke info kunt versleutelen die, als die in handen van de bedrieger valt, door die bedrieger kan worden ontsleuteld, kan de bedrieger jou ook bijv. mail sturen die digitaal is ondertekend - schijnbaar door Jürgen Schmidt.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
