Microsoft verbiedt lange wachtwoorden
Gebruikers van Outlook.com stonden vorige week vreemd te kijken toen ze de melding te zien kregen dat hun wachtwoord niet langer dan 16 karakters mag zijn, maar dit was ook altijd al het geval bij Windows Live. Gebruikers van wie het wachtwoord langer dan 16 karakters is moeten de eerste 16 invoeren. Volgens Microsoft betekent dit niet dat wachtwoorden verkort zijn.
"Windows Live ID wachtwoorden waren altijd beperkt tot 16 karakters, alle aanvullende karakters werden tijdens het inloggen genegeerd." Bij het wijzigen van Windows Live ID naar "Microsoft account", heeft Microsoft ook de inlogpagina gewijzigd zodat gebruikers weten dat alleen de eerste zestien karakters van het wachtwoord nodig zijn.
Lengte
"Om deze melding in de toekomst te voorkomen, hoef je alleen de eerste zestien karakters van je wachtwoord in te voeren." Waarom Microsoft niet meer karakters accepteert laat het niet weten.
Yahoo vraagt maximaal 32 karakters, terwijl Google tot 200 karakters gaat, zo ontdekte Graham Cluley van Sophos.
Met dank aan Martijn voor de tip
Reacties (22)
06-08-2012, 17:43 door
Martijn2
Het zou natuurlijk netjes zijn als een wachtwoord minimaal 32 karakters lang zou kunnen zijn, maar is dit echt noodzakelijk? Een online account kan niet zo 1-2-3 worden gekraakt mbv een bruteforce (max 5 pogingen per gegeven tijd is het meestal?).
Het is merkwaardig dat Microsoft jarenlang een deel van je wachtwoord negeert zonder dit te vermelden. De kans dat hier in een online situatie misbruik van gemaakt kan worden is natuurlijk niet zo heel groot, maar databases met inloggegevens hebben de laatste tijd nog wel eens de neiging om op straat te belanden.
Wat natuurlijk ook wel gek is, is dat Microsoft een nieuw "Microsoft account" introduceert en daar de beperkingen van de oude situatie in laat zitten. En waarom de lengte van het wachtwoord beperken als deze uiteindelijk toch in een hash beland?
Wat natuurlijk ook wel gek is, is dat Microsoft een nieuw "Microsoft account" introduceert en daar de beperkingen van de oude situatie in laat zitten. En waarom de lengte van het wachtwoord beperken als deze uiteindelijk toch in een hash beland?
Online accounts worden zo vaak met brute force te pakken genomen. En zo zijn er nog wel meer truukjes om wachtwoorden te pakken te krijgen, het gebeurt dagelijks. En als iemand een wachtwoord van 120 karakters wil, dan moet dat kunnen. Is in ieder geval een stuk veiliger dan abcd1234.
Ter info dit was altijd al alleen liet hotmail voorloper outlook.com inlog via de browser toe door enkel de eerte 16 karakters te rekenen. Het
Enige verschil is nu dat je als gebruiker geinformeerd er over wordt dus al had je jaten terug zelf 50 cijfers ingetikt de eerste
16 werden geteld. Ook de reden dat veel mensen problemen gehad meh pop accounts in mail toevoegen.
Enige verschil is nu dat je als gebruiker geinformeerd er over wordt dus al had je jaten terug zelf 50 cijfers ingetikt de eerste
16 werden geteld. Ook de reden dat veel mensen problemen gehad meh pop accounts in mail toevoegen.
06-08-2012, 19:13 door
Wim ten Brink
Een online account kan niet zo 1-2-3 worden gekraakt mbv een bruteforce
Een enkele account niet, nee. Maar er bestaat een omgekeerde methode, waarbij de hacker kiest voor 1 wachtwoord en daarmee probeert in te loggen met een paar miljoen accountnamen. Het enige wat je nodig hebt is een adressenlijst zoals spammers die gebruiken. Ga eerst de lijst af met wachtwoord ABC123, ga dan nogmaals de lijst langs met een tweede wachtwoord, en dan een derde, vierde, vijfde... Laat dit werk uitvoeren door een botnet van 10.000 systemen en zo kun je langzaam maar zeker honderden accounts kraken.Enige wat je moet weten is wat populaire wachtwoorden zijn. Michael Garibaldi uit Babylon 5 had bijvoorbeeld "Peek-a-boo" als wachtwoord want wie zou dat raden? Na de betreffende aflevering, waarschijnlijk alle hackers die deze aflevering hebben gezien...
Het probleem is vooral de wachtwoord-collision. Meerdere gebruikers die gewoon hetzelfde wachtwoord gebruiken, zonder dit van elkaar te weten. Daarom was de hack in de LinkedIn database ook zo waardevol omdat men er aanwijzingen vond van de meest populaire wachtwoorden.
Als langere wachtwoorden zijn toegestaan, of passphrases zoals bij Google, dan is de kans dat twee of meer gebruikers hetzelfde wachtwoord gebruiken ook vele malen kleiner en is deze omgekeerde hack-aanval dus nutteloos. Maar zolang wachtwoorden een beperkte lengte hebben is deze omgekeerde brute-force methode erg effectief.
06-08-2012, 19:15 door
cyberpunk
Beetje zoals mijn ISP: Telenet. Al jaren is ons wachtwoord niet langer dan 8 karakters. Je kan er ook méér intypen, maar dat wordt gewoonweg genegeerd. Niet te begrijpen... Ik denk dat er heel wat gebruikers blij zouden zijn mochten we 16 karakters mogen gebruiken.
06-08-2012, 19:27 door
donnerd
Mijn wachtwoorden zijn standaard langer dan 16 tekens, gewoon uit veiligheid.
MS blundert nu steeds vaker, eerst was door een gebruiker steveballmer@outlook.com aangemaakt, en ook accounts als donotreply@outlook.com en nu dit.
Is veiligheid wel een prioriteit bij Microsoft?
MS blundert nu steeds vaker, eerst was door een gebruiker steveballmer@outlook.com aangemaakt, en ook accounts als donotreply@outlook.com en nu dit.
Is veiligheid wel een prioriteit bij Microsoft?
Hoe moeilijk kan het zijn??
1) Gebruik salt and hashing voordat je wachtwoorden opslaat.
2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.
3) Ga aanmoedigen om langere en complexere wachtwoorden te gebruiken.
4) Ga vooral niet doen alsof alles ok is en vervolgens gebruik je enkel de eerste x karakters van een oorspronkelijk langer wachtwoord voordat je deze in de database opslaat.
Kom op MS, we leven in 2012. We weten inmiddels wel dat 8 karakters niet meer voldoen. Dat het gros van de gebruikers alsnog "password" als wachtwoord gebruikt betekent niet dat je je authenticatie procedure niet op orde hoeft te hebben.
Ik begrijp werkelijk niet dat programmeurs c.q. hun managers er niet bij stil staan.
Jammer, maar wat de meest basale security awareness aangaat wordt er zelfs bij grote software bedrijven ontiegelijk geprutst.
1) Gebruik salt and hashing voordat je wachtwoorden opslaat.
2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.
3) Ga aanmoedigen om langere en complexere wachtwoorden te gebruiken.
4) Ga vooral niet doen alsof alles ok is en vervolgens gebruik je enkel de eerste x karakters van een oorspronkelijk langer wachtwoord voordat je deze in de database opslaat.
Kom op MS, we leven in 2012. We weten inmiddels wel dat 8 karakters niet meer voldoen. Dat het gros van de gebruikers alsnog "password" als wachtwoord gebruikt betekent niet dat je je authenticatie procedure niet op orde hoeft te hebben.
Ik begrijp werkelijk niet dat programmeurs c.q. hun managers er niet bij stil staan.
Jammer, maar wat de meest basale security awareness aangaat wordt er zelfs bij grote software bedrijven ontiegelijk geprutst.
Door WorkshopAlex:
Enige wat je moet weten is wat populaire wachtwoorden zijn. Michael Garibaldi uit Babylon 5 had bijvoorbeeld "Peek-a-boo" als wachtwoord want wie zou dat raden? Na de betreffende aflevering, waarschijnlijk alle hackers die deze aflevering hebben gezien...
Het probleem is vooral de wachtwoord-collision. Meerdere gebruikers die gewoon hetzelfde wachtwoord gebruiken, zonder dit van elkaar te weten. Daarom was de hack in de LinkedIn database ook zo waardevol omdat men er aanwijzingen vond van de meest populaire wachtwoorden.
Als langere wachtwoorden zijn toegestaan, of passphrases zoals bij Google, dan is de kans dat twee of meer gebruikers hetzelfde wachtwoord gebruiken ook vele malen kleiner en is deze omgekeerde hack-aanval dus nutteloos. Maar zolang wachtwoorden een beperkte lengte hebben is deze omgekeerde brute-force methode erg effectief.
Een online account kan niet zo 1-2-3 worden gekraakt mbv een bruteforce
Een enkele account niet, nee. Maar er bestaat een omgekeerde methode, waarbij de hacker kiest voor 1 wachtwoord en daarmee probeert in te loggen met een paar miljoen accountnamen. Het enige wat je nodig hebt is een adressenlijst zoals spammers die gebruiken. Ga eerst de lijst af met wachtwoord ABC123, ga dan nogmaals de lijst langs met een tweede wachtwoord, en dan een derde, vierde, vijfde... Laat dit werk uitvoeren door een botnet van 10.000 systemen en zo kun je langzaam maar zeker honderden accounts kraken.Enige wat je moet weten is wat populaire wachtwoorden zijn. Michael Garibaldi uit Babylon 5 had bijvoorbeeld "Peek-a-boo" als wachtwoord want wie zou dat raden? Na de betreffende aflevering, waarschijnlijk alle hackers die deze aflevering hebben gezien...
Het probleem is vooral de wachtwoord-collision. Meerdere gebruikers die gewoon hetzelfde wachtwoord gebruiken, zonder dit van elkaar te weten. Daarom was de hack in de LinkedIn database ook zo waardevol omdat men er aanwijzingen vond van de meest populaire wachtwoorden.
Als langere wachtwoorden zijn toegestaan, of passphrases zoals bij Google, dan is de kans dat twee of meer gebruikers hetzelfde wachtwoord gebruiken ook vele malen kleiner en is deze omgekeerde hack-aanval dus nutteloos. Maar zolang wachtwoorden een beperkte lengte hebben is deze omgekeerde brute-force methode erg effectief.
Tuurlijk.
Beweer je nou serieus dat de populaire dubbele wachtwoorden die gevonden worden 16 chars zijn ?
get real.
En , voor zo ver dat zo af en toe het geval zou zijn, dat die opeens boven de 16 karakters wel zouden gaan afwijken ?
Je kunt bijna met zekerheid aannemen dat een populair "dubbel" wachtwoord van zo'n lengte een bekende zin , quote of frase is, en dat als een groter aantal letters meegenomen wordt de gebruikers ervan dus vanuit dezelfde bron verlengen.
Voor de kans op dubbele wachtwoorden moet je zeker niet rekenen met een uniforme verdeling van letterfrequenties, maar met een uniforme mensheid...
06-08-2012, 20:23 door
golem
Nu deze tekortkoming in het nieuws staat zal het vast niet lang duren voordat
Microsoft dit aangepast zal hebben.
Volgens mij ook PR foutje om aan te geven dat er eigenlijk geen verandering is,
het was altijd al 16 tekens. :)
Gewoon probleem erkennen en zsm aanpassen.
Mijn wachtwoorden zijn standaard langer dan 16 tekens, gewoon uit veiligheid.
Bedankt, dan kunnen we beginnen met bruteforcen vanaf 17 tekens. ;)
Microsoft dit aangepast zal hebben.
Volgens mij ook PR foutje om aan te geven dat er eigenlijk geen verandering is,
het was altijd al 16 tekens. :)
Gewoon probleem erkennen en zsm aanpassen.
Mijn wachtwoorden zijn standaard langer dan 16 tekens, gewoon uit veiligheid.
ach ja, microsoft, lang volgehouden dat een bestandsnaam niet langer dan 8 karakters kon zijn. verkeerde bitjes zuinigheid.
06-08-2012, 23:47 door
donnerd
Door golem: Nu deze tekortkoming in het nieuws staat zal het vast niet lang duren voordat
.........
Bedankt, dan kunnen we beginnen met bruteforcen vanaf 17 tekens. ;)
Ik pas hem maandelijks aan, dus wens je veel succes..........
Bedankt, dan kunnen we beginnen met bruteforcen vanaf 17 tekens. ;)
07-08-2012, 00:20 door
burne101
Door Anoniem: Hoe moeilijk kan het zijn??
2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.
2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.
Gelukkig dat je gelijk even aantoont dat je de 'basale security awareness' mist. Een SHA1 password-hash is 160 bits, een SHA256 (je verwacht het niet) 256 bits. Bits, niet bytes. Meer dan 20 of 32 karakters gaat geen enkel voordeel opleveren voor de resulterende hash. Meer tiepwerk zonder enig zinnig resultaat. Meer opslag, zonder enig meetbaar voordeel qua security. Meer rekenwerk en dus energiegebruik en het maakt geen reet uit.
Om dat te onderstrepen: de huidige 'wedstrijd' voor een SHA-3 algoritme gaat uit van 256, 384 en 512 bit hashes. Met de lessen van MD4, MD5 en SHA-1 in het achterhoofd is er gekozen voor een totaal andere opzet van het berekenen van de hash, niet voor een extreem verlengde hash. Waarom?
07-08-2012, 09:44 door
Overcome
Door burne101:
Gelukkig dat je gelijk even aantoont dat je de 'basale security awareness' mist. Een SHA1 password-hash is 160 bits, een SHA256 (je verwacht het niet) 256 bits. Bits, niet bytes. Meer dan 20 of 32 karakters gaat geen enkel voordeel opleveren voor de resulterende hash. Meer tiepwerk zonder enig zinnig resultaat. Meer opslag, zonder enig meetbaar voordeel qua security. Meer rekenwerk en dus energiegebruik en het maakt geen reet uit.
Door Anoniem: Hoe moeilijk kan het zijn??
2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.
2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.
Gelukkig dat je gelijk even aantoont dat je de 'basale security awareness' mist. Een SHA1 password-hash is 160 bits, een SHA256 (je verwacht het niet) 256 bits. Bits, niet bytes. Meer dan 20 of 32 karakters gaat geen enkel voordeel opleveren voor de resulterende hash. Meer tiepwerk zonder enig zinnig resultaat. Meer opslag, zonder enig meetbaar voordeel qua security. Meer rekenwerk en dus energiegebruik en het maakt geen reet uit.
Niet waar. Er bestaat ook nog zoiets als entropie. Zie b.v. http://en.wikipedia.org/wiki/Entropy_(information_theory). Jouw 20 karakters hebben een VEEL lagere entropie dan 160 bits, zeker als het wachtworod niet 100% random gekozen is.
De vraag is hoeveel personen daadwerkelijk een wachtwoord hebben van meer dan 16 karakters. Dat aantal is veelal op de vingers van 1 hand te tellen. De volgende vraag is dan: wat is het risico dat het wachtwoord wordt afgekapt op 16 karakters? Het antwoord op die vraag heb ik nog nergens gezien.
Zijn wachtwoorden niet sowieso passé? Meer karakters maken wachtwoorden niet persé veiliger, een combinatie van allerlei karakters wel, en dan hoeft een wachtwoord echt geen 16 karakters te zijn. Daarnaast, hoe langer een wachtwoord hoe meer mensen geneigd zijn om het té simpel te houden.
Wachtwoorden alleen gaan gewoon niet meer werken, als we het gebruiksgemak ook nog een in ogenschouw nemen. Dat zal voor de toekomst toch echt in combinatie met een 2e of misschien wel een 3e factor moeten. Dus niet alleen 'iets wat je weet' maar ook 'iets dat je hebt' of zelfs 'iets dat je bent'. Je ziet al notebooks verschijnen met daarop software waarmee je via 'face regocnition' kan inloggen. Nu stelt dat nog niet zoveel voor, want hou er een foto van jezelf voor en het werkt ook, maar dat neemt niet weg dat het wel een ontwikkeling is waar we naar toe moeten.
Wachtwoorden alleen gaan gewoon niet meer werken, als we het gebruiksgemak ook nog een in ogenschouw nemen. Dat zal voor de toekomst toch echt in combinatie met een 2e of misschien wel een 3e factor moeten. Dus niet alleen 'iets wat je weet' maar ook 'iets dat je hebt' of zelfs 'iets dat je bent'. Je ziet al notebooks verschijnen met daarop software waarmee je via 'face regocnition' kan inloggen. Nu stelt dat nog niet zoveel voor, want hou er een foto van jezelf voor en het werkt ook, maar dat neemt niet weg dat het wel een ontwikkeling is waar we naar toe moeten.
@burne101:
Wat ik begrijp in je verhaal is dat je zegt, een wachtwoord is 20 bytes, dat is 20*8bits=160 bits. Als je meer tekens gebruikt dan past dat niet meer in de hash en de rest is daarom overtollige informatie.
Maar het gaat bij wachtwoorden meer om de willekeur, ook wel entropie genoemd. Daarnaast wordt er per teken in een wachtwoord maar een subset gebruikt van de gehele byte.
Een 20 karakter lang random wachtwoord met alleen hoofdletters, kleine letters, cijfers en speciale tekens heeft volgens de wachtwoord generator van KeePass slechts 132 bits aan entropie.
De meeste mensen vinden volledig random wachtwoorden met speciale tekens zeer lastig te onthouden. In de praktijk is meer dan 20 karakters voor encryptie niet ongewoon. Daarnaast gebruiken mensen vaak ook passphrases, hele zinnen om dan aan de 120+bits aan willekeur te komen, moet je een zin van zo'n 19 woorden invullen.
Daarnaast is er in de SHA2 familie ook SHA-512.
Wat ik begrijp in je verhaal is dat je zegt, een wachtwoord is 20 bytes, dat is 20*8bits=160 bits. Als je meer tekens gebruikt dan past dat niet meer in de hash en de rest is daarom overtollige informatie.
Maar het gaat bij wachtwoorden meer om de willekeur, ook wel entropie genoemd. Daarnaast wordt er per teken in een wachtwoord maar een subset gebruikt van de gehele byte.
Een 20 karakter lang random wachtwoord met alleen hoofdletters, kleine letters, cijfers en speciale tekens heeft volgens de wachtwoord generator van KeePass slechts 132 bits aan entropie.
De meeste mensen vinden volledig random wachtwoorden met speciale tekens zeer lastig te onthouden. In de praktijk is meer dan 20 karakters voor encryptie niet ongewoon. Daarnaast gebruiken mensen vaak ook passphrases, hele zinnen om dan aan de 120+bits aan willekeur te komen, moet je een zin van zo'n 19 woorden invullen.
Daarnaast is er in de SHA2 familie ook SHA-512.
De grond van de zaak is dat er minder symbolen gebruikt werden dan de gebruiker ingaf zonder verwittiging.
Dat doe je niet. "probeerditmaartekraken" is redelijk ok, "probeerd" is dat niet. Zo'n verschil wil ik weten.
anonym 19:42 vat het goed samen: waarom??
Deze discussie laat ook wel weer zien dat cryptografie te moeilijk is tenzij voor uitzonderingen, waar ik me niet bij reken.
golem: beginnen vanaf 17 levert nauwelijks iets van winst op totale tijdsduur.
burne101: entropy! zelfs met 1 letter is je hash al full-size, dat is niet het punt: 30 symbolen is 240bits,
meestal geen 240 bit aan entropy
Dat doe je niet. "probeerditmaartekraken" is redelijk ok, "probeerd" is dat niet. Zo'n verschil wil ik weten.
anonym 19:42 vat het goed samen: waarom??
Deze discussie laat ook wel weer zien dat cryptografie te moeilijk is tenzij voor uitzonderingen, waar ik me niet bij reken.
golem: beginnen vanaf 17 levert nauwelijks iets van winst op totale tijdsduur.
burne101: entropy! zelfs met 1 letter is je hash al full-size, dat is niet het punt: 30 symbolen is 240bits,
meestal geen 240 bit aan entropy
07-08-2012, 10:08 door
Skizmo
Door golem: Nu deze tekortkoming in het nieuws staat zal het vast niet lang duren voordat
Microsoft dit aangepast zal hebben.
Volgens mij ook PR foutje om aan te geven dat er eigenlijk geen verandering is,
het was altijd al 16 tekens. :)
Gewoon probleem erkennen en zsm aanpassen.
Mijn wachtwoorden zijn standaard langer dan 16 tekens, gewoon uit veiligheid.
Bedankt, dan kunnen we beginnen met bruteforcen vanaf 17 tekens. ;)
Dan wens ik je daar veel success mee. Hoeveel jaar heb je de tijd ?Microsoft dit aangepast zal hebben.
Volgens mij ook PR foutje om aan te geven dat er eigenlijk geen verandering is,
het was altijd al 16 tekens. :)
Gewoon probleem erkennen en zsm aanpassen.
Mijn wachtwoorden zijn standaard langer dan 16 tekens, gewoon uit veiligheid.
07-08-2012, 10:09 door
eriky
Dit impliceert ook dat Microsoft (en anderen) de wachtwoorden ongecodeerd opslaan. Er is namelijk geen enkele andere reden waarom je de lengte zou willen beperkte. Een hash is een hash, of je die nou maakt van een string van 1024 bytes of van 16 bytes. Dus het is wachten op het volgende schandaal..?
Door eriky: Dit impliceert ook dat Microsoft (en anderen) de wachtwoorden ongecodeerd opslaan. Er is namelijk geen enkele andere reden waarom je de lengte zou willen beperkte. Een hash is een hash, of je die nou maakt van een string van 1024 bytes of van 16 bytes. Dus het is wachten op het volgende schandaal..?
Die reden is er wel.
Ergens moet je de invoer afkappen (4G ? ) , gewoon omdat je in de verwerkingsketen geen ongelimiteerde invoer kunt toestaan.
Die lengte moet op alle plekken waar passwords ingevoerd worden gelijk zijn.
Omdat de hash van een string die op 16 karakters afgekapt is, anders is dan de hash van een string die op 32 karakters is afgekapt, maar waarvan de eerste 16 gelijk zijn.
Als je voor nogal grote lengtes kiest, ga je ook problemen krijgen dat client software z'n eigen beperkingen heeft, en mensen die met de ene client (browser) een lang password gekozen hebben, met hun smartphone imap client misschien dat lange password niet KUNNEN meegeven.
Het zijn (als ik alleen maar kijk op dit forum) maar heel weinig mensen die dat zelf snappen. En al helemaal niet als zo'n beperkte client misschien wel een stille beperking heeft (lang veld accepteren, truncated string sturen).
Kortom, met een dergelijke dienst moet je ergens een keuze maken, die door een ongetwijfeld grote en historisch gegroeide codebase consequent doorvoeren, en een hoop afwegingen maken die veel verder gaan dan simpelweg "groter = beter dus MAXINT buffer".
07-08-2012, 15:01 door
Overcome
Door eriky: Dit impliceert ook dat Microsoft (en anderen) de wachtwoorden ongecodeerd opslaan.
Nee hoor. We hebben binnen ons bedrijf een applicatie die wachtwoorden ook afkapt, maar waarbij de wachtwoorden gecodeerd worden opgeslagen. In ons geval betreft het een legacy applicatie die door de jaren heen functioneel is aangepast, alleen niet de password functionaliteit. Het risico dat misbruik wordt gemaakt van de afkapping is ingeschat als zeer laag, mede doordat de applicatie en het netwerk waarop het draait op meerdere manieren is beveiligd. Als gevogl daarvan komt er geen budget vrij voor het aanpassen van de code. Met name door de leeftijd van de applicatie en de ontbrekende documentatie vereist die aanpassing zoveel uren, dat het risico is geaccepteerd.
Geen idee wat de reden is voor Microsoft. Misschien hebben ze ook een risicoafweging gemaakt.
@burne101 , de passwordlengte heeft geen relatie met de resulterende hash , die heeft een fixed lengte , maar je kun een kompleert document door een hash algoritme heen gooien, vervolgens in het document 1 byte veranderen en de hash kan geheel anders zijn (avelanche effect) . Dus het hashing algoritme beperkt niet de passwordlengte .
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.