Bedenker van strenge wachtwoordeisen heeft spijt

quote:

Op dinsdag 8 augustus 2017 17:30 schreef Bart2002 het volgende:

[..]

Dat kan in principe niet. Of je moet de wachtwoorden als plain tekst (via 1 of andere encryptie eventueel) opslaan.

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:

Op dinsdag 8 augustus 2017 17:43 schreef Bart2002 het volgende:

[..]

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.

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.

Waarmee ik absoluut niet wil zeggen dat deze eisen 'goed' zijn, of dat het daadwerkelijk op deze manier gedaan wordt, uiteraard.

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.

Ik ga dat zo ook maar even kijken dan. Is het werkelijk zo grappig?

quote:

Op dinsdag 8 augustus 2017 23:14 schreef De_Hertog het volgende:
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.

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:

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.

Hij heet (ook) Bill Burr (eerste zin vd OP)

quote:

Op dinsdag 8 augustus 2017 23:25 schreef Treinhomo het volgende:

[..]

Oeh; da's een gewetensvraag.

(Wan)smaak is wel zó persoonlijk.

Ja, dat is waar. Als ik moest lachen meld ik dat zo wel. Blijft het stil: trek dan je conclusie.

quote:

Op dinsdag 8 augustus 2017 23:24 schreef Bart2002 het volgende:

[..]

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.

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-https

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

quote:

Op dinsdag 8 augustus 2017 23:25 schreef Treinhomo het volgende:

[..]

Oeh; da's een gewetensvraag.

(Wan)smaak is wel zó persoonlijk.

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.

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.

quote:

Op dinsdag 8 augustus 2017 23:43 schreef De_Hertog het volgende:
Overigens zou je zelfs in dat systeem clientside de twee uiteindelijke hashes met elkaar kunnen vergelijken

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.

[ Bericht 7% gewijzigd door Bart2002 op 09-08-2017 00:26:54 ]

quote:

Op dinsdag 8 augustus 2017 17:00 schreef LXIV het volgende:
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

is dat een zekere verzekeraar?

quote:

Op woensdag 9 augustus 2017 00:51 schreef Yreal het volgende:

[..]

is dat een zekere verzekeraar?

Nee.

quote:

Op dinsdag 8 augustus 2017 22:48 schreef Bart2002 het volgende:

[..]

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.

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.

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.

quote:

Op dinsdag 8 augustus 2017 23:53 schreef Bart2002 het volgende:

[..]

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.

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.

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.

quote:

Op dinsdag 8 augustus 2017 17:30 schreef Bart2002 het volgende:

[..]

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.

Nee hoor, dat is wel op slimmere manieren te doen, bijvoorbeeld door ook een footprint op te slaan van een wachtwoord structuur.

quote:

Op dinsdag 8 augustus 2017 17:43 schreef Bart2002 het volgende:

[..]

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.

Jij ook niet echt, wat je roept is simpelweg niet waar, overigens is het flauwekul om dit soort beperkingen op te leggen.

quote:

Op woensdag 9 augustus 2017 09:49 schreef raptorix het volgende:

[..]

Nee hoor, dat is wel op slimmere manieren te doen, bijvoorbeeld door ook een footprint op te slaan van een wachtwoord structuur.

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:

Op woensdag 9 augustus 2017 09:49 schreef raptorix het volgende:

[..]

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?

Of als je enkel footprints voor eerdere wachtwoorden op en voeg je er één toe voor het oude wachtwoord als je deze wijzigt?

quote:

Op woensdag 9 augustus 2017 09:53 schreef Bart2002 het volgende:

[..]

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.

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:

Op woensdag 9 augustus 2017 09:56 schreef kipknots het volgende:

[..]

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?

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.

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

Bart2002 praat weer eens alsof hij ergens verstand over heeft, maar klok en klepel...

quote:

Op dinsdag 8 augustus 2017 16:17 schreef spijkerbroek het volgende:
Gelukkig is deze man tot inkeer gekomen. Maar helaas is het kwaad al geschied.

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:

Op woensdag 9 augustus 2017 10:05 schreef raptorix het volgende:
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

quote:

e.g. comparing a hash of this string against the stored hash of your current password

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.

[ Bericht 3% gewijzigd door Bart2002 op 09-08-2017 10:40:52 ]

Ik gebruik altijd wachtwoorden zoals zwalustaartaftekenhulpstukje of Nederlandsetrampolinespringkampioenschappen. Arbeidsongeschiktheidverzekeringsformulier en landbouwmechanisatietetentoonstelling zijn ook leuke. Zulke woorden zijn makkelijk te onthouden maar voor een hacker zo moeilijk om te achterhalen dat ze het vrij snel opgeven.