abonnementen ibood.com bol.com Gearbest
  woensdag 9 augustus 2017 @ 10:32:46 #76
78680 Nielsch
Al 41 jaar op FOK!
pi_173014208
berenanusboswachterremlof
Op zaterdag 8 oktober 2016 23:29 schreef Braindead2000 het volgende: Als je een vrouw vooraf gaat vragen of je haar bij haar kutje mag grijpen dan ben je wel een enorme sukkel.
  woensdag 9 augustus 2017 @ 10:41:30 #77
73232 De_Hertog
Aut bibat, aut abeat
pi_173014342
quote:
0s.gif Op woensdag 9 augustus 2017 10:23 schreef Bart2002 het volgende:

[..]

[..]

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)?
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'.
Mary had a little lamb
Then Mary had dessert
pi_173014393
quote:
0s.gif Op woensdag 9 augustus 2017 10:41 schreef De_Hertog het volgende:

[..]

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'.
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.

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 ]
vrijdag 9 december 2016 15:58 schreef Ringo het volgende:
Welke discussie? Ik zie alleen maar harige kerels die elkaar de rug inzepen.
  woensdag 9 augustus 2017 @ 10:56:13 #79
73232 De_Hertog
Aut bibat, aut abeat
pi_173014589
quote:
0s.gif Op woensdag 9 augustus 2017 10:44 schreef Bart2002 het volgende:

[..]

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

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.
Mary had a little lamb
Then Mary had dessert
pi_173014597
quote:
0s.gif Op woensdag 9 augustus 2017 10:44 schreef Bart2002 het volgende:

[..]

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.
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.
pi_173014636
quote:
0s.gif Op woensdag 9 augustus 2017 10:56 schreef De_Hertog het volgende:
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.
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.
vrijdag 9 december 2016 15:58 schreef Ringo het volgende:
Welke discussie? Ik zie alleen maar harige kerels die elkaar de rug inzepen.
  woensdag 9 augustus 2017 @ 11:00:17 #82
73232 De_Hertog
Aut bibat, aut abeat
pi_173014673
quote:
0s.gif Op woensdag 9 augustus 2017 10:58 schreef Bart2002 het volgende:

[..]

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.
Ze lijken niet op elkaar, ze zijn hetzelfde. Gegenereerd nieuw wachtwoord 2 en oud wachtwoord zijn hetzelfde.
Mary had a little lamb
Then Mary had dessert
pi_173014703
quote:
0s.gif Op woensdag 9 augustus 2017 10:56 schreef Farenji het volgende:

[..]

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.
Ah. Ja, dat klopt inderdaad. Men bedoelde dus w.s. dat. ;) 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.

quote:
Hashes zijn inderdaad "one way".
Het is gehakt waarvan je geen varken meer kunt maken. :)

[ Bericht 12% gewijzigd door Bart2002 op 09-08-2017 11:14:41 ]
vrijdag 9 december 2016 15:58 schreef Ringo het volgende:
Welke discussie? Ik zie alleen maar harige kerels die elkaar de rug inzepen.
pi_173015001
quote:
0s.gif Op woensdag 9 augustus 2017 11:01 schreef Bart2002 het volgende:

[..]

Ah. Ja, dat klopt inderdaad. Men bedoelde dus w.s. dat. ;) 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.
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.

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.
  woensdag 9 augustus 2017 @ 11:55:09 #85
8130 raptorix
THAI CHARACTER MAITAIKHU
pi_173015841
quote:
0s.gif Op woensdag 9 augustus 2017 10:23 schreef Bart2002 het volgende:

[..]

[..]

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.
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.
pi_173016654
quote:
0s.gif 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. 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.
En op welke manier zou jij implementeren dat het paswoord aan client-side ook niet gekend is?
Experiencing minor difficulties. Have positive up-angle and attempting to blow. Will keep you informed.
  woensdag 9 augustus 2017 @ 13:06:41 #87
341556 whY...
symbolisch ambassadeur
pi_173017240
quote:
1s.gif 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 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.
Apeldoorn 't Loo is waar ik te vinden ben.
"Ambassadeur van de stad Apeldoorn, namens Isis20."
pi_173017485
quote:
0s.gif Op woensdag 9 augustus 2017 12:35 schreef crystal_meth het volgende:

[..]

En op welke manier zou jij implementeren dat het paswoord aan client-side ook niet gekend is?
Ik moet zo weg, op vakantie. (geen smoes) :) Ik kom er op terug.
vrijdag 9 december 2016 15:58 schreef Ringo het volgende:
Welke discussie? Ik zie alleen maar harige kerels die elkaar de rug inzepen.
pi_173017595
quote:
0s.gif Op woensdag 9 augustus 2017 11:55 schreef raptorix het volgende:

[..]

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.
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.
vrijdag 9 december 2016 15:58 schreef Ringo het volgende:
Welke discussie? Ik zie alleen maar harige kerels die elkaar de rug inzepen.
  woensdag 9 augustus 2017 @ 13:38:53 #90
8130 raptorix
THAI CHARACTER MAITAIKHU
pi_173017956
quote:
0s.gif Op woensdag 9 augustus 2017 13:22 schreef Bart2002 het volgende:

[..]

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.
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.
pi_173018342
quote:
Zo vaak dit plaatje laten zien, waarna ik meestal door fok zolderautisten werd aangevallen hoe dat niet klopt of achterhaald zou zijn. :')

Echt dit gaat al jaren terug.
pi_173028168
Daarom gewoon simpele wachtwoorden met two factor authenticatie wanneer je ingelogd bent 128bit automatisch gegenereerde wachtwoorden gebruiken met je password manager *O*
abonnementen ibood.com bol.com Gearbest
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')