http://www.nu.nl/internet(...)sen-heeft-spijt.htmlquote:Bill Burr, een voormalig Amerikaans overheidsmedewerker die in 2003 een set strenge eisen voor computerwachtwoorden opstelde, zegt dat hij spijt heeft van zijn invloedrijke werk.
Burr stelde voor het National Institute of Standards and Technology (NIST) een advies op, waarin hij mensen onder meer opriep om veel getallen en speciale tekens te gebruiken in wachtwoorden, en om deze regelmatig te veranderen.
De standaarden van NIST hebben veel invloed binnen de Amerikaanse overheid en in de privésector. Door het eerdere document van Burr was het bij veel agentschappen en bedrijven verplicht om regelmatig alle wachtwoorden te vervangen en tekencombinaties te gebruiken die moeilijk te onthouden zijn.
"Ik heb nu spijt van veel van wat ik heb gedaan", zegt de 72-jarige Burr dinsdag tegen de Wall Street Journal. In juni stelde NIST een nieuwe versie van zijn advies op, waarin grote veranderingen werden doorgevoerd.
Onthouden
In de praktijk blijkt dat veel mensen bij verplichte wachtwoordwijzigingen slechts kleine aanpassingen maken, door bijvoorbeeld één cijfer te wijzigen. Ook leidden de eisen ertoe dat veel mensen makkelijk te raden wachtwoorden als 'W4chtw00rd!' gebruiken.
Volgens experts is het beter om een lang, maar makkelijk te onthouden wachtwoord te gebruiken, dan een korter en ingewikkelder wachtwoord. Een wachtwoord dat bestaat uit vier willekeurige woorden achter elkaar is bijvoorbeeld moeilijk te kraken.
"Het was uiteindelijk waarschijnlijk te ingewikkeld voor veel mensen om goed te begrijpen, en eerlijk gezegd had ik een verkeerde aanpak", zegt Burr nu over zijn advies. "Mensen worden er gek van en ze kiezen toch geen goede wachtwoorden, wat je ook doet."
Uw wachtwoord moet minstens 8 en maximaal 16 tekens bevatten.
Uw nieuwe wachtwoord moet minimaal het volgende bevatten:
- 1 hoofdletter
- 1 kleine letter
- 1 cijfer
- 1 speciaal teken
D0nd%r toch snel op
Een wachtwoord als "konijn wortel doperwt groen" is beter dan welk wachtwoord met speciale tekens en cijfers dan ook.
Gelukkig is deze man tot inkeer gekomen. Maar helaas is het kwaad al geschied.
quote:
En waarom men dan het idee heeft dat de meerderheid iets anders zou doen dan één cijfer of één letter veranderen.quote:Op dinsdag 8 augustus 2017 16:30 schreef MichaelScott het volgende:
Begreep sowieso al nooit waarom je elke maand je wachtwoord zou moeten veranderen.
Dat is wel goed voor mensen die overal dezelfde combinatie van e-mail adres en wachtwoord gebruiken.quote:
Begreep sowieso al nooit waarom je elke maand je wachtwoord zou moeten veranderen.
Dat is bij ons uitgeschakeld, als je iets neemt wat er te veel op lijkt word het afgekeurt.quote:Op dinsdag 8 augustus 2017 16:36 schreef Janneke141 het volgende:
[..]
En waarom men dan het idee heeft dat de meerderheid iets anders zou doen dan één cijfer of één letter veranderen.
Bij ons is ook policy om zoveel mogelijk software en systemen via je windows credentials te laten lopen, als iemand uit dienst gaat is gelijk in 1 keer alles geregeld.
Net als alle anderen die tegelijkertijd met jou startten.quote:
Bij het bedrijf waar ik werkt krijgt iedereen bij binnenkomst het wachtwoord Welcome01 en je moet dan iedere drie maanden een nieuw wachtwoord kiezen. Mijn wachtwoord is nu Welcome17
Haha. Ja. Als je weet hoe lang iemand bij de baas zit kun je zijn wachtwoord vaak wel raden. Gemakkelijk als iemand ziek tthuis is.quote:
[..]
Net als alle anderen die tegelijkertijd met jou startten.
Daarom is het ook zo mega-irritant als mensen op eigen initiatief in het systeem gaan kloten. Met Nederlandse wachtwoorden zoals Welkom01 of met de hoofdletter op de foute plaats.
Dat kan in principe niet. Of je moet de wachtwoorden als plain tekst (via 1 of andere encryptie eventueel) opslaan. Bij de echte systemen wordt alleen de hashcode opgeslagen. En die hashcode is heel erg anders, ook bij 1 teken verschil. Voor de systemen en en hackers maakt het allemaal niet zoveel uit. Het is het uitproberen van hashcodes. Dat moet op ieder systeem beperkt worden tot maximaal 4 keer fout en daarna een uur pauze. Zo ben je veilig tegen automaten.quote:
[..]
Dat is bij ons uitgeschakeld, als je iets neemt wat er te veel op lijkt word het afgekeurt.
Bij ons is ook policy om zoveel mogelijk software en systemen via je windows credentials te laten lopen, als iemand uit dienst gaat is gelijk in 1 keer alles geregeld.
Idem. Alleen met iets anders ervoor Ik begon op 2008 en zit nu op 2029.quote:
Bij het bedrijf waar ik werkt krijgt iedereen bij binnenkomst het wachtwoord Welcome01 en je moet dan iedere drie maanden een nieuw wachtwoord kiezen. Mijn wachtwoord is nu Welcome17
Dit is spot on inderdaad. Het is mooi dat de man die dit bedacht heeft nu spijt heeft. Voortschrijdend inzicht is altijd iets erg moois vind ik.quote:
Zoals gezegd: als het systeem die punten allemaal kan controleren dat is het inherent onveilig omdat de echte wachtwoorden ergens opgeslagen worden. Zeg dat maar tegen je school.quote:
Het is wel duidelijk dat "de mens" maar ook degenen die het implementeren bijzonder weinig snappen van het metier.
Tot het wachtwoord van deze manager aan de beurt is. Dan heb je ze allemaal in 1 keer. Slecht idee.quote:
Ik laat altijd een ww genereren en onthouden door een wachtwoordmanager. Werkt ideaal, nooit omkijken naar.
Nu je het zegt; terechte klacht. Gelukkig zit ik er niet meer.quote:
[..]
Zoals gezegd: als het systeem die punten allemaal kan controleren dat is het inherent onveilig omdat de echte wachtwoorden ergens opgeslagen worden. Zeg dat maar tegen je school.
Terwijl dat een stukje combinatoriek is dat een leerling uit 3-vwo ook voor je uit had kunnen rekenen.quote:
Eigenlijk zegt het plaatje in post #2 alles. De rest van hoe wij erover denken is op misverstand gebaseerd.
Vooral punt 3 is heel kwalijk. Het mag niet langer zijn dan 13 tekens. Dat is werkelijk nergens op gebaseerd. Zij dachten daar duidelijk: als we maar heel veel regels verzinnen dan is het wachtwoord automagisch veilig. Dat idee klopt niet. Sterker nog: het is volkomen fout. Je moet niet denken als een mens als je de regels bedenkt.quote:
[..]
Nu je het zegt; terechte klacht. Gelukkig zit ik er niet meer.
Zeer zeker. Toch wordt er op de afdelingen die het beleid voorschrijven gedacht zoals in het bovenste deel van de strip. Dat is juist zo kwalijk. Je krijgt dan dat soort regels als: max. 13 tekens. Niemand weet waarom...quote:
[..]
Terwijl dat een stukje combinatoriek is dat een leerling uit 3-vwo ook voor je uit had kunnen rekenen.
Helemaal mee eens.quote:
[..]
Vooral punt 3 is heel kwalijk. Het mag niet langer zijn dan 13 tekens. Dat is werkelijk nergens op gebaseerd. Zij dachten daar duidelijk: als we maar heel veel regels verzinnen dan is het wachtwoord automagisch veilig. Dat idee klopt niet. Sterker nog: het is volkomen fout. Je moet niet denken als een mens als je de regels bedenkt.
Ze zouden die wachtwoordwissel eigenlijk op jaarbasis moetne doen, dan wist je altijd je wachtwoord!quote:
[..]
Idem. Alleen met iets anders ervoor Ik begon op 2008 en zit nu op 2029.
Ik wilde net aangeven dat dat belachelijk is. Veel van mijn wachtwoorden zijn langer dan 13 tekens.quote:
[..]
Vooral punt 3 is heel kwalijk. Het mag niet langer zijn dan 13 tekens. Dat is werkelijk nergens op gebaseerd. Zij dachten daar duidelijk: als we maar heel veel regels verzinnen dan is het wachtwoord automagisch veilig. Dat idee klopt niet. Sterker nog: het is volkomen fout. Je moet niet denken als een mens als je de regels bedenkt.
In het algemeen: de "geheugenkunstenaars" werken volgens het principe in het onderste deel van de strip in #2. Als een wachtwoord makkelijk te onthouden is kun je dat voor veel wachtwoorden. Je moet een kleine hint naar het onderwerp van dienst doen: de site. Dat kan meestal niet in 13 tekens.quote:Op dinsdag 8 augustus 2017 18:25 schreef Morrigan het volgende:
[..]
Ik wilde net aangeven dat dat belachelijk is. Veel van mijn wachtwoorden zijn langer dan 13 tekens.
Het gaat er vooral om wat makkelijk te onthouden is. Want voor de systemen is het allemaal een 512 bits, 1024 bits, 2048 bits hashcode. Ook al is het wachtwoord 17 kantjes A4. De wachtwoorden gezien vanuit het systeem en vanuit de mens zijn heel verschillend.
AutomaTischquote:
[..]
Vooral punt 3 is heel kwalijk. Het mag niet langer zijn dan 13 tekens. Dat is werkelijk nergens op gebaseerd. Zij dachten daar duidelijk: als we maar heel veel regels verzinnen dan is het wachtwoord automagisch veilig. Dat idee klopt niet. Sterker nog: het is volkomen fout. Je moet niet denken als een mens als je de regels bedenkt.
Ik heb die vreemde variant al eens een keer gezien hier, dat was toch jij niet?
waaronder geen matchende tekens direct achter elkaar oftewel geen
Aa
22
o.i.d.
Dat is pas kut.
Volgend jaar: Uw wachtwoord moet een ingewikkelde natuurkundige formule bevatten.quote:
Dan kiest iedereen E=mc2 want simpel.quote:Op dinsdag 8 augustus 2017 19:00 schreef Eyjafjallajoekull het volgende:
[..]
Volgend jaar: Uw wachtwoord moet een ingewikkelde natuurkundige formule bevatten.
die hebben 2faquote:
[..]
Tot het wachtwoord van deze manager aan de beurt is. Dan heb je ze allemaal in 1 keer. Slecht idee.
Accuratequote:
Dat maakt niet zoveel uit. De lengte in bits van de hashcode maakt het moeilijk te raden. 1 bit meer is meteen een factor 2. Maar daar gaat het natuurlijk niet om. Als e.e.a. uitlekt of geraden wordt door een bekende. Dan is het mis. Want dat betreft dan al je wachtwoorden. En het is ook nog mogelijk dat er in de software die deze dingen mogelijk maakt een backdoortje zit die gewoon beschikbaar is via "Welkom123" en dan alle hashcodes verklapt.quote:
In het algemeen zijn dit soort dingen uitgevonden voor de mens opdat hij al zijn wachtwoorden mag vergeten omdat software dit voor hem regelt. In principe is zo'n systeem inherent onveiliger dan dat je ze zelf apart zou onthouden. Alleen kan een mens dat niet.
Het is een masterkey van de kluis. En als iemand die heeft kan hij de hele kluis leegroven. Dat is anders dan dat hij alleen je wachtwoord voor feestboek krijgt.
[ Bericht 4% gewijzigd door Bart2002 op 08-08-2017 20:46:21 ]
Daar gaat het al fout. Ze worden geacht om in jouw hoofd opgeslagen te zijn. Wat kansloos is, dat weten we allemaal.quote:
Ik heb Gvd een schrift om al die ww bij te houden.
Dit inderdaad. Zoals je hierboven zag, die 34 regels waar een acceptabel wachtwoord aan dient te voldoen.... Voor de site van een school godbetert. Het is wel over the top allemaal.quote:
Het allerergste is nog wanneer je zo'n heel ingewikkeld wachtwoord moet invoeren bij een volstrekt irrelevante site, dus de website van school of van een krant om te kunnen reageren. Als iemand dat wachtwoord al zou willen kraken maakt dat nog niet zoveel uit.
Automagisch FTW!!!!!11EINZ!quote:Op dinsdag 8 augustus 2017 18:44 schreef Hdero het volgende:
[..]
AutomaTisch
Ik heb die vreemde variant al eens een keer gezien hier, dat was toch jij niet?
Ik vond het vorige plaatje van je beter. Dat was volgens mij een leuke cynische Engelsman. Dat kwam helemaal overeen met het commentaar wat je doorgaans geeft.quote:Op dinsdag 8 augustus 2017 20:47 schreef nogeenoudebekende het volgende:
[..]
Automagisch FTW!!!!!11EINZ!
Het is ook maar net hoe je het bewaart. Je kunt heus wel wachtwoorden opslaan op je computer zonder dat andere kunnen zien dat het om wachtwoorden gaat. Niet allemaal uiteraard. De belangrijke onthoud je dan.quote:
[..]
Daar gaat het al fout. Ze worden geacht om in jouw hoofd opgeslagen te zijn. Wat kansloos is, dat weten we allemaal.
Buiten dat het over de top is maakt het het brute force kraken ook simpeler. Je kunt al een hoop combinaties uitsluiten.quote:
[..]
Dit inderdaad. Zoals je hierboven zag, die 34 regels waar een acceptabel wachtwoord aan dient te voldoen.... Voor de site van een school godbetert. Het is wel over the top allemaal.
Onzin. Je genoemde wachtwoord heeft helemaal niet zoveel entropie, vooral omdat je gerelateerde worden gebruikt. Een random string van 10+ karakters is waarschijnlijk veiliger dan dat. Als je deze methode wel wil gebruiken moet je echt random worden kiezen. Verder wordt tegenwoordig 6+ worden aangereden.quote:
[..]
http://www.nu.nl/internet(...)sen-heeft-spijt.html
Uw wachtwoord moet minstens 8 en maximaal 16 tekens bevatten.
Uw nieuwe wachtwoord moet minimaal het volgende bevatten:
- 1 hoofdletter
- 1 kleine letter
- 1 cijfer
- 1 speciaal teken
D0nd%r toch snel op
Een wachtwoord als "konijn wortel doperwt groen" is beter dan welk wachtwoord met speciale tekens en cijfers dan ook.
Gelukkig is deze man tot inkeer gekomen. Maar helaas is het kwaad al geschied.
Beste optie is toch echt de password manager. Dat is dan de zwakke plek, maar anders ga je zeker wachtwoorden gebruiken en ben je de Sjaak als van een van deze sites de wachtwoorden lekken. Toch een stuk groter risico.
Verder gewoon two factor authenticatie gebruiken voor belangrijke zaken.
Herkenbaar.quote:
Bij het bedrijf waar ik werkt krijgt iedereen bij binnenkomst het wachtwoord Welcome01 en je moet dan iedere drie maanden een nieuw wachtwoord kiezen. Mijn wachtwoord is nu Welcome17
linux gebruiker?quote:
[..]
Dat maakt niet zoveel uit. De lengte in bits van de hashcode maakt het moeilijk te raden. 1 bit meer is meteen een factor 2. Maar daar gaat het natuurlijk niet om. Als e.e.a. uitlekt of geraden wordt door een bekende. Dan is het mis. Want dat betreft dan al je wachtwoorden. En het is ook nog mogelijk dat er in de software die deze dingen mogelijk maakt een backdoortje zit die gewoon beschikbaar is via "Welkom123" en dan alle hashcodes verklapt.
In het algemeen zijn dit soort dingen uitgevonden voor de mens opdat hij al zijn wachtwoorden mag vergeten omdat software dit voor hem regelt. In principe is zo'n systeem inherent onveiliger dan dat je ze zelf apart zou onthouden. Alleen kan een mens dat niet.
Het is een masterkey van de kluis. En als iemand die heeft kan hij de hele kluis leegroven. Dat is anders dan dat hij alleen je wachtwoord voor feestboek krijgt.
een hash is toch altijd even lang?
ik bedoel die managers gebruiken dan wel één wachtwoord om toegang te krijgen tot de rest, met 2fa ingeschakeld heb je niks aan alleen het wachtwoord. dan denk ik aan lastpass.
Inderdaad. En de rest van wat je schrijft ook. Jouw post schetst precies het misverstand wat er leeft en wat leading is. "Random" (zeer moeilijk te onthouden voor een mens) maakt voor de computer geen enkel verschil. Zie het plaatje in post 2 over "entropie". Men gebruikt dat vaak maar snapt niet precies wat het eigenlijk is.quote:
Ja. Hier gaan we de essentie raken van hoe het werkt. Ze zijn even lang. En ze zijn bijzonder random. Zelfs als je bijna hetzelfde wachtwoord als input hebt. Door de lengte qua hoeveelheid bits zijn ze in principe niet automatisch te kraken. Als je tenminste een limiet zet op het aantal pogingen en de pauze daarna.quote:
De discussie over het wachtwoordgebeuren gaat m.i. over heel iets anders: hoe zijn zij voor de mens te handelen.... De systemen zijn perfect als ze voldoen aan het pauzegebeuren. Het echte probleem zetelt dus in de mens. Men zou het moeten hebben over hoe het voor de mens handelbaar en tevens veilig is. En dat gaat niet met die gibberish wachtwoorden.
Een eerste vereiste voor dit alles is: je moet de bitlengte groot maken. Als al je wachtwoorden worden omgezet naar een hashcode van 16 bits dan raad je alles binnen een seconde. Het kan ook zonder hashcode maar dan moet je een wachtwoord als plain-tekst opslaan. Wat veel beter is dan een hashcode omdat de lengte van het wachtwoord dan altijd in het voordeel werkt. Hoe langer hoe beter. Maar dat heeft dus voor de hand liggende nadelen.
Al met al is een wachtwoord een magisch getal. Voorkennis helpt hier veel. En mensen gebruiken voor alles overal hetzelfde wachtwoord. Dat maakt dat als je het weet voor een random site (dat gaat vaak toevallig) dat je het dan weet voor alles. Het probleem van een wachtwoord is niet hoe computers dit kunnen kraken maar hoe anderen er achter kunnen komen.
[ Bericht 6% gewijzigd door Bart2002 op 08-08-2017 23:14:44 ]
Dat hoeft niet perse. Bij het wijzigen van je wachtwoord moet je vaak je huidige wachtwoord opgeven, dan kun je het nieuwe wachtwoord wel met die plaintext vergelijken zonder dat het moet worden opgeslagen.quote:
[..]
Dat kan in principe niet. Of je moet de wachtwoorden als plain tekst (via 1 of andere encryptie eventueel) opslaan.
Ook dat valt mee. De enige eis die terug gaat naar vorige wachtwoorden is dat ze niet eerder gebruikt mogen zijn en dat kun je ook bereiken door de hashes van alle gebruikte wachtwoorden te bewaren.quote:
[..]
Zoals gezegd: als het systeem die punten allemaal kan controleren dat is het inherent onveilig omdat de echte wachtwoorden ergens opgeslagen worden. Zeg dat maar tegen je school.
Waarmee ik absoluut niet wil zeggen dat deze eisen 'goed' zijn, of dat het daadwerkelijk op deze manier gedaan wordt, uiteraard.
Geen idee wat dit met het topic te maken heeft, maar ik heb me wel de lul uit de broek gelachen.quote:
Ik ga dat zo ook maar even kijken dan. Is het werkelijk zo grappig?quote:Op dinsdag 8 augustus 2017 23:16 schreef Treinhomo het volgende:
[..]
Geen idee wat dit met het topic te maken heeft, maar ik heb me wel de lul uit de broek gelachen.
Inderdaad. Dat is het gevaar van internet. In principe werkt een goed systeem zo dat het teken voor teken een hashcode bouwt. Dus met ieder teken wat je typt. Dat kan niet online. Dus de hele string wordt verstuurd en daar ga je al. Dingen van internet werken zo dat je die 2 invoerboxen met elkaar kunt vergelijken. En dat is al heel fout en inherent zwaar onveilig.quote:
Dat hoeft niet perse. Bij het wijzigen van je wachtwoord moet je vaak je huidige wachtwoord opgeven, dan kun je het nieuwe wachtwoord wel met die plaintext vergelijken zonder dat het moet worden opgeslagen.
Oeh; da's een gewetensvraag.quote:Op dinsdag 8 augustus 2017 23:17 schreef Bart2002 het volgende:
Ik ga dat zo ook maar even kijken dan. Is het werkelijk zo grappig?
(Wan)smaak is wel zó persoonlijk.
Hij heet (ook) Bill Burr (eerste zin vd OP)quote:
[..]
Geen idee wat dit met het topic te maken heeft, maar ik heb me wel de lul uit de broek gelachen.
Ja, dat is waar. Als ik moest lachen meld ik dat zo wel. Blijft het stil: trek dan je conclusie.quote:
[..]
Oeh; da's een gewetensvraag.
(Wan)smaak is wel zó persoonlijk.
Als je je data via POST over HTTPS verstuurt is dat gewoon prima veilig. Client Side hashing is niet veiliger. Zie bijv. https://security.stackexc(...)-password-over-httpsquote:
[..]
Inderdaad. Dat is het gevaar van internet. In principe werkt een goed systeem zo dat het teken voor teken een hashcode bouwt. Dus met ieder teken wat je typt. Dat kan niet online. Dus de hele string wordt verstuurd en daar ga je al. Dingen van internet werken zo dat je die 2 invoerboxen met elkaar kunt vergelijken. En dat is al heel fout en inherent zwaar onveilig.
Overigens zou je zelfs in dat systeem clientside de twee uiteindelijke hashes met elkaar kunnen vergelijken, dus ook daar hoeft een 'uw wachtwoord mag niet gelijk zijn aan uw vorige wachtwoord' melding niet direct op een onveilig systeem te duiden
Dat door en door en door doordraven over hetzelfde vind ik leuk. Wim Kan kon dat ook zo superieur. Het is ook heel herkenbaar: ik was aan het koken geweest en daar hoorde een rooster ovenfriet bij. Op 225 graden uit de oven. De vrouw ging e.e.a. opscheppen, dingen van pannen enzo. Dat rooster stond toen op het aanrecht en zij verbrande haar hand toen ze daar per ongeluk tegenaan kwam.quote:
[..]
Oeh; da's een gewetensvraag.
(Wan)smaak is wel zó persoonlijk.
En toen kreeg ik de schuld dat ik haar niet verteld had dat dat rooster heet was... Toen heb ik haar ook even goed met het hoofd tegen het aanrecht gebeukt natuurlijk. Maar dat moet binnenshuis blijven want mensen vinden zoiets dan "raar". Lastige vragen worden dan gesteld. Waar je natuurlijk niet op staat te wachten. Dus er is wel "reason", vandaar een goed clipje. Maar context is altijd nodig om niet de gebeten hond te zijn als man zijnde.
Nee. Hashes kun je niet vergelijken. Als je gehakt ziet dan kun je niet meer zien van welk varken dat afkomstig is. Ook kun je van dat gehakt geen varken meer maken. Dat is nou juist de kracht van het hash-algoritme. Het is een slecht begrepen fenomeen. Zie het als een vleesmolen. Je kunt enkel vergelijken of ze hetzelfde zijn. En dan is de input ook hetzelfde. Is de input 1 teken anders dan kun je ze niet vergelijken. Je kunt dus niet controleren of het wachtwoord "Welkom123" lijkt op wachtwoord "Welkom124".quote:
Overigens zou je zelfs in dat systeem clientside de twee uiteindelijke hashes met elkaar kunnen vergelijken
Als dat wel kan dan doet het iets met plain tekst en de hele string. En dat moet je niet doen. Je sluit dan alles uit wat nou juist de bedoeling is met veiligheid.
Dus die 3 tekstvakken met "oude wachtwoord", "nieuwe wachtwoord", "nogmaals nieuwe wachtwoord" en als ze daar dan iets van vinden behalve of het oude wachtwoord niet klopt en/of de 2 nieuwe wachtwoorden niet hetzelfde zijn zijn inherent onveilig. Zij doen dan iets op de client wat betekent dat zij alle invoerstrings weten of ze versturen dat gewoon naar de server. Het eerste is wat minder problematisch dan het laatste maar het is beide niet goed.
[ Bericht 7% gewijzigd door Bart2002 op 09-08-2017 00:26:54 ]
is dat een zekere verzekeraar?quote:
Bij het bedrijf waar ik werkt krijgt iedereen bij binnenkomst het wachtwoord Welcome01 en je moet dan iedere drie maanden een nieuw wachtwoord kiezen. Mijn wachtwoord is nu Welcome17
Nee.quote:
Op Nee, je begrijpt de XKCD strip niet. Het er wachtwoord daarin is ook niet random, maar een woord met wat gehusselde letters. Daarom is dat zo onveilig. Als het daadwerkelijk een random string van tien tekens was was het een stuk veiliger geweest.quote:
[..]
Inderdaad. En de rest van wat je schrijft ook. Jouw post schetst precies het misverstand wat er leeft en wat leading is. "Random" (zeer moeilijk te onthouden voor een mens) maakt voor de computer geen enkel verschil. Zie het plaatje in post 2 over "entropie". Men gebruikt dat vaak maar snapt niet precies wat het eigenlijk is.
Je beeld van een aanval is ook niet correct. Het grootste gevaar dat veel mensen lopen is dat de wachtwoord hashes van een populaire service worden gelekt en hier een dictionary aanval op wordt uitgevoerd. Zelfs als er een random salt wordt gebruikt kan dan behoorlijk wat worden achterhaald omdat zo'n aanval met een paar miljard pogingen per seconde worden gedaan. Vervolgens kunnen de achterhaalde wachtwoorden vaak worden gebruikt om op andere systemen in te loggen aangezien de meeste mensen wachtwoorden hergebruiken.
Verder is het versturen van plain text wachtwoorden over een goed versleutelde HTTPS verbinding in de basis veilig. En plain text aan cliënt side ook. De enige realistische manier om dit te kraken is door directe toegang te hebben tot de cliënt zelf en dan helpt een of ander vaag systeem als hashen per teken ook niet meer.
Ja, dus je kunt prima vergelijken of het oude en nieuwe wachtwoord hetzelfde zijn. En als je de wachtwoorden aan de server-kant hashed in plaats van aan de client (wat zoals hierboven ook staat en ik in mijn vorige post naar linkte prima veilig is) kun je dat ook doen met oudere wachtwoorden.quote:
[..]
Nee. Hashes kun je niet vergelijken. Als je gehakt ziet dan kun je niet meer zien van welk varken dat afkomstig is. Ook kun je van dat gehakt geen varken meer maken. Dat is nou juist de kracht van het hash-algoritme. Het is een slecht begrepen fenomeen. Zie het als een vleesmolen. Je kunt enkel vergelijken of ze hetzelfde zijn.
Nogmaals, ik zeg niet dat je dit moet afdwingen of opslaan op deze manier. Maar een controle op een ouder wachtwoord, of oudere wachtwoorden, duidt niet perse direct op een veiligheidsprobleem in de implementatie.
Nee hoor, dat is wel op slimmere manieren te doen, bijvoorbeeld door ook een footprint op te slaan van een wachtwoord structuur.quote:
[..]
Dat kan in principe niet. Of je moet de wachtwoorden als plain tekst (via 1 of andere encryptie eventueel) opslaan. Bij de echte systemen wordt alleen de hashcode opgeslagen. En die hashcode is heel erg anders, ook bij 1 teken verschil. Voor de systemen en en hackers maakt het allemaal niet zoveel uit. Het is het uitproberen van hashcodes. Dat moet op ieder systeem beperkt worden tot maximaal 4 keer fout en daarna een uur pauze. Zo ben je veilig tegen automaten.
Jij ook niet echt, wat je roept is simpelweg niet waar, overigens is het flauwekul om dit soort beperkingen op te leggen.quote:
[..]
Zoals gezegd: als het systeem die punten allemaal kan controleren dat is het inherent onveilig omdat de echte wachtwoorden ergens opgeslagen worden. Zeg dat maar tegen je school.
Het is wel duidelijk dat "de mens" maar ook degenen die het implementeren bijzonder weinig snappen van het metier.
O boy. Maar ik hou erover op. Iedereen heeft blijkbaar een particuliere mening over dit soort zaken. Het kan op vele manieren en die zijn allemaal goed lijkt men te denken.quote:
[..]
Nee hoor, dat is wel op slimmere manieren te doen, bijvoorbeeld door ook een footprint op te slaan van een wachtwoord structuur.
Dit deel heb ik geen ervaring mee. Zou zo'n footprint geen extra aanvalsvector zijn bij het kraken van hashes? Hoe doe je zoiets zonder het aantal mogelijke wachtwoorden dat de gebruiker nu heeft enorm te beperken?quote:
[..]
Nee hoor, dat is wel op slimmere manieren te doen, bijvoorbeeld door ook een footprint op te slaan van een wachtwoord structuur.
Of als je enkel footprints voor eerdere wachtwoorden op en voeg je er één toe voor het oude wachtwoord als je deze wijzigt?
Joh, ik implementeer en beheer ruim 20 jaar websites, ik maak security audits van banken mee, ik weet echt wel waar ik het over heb.quote:
[..]
O boy. Maar ik hou erover op. Iedereen heeft blijkbaar een particuliere mening over dit soort zaken. Het kan op vele manieren en die zijn allemaal goed lijkt men te denken.
Als je beide zou kunnen bemachtigen zal dat ongetwijfeld een verhoging van de kansen geven, je zult dus een afweging moeten maken. Echter qua security zijn er meestal een hoop andere zaken die minder aandacht krijgen.quote:
[..]
Dit deel heb ik geen ervaring mee. Zou zo'n footprint geen extra aanvalsvector zijn bij het kraken van hashes? Hoe doe je zoiets zonder het aantal mogelijke wachtwoorden dat de gebruiker nu heeft enorm te beperken?
Of als je enkel footprints voor eerdere wachtwoorden op en voeg je er één toe voor het oude wachtwoord als je deze wijzigt?
https://www.quora.com/How(...)Graw-Herdeg?srid=Itv
Moraal van het verhaal: wantrouw *sommige* experts (nee, ik heb niets tegen vaccinaties, maar klimaatwetenschappers die het voor the childrun doen wantrouw ik met verve), vooral als je theewater zegt dat het ook anders kan.quote:
Gelukkig is deze man tot inkeer gekomen. Maar helaas is het kwaad al geschied.
quote:
Ik heb er even naar gezocht, maar het brengt geen extra risicos's mee, hier een uitstekende uitleg:
https://www.quora.com/How(...)Graw-Herdeg?srid=Itv
En dat kan dus niet. Zoals gezegd je kunt hashcode's niet met elkaar vergelijken en daar een bepaalde conclusie uit trekken behalve dat ze hetzelfde zijn of niet. Als dat wel kon dan moet je ze vermijden want ze zijn dan immers onveilig.quote:e.g. comparing a hash of this string against the stored hash of your current password
B.v. (vereenvoudigd voorbeeld van de hashcodes van 2 strings):
100011101010001111010001 (wachtwoord 1)
001100101110010110000110 (wachtwoord 2)
Welke conclusies kun je allemaal trekken? Lijkt wachtwoord 1 (Welkom123) op wachtwoord 2 (Welkom124)?
Ik heb het idee dat ik wat anders bedoel dan de anderen hier. Of dat men niet precies snapt wat een hashcode is en hoe die tot stand komt.
@Steenkool: van hashcodes en alles rondom het thema heb ik wel veel verstand hoor.
En voor de goede orde: je kunt uit bovenstaande 2 code's het origineel NIET herleiden. En is het dus onmogelijk te bepalen of de 2 op elkaar lijken of hetzelfde "thema" hebben. Zo werkt dat. Ik zal het topic t.z.t. nog eens goed lezen want ik heb het idee dat "men" (ook ik) langs elkaar heen praten.
[ Bericht 3% gewijzigd door Bart2002 op 09-08-2017 10:40:52 ]
Je versimpelt het daar voorgestelde systeem door maar een deel van de zin te citeren. Wat ze voorstellen is het volgende:quote:
[..]
[..]
En dat kan dus niet. Zoals gezegd je kunt hashcode's niet met elkaar vergelijken en daar een bepaalde conclusie uit trekken behalve dat ze hetzelfde zijn of niet. Als dat wel kon dan moet je ze vermijden want ze zijn dan immers onveilig.
B.v. (vereenvoudigd voorbeeld van de hashcodes van 2 strings):
100011101010001111010001 (wachtwoord 1)
001100101110010110000110 (wachtwoord 2)
Welke conclusies kun je allemaal trekken? Lijkt wachtwoord 1 (Welkom123) op wachtwoord 2 (Welkom124)?
Gegeven nieuw wachtwoord 'welkom12' genereren zij hashcodes voor alle wachtwoorden die ze op het nieuwe wachtwoord vinden lijken (bijvoorbeeld 'welkom1', 'welkom11' en 'welkom13'). Als één van die hashes exact lijkt op de hash van het oude wachtwoord ('welkom11') wordt het wachtwoord aangemerkt als 'te gelijkend'.
Zeker. Dat denkt men. Maar zo werkt het niet. Je krijgt geen "gelijkende" (hoe moet ik dat zien overigens?) hashcodes door woorden die op elkaar lijken te coderen. Laat staan precies dezelfde code. Dat is nou juist mijn betoog. Dit is de kracht van hashcodering: je kunt er volstrekt niets uit afleiden en al helemaal niet hoe hij tot stand is gekomen. Als dat wel kon dan was de methodiek onveilig. En dat is ie niet.quote:
[..]
Je versimpelt het daar voorgestelde systeem door maar een deel van de zin te citeren. Wat ze voorstellen is het volgende:
Gegeven nieuw wachtwoord 'welkom12' genereren zij hashcodes voor alle wachtwoorden die ze op het nieuwe wachtwoord vinden lijken (bijvoorbeeld 'welkom1', 'welkom11' en 'welkom13'). Als één van die hashes exact lijkt op de hash van het oude wachtwoord ('welkom11') wordt het wachtwoord aangemerkt als 'te gelijkend'.
Zie nogmaals die 2 bitstrings boven. Wat kun je eruit afleiden als jouw informatie enkel deze 2 strings zijn (want zo hoort het..)? Niets. En dat is precies de bedoeling.
Hoe zie jij dat trouwens? Hashcodes die op elkaar "lijken"? Dat hele fenomeen bestaat volgens mij niet. Maar ik denk dat we beide iets anders bedoelen. Dat kan haast niet anders.
[ Bericht 2% gewijzigd door Bart2002 op 09-08-2017 10:56:05 ]
Inderdaad: je controleert hier geen 'gelijkende' hashcodes, je creëert hashcodes van gelijkende strings. Als een van die hashcodes (exact) gelijk is aan die van het oude wachtwoord heb je een 'te veel lijkend' wachtwoord te pakken.quote:
[..]
Zeker. Maar zo werkt het niet. Je krijgt geen "gelijkende" (hoe moet ik dat zien overigens?) hashcodes door woorden die op elkaar lijken te coderen. Laat staan precies dezelfde code. Dat is nou juist mijn betoog. Dit is de kracht van hashcodering: je kunt er niets uit afleiden en al helemaal niet hoe hij tot stand is gekomen.
Hoe zie jij dat trouwens? Hashcodes die op elkaar "lijken"? Dat hele fenomeen bestaat volgens mij niet. Maar ik denk dat we beide iets anders bedoelen. Dat kan haast niet anders.
Dus:
Oud wachtwoord 'welkom12', hashcode '100011101010001111010001'
Nieuw wachtwoord 'welkom13', hashcode '001100101110010110000110'
Gegenereerd gelijkend nieuw wachtwoord 1: 'welkom1', hashcode '010001100011000100110010'
Gegenereerd gelijkend nieuw wachtwoord 2: 'welkom12', hashcode '100011101010001111010001'
Gegenereerd gelijkend nieuw wachtwoord 3: 'welkom14', hashcode '001010101011110111011101'
(etc.)
De hashcode van gegeneerd gelijkend nieuw wachtwoord 2 is gelijk aan die van het oude wachtwoord, dus het nieuwe wachtwoord lijkt te veel op het oude.
Hashes zijn inderdaad "one way". Je kan wel hashes genereren van vergelijkbare strings; dus als iemand "welkom01" als wachtwoord kiest sla je de hash van "welkom01" in de database op, maar je kan daarnaast ook meteen de hash van "welkom02" opslaan; als de gebruiker dan zijn wachtwoord wijzigt in "welkom02" dan matcht dat met de al eerder gegenereerde hash en kun je dit wachtwoord weigeren wegens teveel gelijkenis met het vorige wachtwoord.quote:
[..]
Zeker. Dat denkt men. Maar zo werkt het niet. Je krijgt geen "gelijkende" (hoe moet ik dat zien overigens?) hashcodes door woorden die op elkaar lijken te coderen. Laat staan precies dezelfde code. Dat is nou juist mijn betoog. Dit is de kracht van hashcodering: je kunt er niets uit afleiden en al helemaal niet hoe hij tot stand is gekomen.
Zie nogmaals die 2 bitstrings boven. Wat kun je eruit afleiden als jouw informatie enkel deze 2 strings zijn (want zo hoort het..)? Niets. En dat is precies de bedoeling.
Hoe zie jij dat trouwens? Hashcodes die op elkaar "lijken"? Dat hele fenomeen bestaat volgens mij niet. Maar ik denk dat we beide iets anders bedoelen. Dat kan haast niet anders.
Nee. Dit kan niet. Zo werkt het niet. Ik weet niet hoe ik het anders formuleren dan in #78. Je krijgt geen gelijke hashcodes door woorden die op elkaar lijken te hashen. Dat is nu juist de kracht en de theoretische basis.quote:
De hashcode van gegeneerd gelijkend nieuw wachtwoord 2 komt overeen met die van het oude wachtwoord, dus het nieuwe wachtwoord lijkt te veel op het oude.
Ze lijken niet op elkaar, ze zijn hetzelfde. Gegenereerd nieuw wachtwoord 2 en oud wachtwoord zijn hetzelfde.quote:
[..]
Nee. Dit kan niet. Zo werkt het niet. Ik weet niet hoe ik het anders formuleren dan in #78. Je krijgt geen gelijke hashcodes door woorden die op elkaar lijken te hashen.
Ah. Ja, dat klopt inderdaad. Men bedoelde dus w.s. dat.quote:
[..]
Hashes zijn inderdaad "one way". Je kan wel hashes genereren van vergelijkbare strings; dus als iemand "welkom01" als wachtwoord kiest sla je de hash van "welkom01" in de database op, maar je kan daarnaast ook meteen de hash van "welkom02" opslaan; als de gebruiker dan zijn wachtwoord wijzigt in "welkom02" dan matcht dat met de al eerder gegenereerde hash en kun je dit wachtwoord weigeren wegens teveel gelijkenis met het vorige wachtwoord.
Al lijkt me deze "methode" ook niet echt het neusje van de zalm op het gebied van veiligheid. Je gaat tenslotte aan de slag met het ongecodeerde origineel. Dat moet wel want anders kun je de gelijkenis niet bepalen. Ik vraag me af of deze manier (waar ik nog nooit van gehoord heb, maar dat zegt verder niets..) een solide theoretische basis heeft. Ik vermoed van niet.Het is gehakt waarvan je geen varken meer kunt maken.quote:Hashes zijn inderdaad "one way".
[ Bericht 12% gewijzigd door Bart2002 op 09-08-2017 11:14:41 ]
Nee, het voegt heel weinig toe want het pakt het onderliggende probleem niet aan: je kan natuurlijk nooit alle variaties gaan opslaan en het is daarnaast nog steeds mogelijk om zwakke wachtwoorden te gebruiken. Beter is het dan om een library als zxcvbn te gebruiken die (los van je eerder gekozen wachtwoorden) de sterkte van wachtwoorden al aan de client side checkt op allerlei kenmerken.quote:
[..]
Ah. Ja, dat klopt inderdaad. Men bedoelde dus w.s. dat.
Maar wachtwoorden an sich zijn helemaal niet veilig. Los van de sterkte kunnen ze gesniffed worden of dmv een keylogger achterhaald worden; of je kan ze eenvoudig resetten als je iemands email ook in handen hebt. Daarom zie je tegenwoordig steeds meer two factor authenticatie; waar je behalve een wachtwoord (iets wat je weet) ook een tweede stap hebt, zoals een pasje, of een challenge/response systeem via je smartphone (iets wat je hebt); of een biometrisch iets zoals stem, gezicht, vingerafdruk, iris etc (iets wat je bent). Als het ene dan gecompromitteerd is dan heb je de tweede stap nog. Ook niet 100% waterdicht (zeker biometrie heeft flinke nadelen) maar wel beduidend veiliger.
Ok wijsneus, als ik een nieuw wachtwoord invoer, voer ik ook mijn oude wachtwoord in, op dat moment kun je dus veilig een compare doen, zonder dat dit word opgeslagen, kortom de eerste stap is een check dat ze niet te veel op elkaar lijken, wanneer dat goed is kun je het nieuwe gehashde password weer opslaan.quote:
[..]
[..]
En dat kan dus niet. Zoals gezegd je kunt hashcode's niet met elkaar vergelijken en daar een bepaalde conclusie uit trekken behalve dat ze hetzelfde zijn of niet. Als dat wel kon dan moet je ze vermijden want ze zijn dan immers onveilig.
B.v. (vereenvoudigd voorbeeld van de hashcodes van 2 strings):
100011101010001111010001 (wachtwoord 1)
001100101110010110000110 (wachtwoord 2)
Welke conclusies kun je allemaal trekken? Lijkt wachtwoord 1 (Welkom123) op wachtwoord 2 (Welkom124)?
Ik heb het idee dat ik wat anders bedoel dan de anderen hier. Of dat men niet precies snapt wat een hashcode is en hoe die tot stand komt.
@Steenkool: van hashcodes en alles rondom het thema heb ik wel veel verstand hoor.
En voor de goede orde: je kunt uit bovenstaande 2 code's het origineel NIET herleiden. En is het dus onmogelijk te bepalen of de 2 op elkaar lijken of hetzelfde "thema" hebben. Zo werkt dat. Ik zal het topic t.z.t. nog eens goed lezen want ik heb het idee dat "men" (ook ik) langs elkaar heen praten.
En op welke manier zou jij implementeren dat het paswoord aan client-side ook niet gekend is?quote:
[..]
Nee. Hashes kun je niet vergelijken. Als je gehakt ziet dan kun je niet meer zien van welk varken dat afkomstig is. Ook kun je van dat gehakt geen varken meer maken. Dat is nou juist de kracht van het hash-algoritme. Het is een slecht begrepen fenomeen. Zie het als een vleesmolen. Je kunt enkel vergelijken of ze hetzelfde zijn. En dan is de input ook hetzelfde. Is de input 1 teken anders dan kun je ze niet vergelijken. Je kunt dus niet controleren of het wachtwoord "Welkom123" lijkt op wachtwoord "Welkom124".
Als dat wel kan dan doet het iets met plain tekst en de hele string. En dat moet je niet doen. Je sluit dan alles uit wat nou juist de bedoeling is met veiligheid.
Dus die 3 tekstvakken met "oude wachtwoord", "nieuwe wachtwoord", "nogmaals nieuwe wachtwoord" en als ze daar dan iets van vinden behalve of het oude wachtwoord niet klopt en/of de 2 nieuwe wachtwoorden niet hetzelfde zijn zijn inherent onveilig. Zij doen dan iets op de client wat betekent dat zij alle invoerstrings weten of ze versturen dat gewoon naar de server. Het eerste is wat minder problematisch dan het laatste maar het is beide niet goed.
Ik weet niet of het al uitgelegd is. Automagisch is een bewuste woordkeuze. Sommige mensen buiten de IT hebben soms het idee dat alles met 1 druk op een knop geregeld kan worden (een magische knop zo gezegd). Meestal leg je aan mensen ook niet uit dat er onwijs complexe structuren zijn om iets geregeld te krijgen (processen). Dus je hebt input, dan gebeurd er iets, dan heb je de output. Alsof het automatisch gebeurd, hence automagisch.quote:
[..]
AutomaTisch
Ik heb die vreemde variant al eens een keer gezien hier, dat was toch jij niet?
Ik moet zo weg, op vakantie. (geen smoes)quote:
[..]
En op welke manier zou jij implementeren dat het paswoord aan client-side ook niet gekend is?
Ik kom er op terug.Als dat alles inderdaad "aan boord" blijft dan kan dat w.s. niet anders. Het middel is niet onomstreden zoals Farenji al schreef (#84). Verder klopt mi.i. alles wat ik schreef over hashcodes, die verder niet van toepassing zijn als je ongecodeerde vergelijkingen gaat doen. Ik vraag me af of dit soort systemen "state of the art" zijn ontworpen en geïmplementeerd want daar gaat het om natuurlijk.quote:
[..]
Ok wijsneus, als ik een nieuw wachtwoord invoer, voer ik ook mijn oude wachtwoord in, op dat moment kun je dus veilig een compare doen, zonder dat dit word opgeslagen, kortom de eerste stap is een check dat ze niet te veel op elkaar lijken, wanneer dat goed is kun je het nieuwe gehashde password weer opslaan.
Gast je beweerd zelf dat om te kijken of en wachtwoord er niet te veel op lijkt je wachtwoorden ongehashed moet opslaan. Kortom NIET alles wat je beweerd klopt.quote:
[..]
Als dat alles inderdaad "aan boord" blijft dan kan dat w.s. niet anders. Het middel is niet onomstreden zoals Farenji al schreef (#84). Verder klopt mi.i. alles wat ik schreef over hashcodes, die verder niet van toepassing zijn als je ongecodeerde vergelijkingen gaat doen. Ik vraag me af of dit soort systemen "state of the art" zijn ontworpen en geïmplementeerd want daar gaat het om natuurlijk.
Zo vaak dit plaatje laten zien, waarna ik meestal door fok zolderautisten werd aangevallen hoe dat niet klopt of achterhaald zou zijn.quote:
Echt dit gaat al jaren terug.
