NIST-medewerker betreurt advies over 'veilige' wachtwoorden
De medewerker van het National Institute of Standards and Technology (NIST) die in 2003 een document over 'veilige' wachtwoorden opstelde waar veel organisaties gebruik van maakten, heeft spijt van zijn advies. Dat laat voormalig NIST-medewerker Bill Burr in een interview met de Wall Street Journal weten.
NIST is een Amerikaanse organisatie die onder andere verantwoordelijk is voor het opstellen van beveiligingsrichtlijnen voor de Amerikaanse overheid. De nu 72-jarige Burr publiceerde in 2003 de "NIST Special Publication 800-63. Appendix A". Een acht pagina's tellend document met advies voor het maken van wachtwoorden. In het advies wordt aangeraden om bijvoorbeeld klinkers door speciale karakters te vervangen. Dit zou tot een wachtwoord als P@sswrD1! leiden. Dergelijke wachtwoorden zijn echter eenvoudig te kraken. Ook adviseerde Burr om wachtwoorden elke 90 dagen te veranderen. Ook dat is volgens experts onnodig.
Burr stelt dat zijn advies voor veel mensen te lastig was. "Het maakte mensen helemaal gek en ze kiezen geen goede wachtwoorden, ongeacht wat je doet", zo merkt hij op. Inmiddels heeft het NIST nieuw advies voor veilige wachtwoorden gepubliceerd waarin de vereiste voor speciale karakters en het wijzigen van wachtwoorden na bepaalde tijd is verwijderd. Zowel het NIST als experts adviseren nu passphrases. Dit zijn wachtwoorden die uit meerdere woorden bestaan en lastig te raden en te kraken zijn, maar eenvoudig voor de gebruiker zijn om te onthouden. Het advies van Burr is in dit gearchiveerde document (pdf) op pagina's 46 tot en met 54 terug te vinden.
Reacties (22)
08-08-2017, 10:52 door
karma4
Het bekende verhaal van voortschrijdend inzicht en als met de kennis van nu hadden we het tken anders gedaan.
Wel jammer dat kritische geluiden onder het mom van best practices onderuit gehaald worden. Good practice is pdca.
Wel jammer dat kritische geluiden onder het mom van best practices onderuit gehaald worden. Good practice is pdca.
Dus minstens 8 karakters en complexiteit is niet nodig? Dat lijkt me erg snel onderuit gehaald met bruteforce?
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Door karma4: Het bekende verhaal van voortschrijdend inzicht en als met de kennis van nu hadden we het tken anders gedaan.
Wel jammer dat kritische geluiden onder het mom van best practices onderuit gehaald worden. Good practice is pdca.
Wel jammer dat kritische geluiden onder het mom van best practices onderuit gehaald worden. Good practice is pdca.
Helemaal waar. Maar logisch nadenken is altijd beter. Het is (was) te voorzien dat mensen de wachtwoorden gingen opschrijven of dan vergemakkelijken.
Ik heb altijd geroepen beter een goed wacht woord elke 2jaar veranderen dan elke 3mnd een slecht wachtwoord.
08-08-2017, 11:14 door
[Account Verwijderd]
[Verwijderd]
Door OpenXOR:
Door Anoniem:
Ik heb altijd geroepen beter een goed wacht woord elke 2jaar veranderen dan elke 3mnd een slecht wachtwoord.
Ook elke 2 jaar wijzigen is zinloos. Wijzigen doe je alleen na (vermoeden van) een inbreuk op je account of wachtwoord.Ik heb altijd geroepen beter een goed wacht woord elke 2jaar veranderen dan elke 3mnd een slecht wachtwoord.
Dan is het te laat - als je er al achter komt . (Het zijn nog veel te weinig plekken die duidelijk melden waar je laatste login vandaan kwam (plaats, device) , en hard toeteren als dat 'onverwacht' was ) .
De gedachte achter wijziging is om eventueel stilletjes verloren passwords tenminste na enige tijd onbruikbaar te maken voor de vinder .
Een one-time password is de meest extreme variant .
De aanbevolen wijzigingstijden zijn een natte-vinger risico afweging tussen te structureel gekozen (of te makkelijk vindbare briefjes) bij frequente wijzigingen en het expiren van stilletjes verloren credentials .
Door Anoniem: Dus minstens 8 karakters en complexiteit is niet nodig? Dat lijkt me erg snel onderuit gehaald met bruteforce?
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Minimaal 8 tekens wordt nog aangeraden:
https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
Zie ook:
https://pages.nist.gov/800-63-3/sp800-63b.html#appA
Voor de methode die ik (Fwiffo) gebruik, zie:
https://www.security.nl/posting/470888#posting470988
GnuPG 1.4.x kan vervangen worden door GnuPG 2.1 (command line). De bedoeling is dat deze methode betere randomness oplevert als dat de gebruiker dit zelf kiest.
Door Anoniem: Dus minstens 8 karakters en complexiteit is niet nodig? Dat lijkt me erg snel onderuit gehaald met bruteforce?
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Als ik configureer dat het account na 5 foutieve pogingen wordt geblokkeerd, dan maakt het niet uit. Als je de versleutelde database al in je bezit hebt, dan maakt die lengte ook weinig meer uit.
Door Anoniem:
Helemaal waar. Maar logisch nadenken is altijd beter. Het is (was) te voorzien dat mensen de wachtwoorden gingen opschrijven of dan vergemakkelijken.
Ik heb altijd geroepen beter een goed wacht woord elke 2jaar veranderen dan elke 3mnd een slecht wachtwoord.
\Door karma4: Het bekende verhaal van voortschrijdend inzicht en als met de kennis van nu hadden we het tken anders gedaan.
Wel jammer dat kritische geluiden onder het mom van best practices onderuit gehaald worden. Good practice is pdca.
Wel jammer dat kritische geluiden onder het mom van best practices onderuit gehaald worden. Good practice is pdca.
Helemaal waar. Maar logisch nadenken is altijd beter. Het is (was) te voorzien dat mensen de wachtwoorden gingen opschrijven of dan vergemakkelijken.
Ik heb altijd geroepen beter een goed wacht woord elke 2jaar veranderen dan elke 3mnd een slecht wachtwoord.
Wachtwoorden zijn toch niet bruikbaar voor een serieus beveiligingsnivo dus al te draconische eisen er aan stellen
is onnodig. Een wachtwoord gebruik je alleen voor minimale beveiliging, bijvoorbeeld in-house inloggen, het mail account
van oma, een webshop waar je even terug komt voor het checken van je order. Voor iets wat echte beveiliging nodig heeft,
zoals toegang tot een informatiesysteem vanaf internet, is een usernaam/wachtwoord authenticatie absoluut onvoldoende.
Door Anoniem:
Als ik configureer dat het account na 5 foutieve pogingen wordt geblokkeerd, dan maakt het niet uit. Als je de versleutelde database al in je bezit hebt, dan maakt die lengte ook weinig meer uit.
Door Anoniem: Dus minstens 8 karakters en complexiteit is niet nodig? Dat lijkt me erg snel onderuit gehaald met bruteforce?
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Het idee om de complexiteit niet af te dwingen vind ik goed, maar zorg dan wel voor een deftige lengte.
Als ik configureer dat het account na 5 foutieve pogingen wordt geblokkeerd, dan maakt het niet uit. Als je de versleutelde database al in je bezit hebt, dan maakt die lengte ook weinig meer uit.
Goed punt van die inlogpogingen, niet aan gedacht, erg effectief lijkt me.
Als ik een wachtwoord gebruik van 20 karakters, ook al zijn het enkel kleine letters, dan hebben ze toch best veel tijd nodig om dat te kraken. Bij 8 karakters daarentegen. En het zijn enkel salted hashes die je dan hebt, als het goed is, niet gewoon versleuteld.
Ook elke 2 jaar wijzigen is zinloos. Wijzigen doe je alleen na (vermoeden van) een inbreuk op je account of wachtwoord.
Ehm. Dus zolang je niet weet dat je compromised bent, dan steek je je kop in het zand ? Door deze houding blijven accounts soms jarenlang compromised. Maarja, wat niet weet, wat niet deert ? Je kan er beter vanuit gaan dat je hoe dan ook 'mogelijk' compromised bent. Waarbij je periodiek voor de zekerheid dus wel wachtwoorden enzo aanpast.
Hoe veel mensen die menen dat ze veilig zijn kunnen denk je hun credentials terugvinden in bijvoorbeeld de HaveIBeenPowned database ?
Password complexiteit maakt daarbij verder niet zo heel veel uit; als je compromised wordt t.g.v. een keylogger, of phishing om maar wat te noemen, dan is ieder password kwetsbaar, hoe 'complex' ook.
Het beste zou zijn om altijd gebruik te maken van multifactor authenticatie, zodat je naast je wachtwoord nog een extra code nodig hebt om in te loggen (via een soft- of hardtoken, sms authenticatie etc).
Gelukkig zijn er steeds meer diensten die gebruik maken van bijvoorbeeld Google Authenticator om extra beveiliging te bieden (aangezien dure tokens voor gratis webdiensten idd niet echt geschikt zijn).
Ik pleit voor een algemene en wereldwijde Password Standaard. Nu heeft elke website zijn eigen benadering: bij de een mogen geen punt of comma's voorkomen en bij de ander geen moeilijke tekens als @#$ etc.. Ik zou zeggen: tussen de 8 en 30 karakters en alles mag!!
Mijn oude stijl was bv:
$NL-2515$hg,(ING)
voor als ik bij de bank inlogde
$,() voor geldzaken
@NL-2515@hg,<MAIL>
voor als ik bij de Mail inlogde
@,<> voor Privezaken
#NL-2515#hg,*Marktplaats*
voor als ik op websites inlog
#,** voor internetpagina's
of nog ouder:
100 ifM$=(@)thenM$=Mail
Waarbij Mail voor allerlei variaties kan zijn mail1-mail2 etc.
100 ifM$=(#)thenMS=Markplaats
Waarbij Marktplaats ook OSM Ebay ENECO of DIGID welk je natuurlijk ook moeilijk maakt 3n3c0 of 38@Y
100 ifM$=($)thenM$=ING
Waarbij ING ook AEGON of PayPal kan zijn of elke variatie daarop
Irritante is dat sommige websites geen @ # $ % ^ & () ! willen toestaan waardoor een wachtwoord patroon moeilijker wordt te maken. Ik vind gewoon stom dat sommige ICT lui bepalen hoe Jij je wachtwoord moet maken.. Waardoor je weer 100 verschillende wachtwoorden krijgt die je niet kunt onthouden en dus weer gaan opschrijven..
Je kunt het zo moeilijk maken als je wilt maar als er geen variaties op verschillende websites gemaakt kan worden heeft moeilijke wachtwoorden geen zin tenzij je hetzelfde wachtwoord opnieuw gebruikt.. Beetje jammer..
http://www.wachtwoordtesten.nl/
https://howsecureismypassword.net/
Mijn oude stijl was bv:
$NL-2515$hg,(ING)
voor als ik bij de bank inlogde
$,() voor geldzaken
@NL-2515@hg,<MAIL>
voor als ik bij de Mail inlogde
@,<> voor Privezaken
#NL-2515#hg,*Marktplaats*
voor als ik op websites inlog
#,** voor internetpagina's
of nog ouder:
100 ifM$=(@)thenM$=Mail
Waarbij Mail voor allerlei variaties kan zijn mail1-mail2 etc.
100 ifM$=(#)thenMS=Markplaats
Waarbij Marktplaats ook OSM Ebay ENECO of DIGID welk je natuurlijk ook moeilijk maakt 3n3c0 of 38@Y
100 ifM$=($)thenM$=ING
Waarbij ING ook AEGON of PayPal kan zijn of elke variatie daarop
Irritante is dat sommige websites geen @ # $ % ^ & () ! willen toestaan waardoor een wachtwoord patroon moeilijker wordt te maken. Ik vind gewoon stom dat sommige ICT lui bepalen hoe Jij je wachtwoord moet maken.. Waardoor je weer 100 verschillende wachtwoorden krijgt die je niet kunt onthouden en dus weer gaan opschrijven..
Je kunt het zo moeilijk maken als je wilt maar als er geen variaties op verschillende websites gemaakt kan worden heeft moeilijke wachtwoorden geen zin tenzij je hetzelfde wachtwoord opnieuw gebruikt.. Beetje jammer..
http://www.wachtwoordtesten.nl/
https://howsecureismypassword.net/
Hoe goed is het wachtwoord: Ik hou van chocolade
Omgezet in een MD5 getal C390DDFF592E521883EA6A28E6F8B2A6
en in een SHA256 getal 70408281449ecd7abf3f2d83c626af92c270d62dc3477c061d593793e5a0c1b4
Wat is sterker, het wachtwoord in platte tekst, of omgezet in een controlegetal
Voorwaarde is natuurlijk dat het wachtwoord mag worden geplakt.
Omgezet in een MD5 getal C390DDFF592E521883EA6A28E6F8B2A6
en in een SHA256 getal 70408281449ecd7abf3f2d83c626af92c270d62dc3477c061d593793e5a0c1b4
Wat is sterker, het wachtwoord in platte tekst, of omgezet in een controlegetal
Voorwaarde is natuurlijk dat het wachtwoord mag worden geplakt.
Door Anoniem: Ik pleit voor een algemene en wereldwijde Password Standaard.
Ik pleit voor een algemene en wereldwijde NO Password Standaard.
Gewoon alles met met public key beveiligen (X509, OpenPGP, etcetera).
Een sleutelpaar per persoon (of per virtuele identiteit) en per apparaat
Elke dienstverlener/leverancier krijgt de public key.
Voor zaken waarvoor de echte identiteit erg belangrijk is, kunnen we de certificering van public keys overlaten aan mensen achter de blauwe enveloppen. Die weten immers toch altijd wie en waar je bent.
Tegenwoordig heb je overal wachtwoorden voor nodig en onthouden is onmogelijk. Opschrijven is helemaal niet erg. Dat is juist goed, want het is niet digitaal en het kan alleen worden gestolen als je het gebruikt. Dat is ook meteen de reden waarom wachtwoorden niet vaak veranderd moeten worden, want dat is weer een kans voor een dief met een keylogger.
@15:43 door Anoniem
Mijn public keys zijn - op 1 uitzondering na - niet publiek en dat blijft zo.
@15:43 door Anoniem
Mijn public keys zijn - op 1 uitzondering na - niet publiek en dat blijft zo.
Hoe goed is het wachtwoord: Ik hou van chocolade
Omgezet in een MD5 getal C390DDFF592E521883EA6A28E6F8B2A6
en in een SHA256 getal 70408281449ecd7abf3f2d83c626af92c270d62dc3477c061d593793e5a0c1b4
Wat is sterker, het wachtwoord in platte tekst, of omgezet in een controlegetal
Omgezet in een MD5 getal C390DDFF592E521883EA6A28E6F8B2A6
en in een SHA256 getal 70408281449ecd7abf3f2d83c626af92c270d62dc3477c061d593793e5a0c1b4
Wat is sterker, het wachtwoord in platte tekst, of omgezet in een controlegetal
Of het wachtwoord 496b20686f752076616e2063686f636f6c616465?
Als het wachtwoord volgens een algoritme (MD5,SHA256,BinHex,L33tsp34k) is gegenereerd, dan kun je nog steeds een dictionary of brute force attack uitvoeren op de mogelijke brondata.
Door Anoniem: ....
Dan is het te laat - als je er al achter komt . (Het zijn nog veel te weinig plekken die duidelijk melden waar je laatste login vandaan kwam (plaats, device) , en hard toeteren als dat 'onverwacht' was ) .
Even denken je stelt voor om bij het jaarlijks verlengen van een abonnement waar verder weinig impact is een wachtwoordwijziiging te eisen met een moeilijk iets om de drie maanden? Vij keer gebruiken doorlooptijd 5 jaar. Nee daarvoor gebruik een apart iets.Dan is het te laat - als je er al achter komt . (Het zijn nog veel te weinig plekken die duidelijk melden waar je laatste login vandaan kwam (plaats, device) , en hard toeteren als dat 'onverwacht' was ) .
Kritisch service account? Aub een zeer moeilijk ww nooit dan wel minimaal veranderen echter toe gekoppeld aan mfa bijvoorbeeld alleen intern netwerk met aparte goedkeuring op ip werkstation..
Een rekening betalen ww pin en liefst na enkele keren fout met delay blokkade en b.v een SM. Herkenning van gebruikt ip Mac maar wel van te voren aangeven (localisering ).
Juist het vinkenlijstje van het hoort zo veroorzaakt echte elllende. Je krijgt daar later spijt van.
Door Anoniem:
Of het wachtwoord 496b20686f752076616e2063686f636f6c616465?
Als het wachtwoord volgens een algoritme (MD5,SHA256,BinHex,L33tsp34k) is gegenereerd, dan kun je nog steeds een dictionary of brute force attack uitvoeren op de mogelijke brondata.
Hoe goed is het wachtwoord: Ik hou van chocolade
Omgezet in een MD5 getal C390DDFF592E521883EA6A28E6F8B2A6
en in een SHA256 getal 70408281449ecd7abf3f2d83c626af92c270d62dc3477c061d593793e5a0c1b4
Wat is sterker, het wachtwoord in platte tekst, of omgezet in een controlegetal
Omgezet in een MD5 getal C390DDFF592E521883EA6A28E6F8B2A6
en in een SHA256 getal 70408281449ecd7abf3f2d83c626af92c270d62dc3477c061d593793e5a0c1b4
Wat is sterker, het wachtwoord in platte tekst, of omgezet in een controlegetal
Of het wachtwoord 496b20686f752076616e2063686f636f6c616465?
Als het wachtwoord volgens een algoritme (MD5,SHA256,BinHex,L33tsp34k) is gegenereerd, dan kun je nog steeds een dictionary of brute force attack uitvoeren op de mogelijke brondata.
Op elk wachtwoord kan je een dictionary of brute force attack uitvoeren, maar dat was de vraag niet.
Zowel het NIST als experts adviseren nu passphrases, Dit zijn wachtwoorden die uit meerdere woorden bestaan en lastig te raden en te kraken zijn, maar eenvoudig voor de gebruiker zijn om te onthouden.
Waarom zou een passphrasse "Ik hou van chocolade" moeilijker te raden zijn dan bijv een SHA256 afgeleide hash daarvan.
Sinds NIST met gemanipuleerde rapporten is gekomen over 911 behandel ik ze als een onbetrouwbare organisatie en neem alles wat ze uitbraken met een flinke korrel zout .
Gewoon sqrl gebruiken ben je van al het wachtwoord gedoe af.
https://www.grc.com/sqrl/sqrl.htm
Zijn bijna klaar voor de uitrol.
https://www.grc.com/sqrl/sqrl.htm
Zijn bijna klaar voor de uitrol.
Allereerst heb ik meer vertrouwen in mijn eigen keuze dan een software programma die één en ander van mij overneemt.
Daarbij heb ik ook een gezonde argwaan richting een autoriteit die ons nu verteld dat een wachtzin die ongetwijfeld gemakkelijker is te onthouden, maar ook veiliger dan een willekeurig gegenereerd wachtwoord van dezelfde lengte zou zijn.
Ik heb hier mijn bedenkingen over, niet gebaseerd op feitelijk onderbouwde kennis van zaken, maar gewoon gezond redeneren. Natuurlijk een wachtzin gebaseerd op een citaat uit een boek, of film is zelfs met enige aanvullingen vragen om moeilijkheden. De vraag is hoe wordt een wachtwoord c.q. wachtzin nu eigenlijk gekraakt. Is dat per woord, of moet het kwartje ineens vallen. "Ik hou van Chocolade" wordt nu eerst het woord "Ik" ontdekt en daar op voortgeborduurd, en dan de spatie die daar tussen staat, enz. enz.
Het is niet duidelijk hoe dit te werk gaat. Tenslotte een 64 bits willekeurige karakters kan onmogelijk met de huidige computers worden gekraakt, of heb ik dat niet goed begrepen.
Daarbij heb ik ook een gezonde argwaan richting een autoriteit die ons nu verteld dat een wachtzin die ongetwijfeld gemakkelijker is te onthouden, maar ook veiliger dan een willekeurig gegenereerd wachtwoord van dezelfde lengte zou zijn.
Ik heb hier mijn bedenkingen over, niet gebaseerd op feitelijk onderbouwde kennis van zaken, maar gewoon gezond redeneren. Natuurlijk een wachtzin gebaseerd op een citaat uit een boek, of film is zelfs met enige aanvullingen vragen om moeilijkheden. De vraag is hoe wordt een wachtwoord c.q. wachtzin nu eigenlijk gekraakt. Is dat per woord, of moet het kwartje ineens vallen. "Ik hou van Chocolade" wordt nu eerst het woord "Ik" ontdekt en daar op voortgeborduurd, en dan de spatie die daar tussen staat, enz. enz.
Het is niet duidelijk hoe dit te werk gaat. Tenslotte een 64 bits willekeurige karakters kan onmogelijk met de huidige computers worden gekraakt, of heb ik dat niet goed begrepen.
Door Anoniem: Gewoon sqrl gebruiken ben je van al het wachtwoord gedoe af.
https://www.grc.com/sqrl/sqrl.htm
Zijn bijna klaar voor de uitrol.
https://www.grc.com/sqrl/sqrl.htm
Zijn bijna klaar voor de uitrol.
--
Not so Sure About that!! But Maybe...
http://resources.infosecinstitute.com/security-attacks-via-malicious-qr-codes/#gref
Door Anoniem: Allereerst heb ik meer vertrouwen in mijn eigen keuze dan een software programma die één en ander van mij overneemt.
Daarbij heb ik ook een gezonde argwaan richting een autoriteit die ons nu verteld dat een wachtzin die ongetwijfeld gemakkelijker is te onthouden, maar ook veiliger dan een willekeurig gegenereerd wachtwoord van dezelfde lengte zou zijn.
Ik heb hier mijn bedenkingen over, niet gebaseerd op feitelijk onderbouwde kennis van zaken, maar gewoon gezond redeneren. Natuurlijk een wachtzin gebaseerd op een citaat uit een boek, of film is zelfs met enige aanvullingen vragen om moeilijkheden. De vraag is hoe wordt een wachtwoord c.q. wachtzin nu eigenlijk gekraakt. Is dat per woord, of moet het kwartje ineens vallen. "Ik hou van Chocolade" wordt nu eerst het woord "Ik" ontdekt en daar op voortgeborduurd, en dan de spatie die daar tussen staat, enz. enz.
Het is niet duidelijk hoe dit te werk gaat. Tenslotte een 64 bits willekeurige karakters kan onmogelijk met de huidige computers worden gekraakt, of heb ik dat niet goed begrepen.
Daarbij heb ik ook een gezonde argwaan richting een autoriteit die ons nu verteld dat een wachtzin die ongetwijfeld gemakkelijker is te onthouden, maar ook veiliger dan een willekeurig gegenereerd wachtwoord van dezelfde lengte zou zijn.
Ik heb hier mijn bedenkingen over, niet gebaseerd op feitelijk onderbouwde kennis van zaken, maar gewoon gezond redeneren. Natuurlijk een wachtzin gebaseerd op een citaat uit een boek, of film is zelfs met enige aanvullingen vragen om moeilijkheden. De vraag is hoe wordt een wachtwoord c.q. wachtzin nu eigenlijk gekraakt. Is dat per woord, of moet het kwartje ineens vallen. "Ik hou van Chocolade" wordt nu eerst het woord "Ik" ontdekt en daar op voortgeborduurd, en dan de spatie die daar tussen staat, enz. enz.
Het is niet duidelijk hoe dit te werk gaat. Tenslotte een 64 bits willekeurige karakters kan onmogelijk met de huidige computers worden gekraakt, of heb ik dat niet goed begrepen.
Een spatie is net zogoed een teken, de aanvaller weet niet waar de spaties zitten en zou dus de wachtzin/passphrase in één keer goed moeten 'brute forcen'. Dat kan niet per woord. Vandaar dat een zin ook beter is, het is een stuk langer en makkelijker te onthouden. Wanneer je interpunctie gebruikt in de zin zorgt dat voor nog meer complexiteit, om dit te kraken met brute force heeft de aanvaller een gigantische lijst met mogelijkheden, computerkracht en tijd nodig. (wat het vaak niet doenlijk of waard maakt)
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.
