Versleutelde wachtwoorden gestolen bij aanval op HvA en UvA
Bij de aanval op de Hogeschool van Amsterdam (HvA) en Universiteit van Amsterdam (UvA) die vorige week plaatsvond zijn versleutelde wachtwoorden van medewerkers en studenten gestolen, zo hebben de onderwijsinstellingen vandaag via de eigen website bekendgemaakt. Studenten en medewerkers worden opgeroepen om hun wachtwoord te wijzigen.
Om wat voor aanval het precies gaat is nog altijd onduidelijk, alsmede hoe de aanvallers wisten binnen te dringen. "Uit onderzoek is gebleken dat de hackers de beschikking hebben over de versleutelde wachtwoorden. Ondanks de versleuteling zouden hackers daar misbruik van kunnen maken. Daarom vragen we alle studenten en medewerkers om uit voorzorg het wachtwoord te wijzigen", aldus de onderwijsinstellingen in een update over het incident.
De HvA en UvA maken gebruik van een gezamenlijke ict-dienst die door de aanval is getroffen. De oproep aan studenten en medewerkers om het wachtwoord te wijzigen kon pas worden gedaan nadat de aanvallers geen toegang meer tot dat deel van het systeem hebben. "Dat is inmiddels het geval. Direct daarna zijn medewerkers en studenten gevraagd om hun wachtwoord te wijzigen. Na wijziging zijn deze gegevens veilig", zo laten de HvA en UvA weten.
Hoe de aanvallers binnen wisten te dringen wordt nog onderzocht. Ook is nog altijd niet duidelijk gemaakt om wat voor aanval het precies gaat. Wel spreken de onderwijsinstellingen over geïnfecteerde systemen wat op malware lijkt te duiden. Eerder werd al gesteld dat de aanval is uitgevoerd door "professionele hackers" die op "financieel gewin" uit zijn. Op de vraag of er om losgeld is gevraagd melden de HvA en UvA dat het door vroege detectie en ingrijpen zover niet is gekomen.
Reacties (19)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
Hopelijk zijn *alle* accounts gereset, dus ook de AD credentials.
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
En dat ze ook geen toegang tot de salts hebben.Door Anoniem:
Hopelijk zijn *alle* accounts gereset, dus ook de AD credentials.
Mogen de studenten dinsdag zelf doen lmao "https://www.nu.nl/tech/6118160/hackers-hva-en-uva-hadden-toegang-tot-wachtwoorden-van-studenten.html"Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
Hopelijk zijn *alle* accounts gereset, dus ook de AD credentials.
Als dit is gebeurd zal men de systemen niet meer kunnen vertrouwen.
Je weet niet exact wat de aanvallers hebben gecompromitteerd en eventueel achtergelaten.
Dus opnieuw opzetten.
Joris Goedbloed
Je weet niet exact wat de aanvallers hebben gecompromitteerd en eventueel achtergelaten.
Dus opnieuw opzetten.
Joris Goedbloed
Door Anoniem:
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
En dat ze ook geen toegang tot de salts hebben.geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Door Anoniem:
geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Door Anoniem:
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
En dat ze ook geen toegang tot de salts hebben.geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
En wanneer is een salt geen salt meer maar een pepper? Zodra deze per gebruiker in een andere database wordt opgeslagen/uitgelezen? Of pas zodra er 1 algemene reeks ergens in de code wordt opgehaald?
Zou dit graag willen weten!
Door Anoniem:
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
En wanneer is een salt geen salt meer maar een pepper? Zodra deze per gebruiker in een andere database wordt opgeslagen/uitgelezen? Of pas zodra er 1 algemene reeks ergens in de code wordt opgehaald?
Zou dit graag willen weten!
Door Anoniem:
geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Door Anoniem:
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
En dat ze ook geen toegang tot de salts hebben.geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
En wanneer is een salt geen salt meer maar een pepper? Zodra deze per gebruiker in een andere database wordt opgeslagen/uitgelezen? Of pas zodra er 1 algemene reeks ergens in de code wordt opgehaald?
Zou dit graag willen weten!
salts helpen tegen rainbow tables (voor uitgerekende hashes van wachtwoorden). check de wikipedia zelf maar.
Door Anoniem:
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
En wanneer is een salt geen salt meer maar een pepper? Zodra deze per gebruiker in een andere database wordt opgeslagen/uitgelezen? Of pas zodra er 1 algemene reeks ergens in de code wordt opgehaald?
Zou dit graag willen weten!
Door Anoniem:
geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Door Anoniem:
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
En dat ze ook geen toegang tot de salts hebben.geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
En wanneer is een salt geen salt meer maar een pepper? Zodra deze per gebruiker in een andere database wordt opgeslagen/uitgelezen? Of pas zodra er 1 algemene reeks ergens in de code wordt opgehaald?
Zou dit graag willen weten!
Een salt is er in essentie om aanvallen met rainbow tables tegen te gaan (https://nl.wikipedia.org/wiki/Rainbow_table). Met een salt is de kans nihil dat zelfs als je wachtwoord "password" is deze in de rainbow table staat. Wanneer deze salt per account verschillend is (wat je natuurlijk wel wil) zou de aanvaller dus per salt een nieuwe rainbow table moeten maken, wat mij niet erg efficiënt lijkt en een beetje de kracht van een dergelijke aanval mitigeert.
Een pepper is ook een vorm van salt, als in dat dit ook een extra input is voor hashing. Het verschil is inderdaad dat deze niet naast het wachtwoord wordt opgeslagen. Echter zijn hier ook verschillende vormen en implementaties van (net zoals een salt), denk bijvoorbeeld aan per account, of shared voor alle accounts. Het voordeel is, afhankelijk van hoe dit geïmplementeerd is uiteraard, dat het op zijn minst moeilijker is dan een standaard salt om deze pepper te achterhalen.
Door Anoniem:
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
Door Anoniem:
geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Door Anoniem:
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
En dat ze ook geen toegang tot de salts hebben.geen toegang tot salt => geen mogelijkheid de hash van een ww te controleren. salt wordt een onderdeel van het opgeslagen stukje info. waar jij over spreekt is 'pepper'.
Wat is het doel van een salt? Als je toegang hebt tot de hashes heb je waarschijnlijk ook toegang tot de salts. Als je er dan vanuit gaat dat de hash is berekend door hash(password.salt) of hash(salt.password) dan is dat toch niet veel anders dan hash(password)? Even aannemend dat je ook de manier weet waarop gehashed wordt.
Is het zo dat het juist alleen handig is omdat als je bijvoorbeeld 2x hetzelfde wachtwoord gebruikt waarbij de hashes verschillen je 2x het wachtwoord moet kraken of zijn er meer redenen?
Een salt heeft vooral meerwaarde om massa-password kraken moeilijker te maken.
Verder maakt het 'rainbow tables' lastig/onmogelijk. Rainbow tables zijn vooraf berekende hashes van veel gebruikte passwords . Dan hoef je alleen maar te vergelijken .
Met een salt van behoorlijke lengte worden tables van 'bekende' passwords (secret,123456 etc) tig keer zo lang .
Verder , als je probeert een heel bestand van passwords te kraken (maakt niet uit welke), kun je bij een salt-loze versie gewoon elke hash die je maakt (geheim, 123456, aaaaa aaaab aaaac ... zzzzzz) vergelijken met de hele file .
Als er wel salts gebruikt zijn, moet je feitelijk al je pogingen op ieder account opnieuw doen.
een 'pepper' is een geheim salt .
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem:
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
Door Anoniem:
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
Door Anoniem:
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
Door Anoniem:
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
Door Anoniem:
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
Door Anoniem:
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
Door Anoniem:
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
Door Anoniem:
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
Door Anoniem:
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
Door Anoniem:
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
nope teken space is veel belangrijker, bekijk het verschil tussen 26^8 en 52^8; beiden 8 tekens maar veel meer entropy in 2e situatie want 52^8=(26^2)^8=26^16. dus 26^8 komt overeen met case insenstive alphabet, 52^8 met case sensitive alphabet.
Door Anoniem:
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
Door Anoniem:
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
Door Anoniem:
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
Door Anoniem:
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
sha512 (std tegenwoordig) heeft en salt van 16 tekens. dat is veel meer dan 12 bits.
Door Anoniem:
nope teken space is veel belangrijker, bekijk het verschil tussen 26^8 en 52^8; beiden 8 tekens maar veel meer entropy in 2e situatie want 52^8=(26^2)^8=26^16. dus 26^8 komt overeen met case insenstive alphabet, 52^8 met case sensitive alphabet.
Door Anoniem:
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
Door Anoniem:
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
Door Anoniem:
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
Door Anoniem:
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Door Anoniem: Hopelijk een sterke salt er overheen gehaald.
salt is een random reeks, daar is verder niets sterks of zwaks aan...
https://en.wikipedia.org/wiki/Salt_(cryptography)
nog beter:
https://en.wikipedia.org/wiki/Pepper_(cryptography)
Een salt kan wel degelijk sterk of zwak zijn maar dat had je zelf ook kunnen lezen in je eigen aangehaalde artikel.
If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
Dat is wat ik bedoel met een sterke salt.
lengte != sterkte in cryptografie. het gaat vaak eerder om de entropy.
De lengte geeft natuurlijk een bovengrens aan de entropie en sterkte.
En de salt wordt door het systeem gekozen , niet de gebruiker, en zal normaal gesproken random gekozen zijn. Dan is de lengte ook precies de maat voor de entropie.
De klassieke Unix crypt(3) password salt is 12 bits - tegenwoordig toch wel een beetje te kort .
nope teken space is veel belangrijker, bekijk het verschil tussen 26^8 en 52^8; beiden 8 tekens maar veel meer entropy in 2e situatie want 52^8=(26^2)^8=26^16. dus 26^8 komt overeen met case insenstive alphabet, 52^8 met case sensitive alphabet.
Op welk statement slaat je 'nope' ?
Een 12-bit salt *is* een beetje kort - en dat heeft helemaal niks met een subset van een ascii tekens te maken.
Je opmerking over de toegestane alfabetten is alleen relevant voor invoervelden.
De lengte van een salt wordt gangbaar uitgedrukt in bits - omdat een salt over het algemeen ergens door een password library gekozen wordt , is het niet gebonden aan de typische invoer-velden beperkingen die de tekenruimte (alfabet is de gangbare term) beperken .
12 bits lang is 12 bits informatie . Hoe lang dat wordt in de een of andere opslag encoding de printable ascii wil gebruiken maakt niet uit. Een salt van 12 bits maakt een rainbow table 4096 keer groter . Dit is niet zo onoverkomelijk meer .
En een account database met 100.000 accounts zal vaak salts delen , en daarbij het zoeken wat makkelijker maken.
Dat is waarom een 12-bit salt 'een beetje kort' is tegenwoordig.
Evenzeer druk je de (output) lengte van een hash uit in bits.
Dat die vaak niet binair wordt opgeslagen, maar als een base-64 encoded string maakt niet meer , en is irrelevant voor 'hash lengte' .
Het toegestane alfabet in invoer is alleen relevant om met een beperkter aantal posities de maximale lengte van de achterliggende hash functie te kunnen benutten.
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.
