Beveiliging: laatste 3 wachtwoorden-check & encryptie

[Rekcor]

Ik wil (in PHP/MySQL) graag maken dat gebruikers om de 3 maanden een nieuw wachtwoord moeten aanmaken. Echter, ik wil voorkomen dat het nieuwe wachtwoord teveel lijkt op een ouder wachtwoord (max 3 wachtwoorden terug), bijv. geen:

myPass1
myPass2
etc.

Nu is de vraag: hoe dit te doen? Zoals gebruikelijk, worden alle wachtwoorden encrypted opgeslagen in de database. Echter, omdat ze encrypted zijn, kan ik niet meer kijken of het wachtwoord lijkt op een eerder wachtwoord. De wachtwoorden als plain text opslaan lijkt me ook geen optie...

[djexplo]

Een standaard wachtwoord formulier vraag altijd :
Bestaand Wachtwoord
Nieuw Wachtwoord
Herhaling Nieuw Wachtwoord

Of te wel als je dat gebruikt, heb je opdat moment een niet versleuteld versie van zijn oude wachtwoord.

[TJHeuvel]

De TS wilt niet dat het overeenkomt, maar eerder dat het nieuwe wachtwoord er niet op lijkt.

[MueR]

Maar waarom zou je dat in je User tabel moeten hebben? Een tabelletje UserPasswordHistory met daarin de hashes en datum kan je makkelijk even aanspreken. Op die manier kan je het ook nog uitbreiden als je ooit naar 5 passwords history oid.

[ Voor 3% gewijzigd door MueR op 01-08-2011 11:01 ]

[Cartman!]

Ik hoop trouwens dat je gehasht bedoelt ipv. encrypted, een groot verschil.

[Cloud]

MueR ik denk dat de vraag van de TS wat complexer is dan dat.

Hij wil weten of het nieuwe wachtwoord niet lijkt op het oude. Dus bijvoorbeeld de volgende reeks:

• mijnwachtwoord!1
• mijnwachtwoord!2
• mijnwachtwoord!3

Zo verander je elke keer van wachtwoord, maar niet op de juiste manier. Het probleem is dat als je alleen de hashes opslaat, je dit patroon niet kunt zien. Want een kenmerk van een goede hash is dat bij minimale verandering van de input, de output maximaal verandert. Op zich dus best een goede vraag, waarop ik nog even geen antwoord weet eigenlijk

[RobIII]

Rekcor schreef op maandag 01 augustus 2011 @ 10:55:
Nu is de vraag: hoe dit te doen? Zoals gebruikelijk, worden alle wachtwoorden encrypted opgeslagen in de database. Echter, omdat ze encrypted zijn, kan ik niet meer kijken of het wachtwoord lijkt op een eerder wachtwoord.

euh; als ze encrypted waren dan kon je dat wél. Je slaat ze hashed op; there's a difference
Encryption => Two way
Hashing => One way

/edit: spuit 11

Cloud schreef op maandag 01 augustus 2011 @ 11:04:

Zo verander je elke keer van wachtwoord, maar niet op de juiste manier. Het probleem is dat als je alleen de hashes opslaat, je dit patroon niet kunt zien. Want een kenmerk van een goede hash is dat bij minimale verandering van de input, de output maximaal verandert. Op zich dus best een goede vraag, waarop ik nog even geen antwoord weet eigenlijk

Je geeft 't antwoord al: als je hashes gebruikt is 't simpelweg niet mogelijk.

Je kunt oude wachtwoorden plain-text opslaan (en dan voor mijn part weer encrypted om 't veiliger te maken), maar als mensen dan (bijv.) mypass1, mypass3, mypass5 in hun lijstje hebben staan (of equivalent wat dan nét langs de eisen komt) kun je als hacker natuurlijk ook wel raden wat de volgende is

[ Voor 48% gewijzigd door RobIII op 01-08-2011 16:39 ]

[Rekcor]

djexplo schreef op maandag 01 augustus 2011 @ 10:59:
Een standaard wachtwoord formulier vraag altijd :
Bestaand Wachtwoord
Nieuw Wachtwoord
Herhaling Nieuw Wachtwoord

Of te wel als je dat gebruikt, heb je opdat moment een niet versleuteld versie van zijn oude wachtwoord.

Dit klinkt me als de winnende oplossing in de oren! Bedankt! Of zie ik iets over het hoofd, getuige de reactie van Cloud. Inderdaad, dit werkt maar 1 wachtwoord terug

Overigens is het idd gehashed, anders bestond het probleem idd niet .

[ Voor 5% gewijzigd door Rekcor op 01-08-2011 11:10 ]

[alwinuzz]

Met encryption bedoel je encryptie die je niet kan decrypten? Dit wordt vaak hashing genoemd.
spuit12

Als je wilt voorkomen dat de gebruiker een oud wachtwoord opnieuw gebruikt, kan dat (zie reactie Muer).

Wil je voorkomen dat de gebruiker een nieuw wachtwoord maakt dat lijkt op het vorige wachtwoord, kan ook (reactie djexplo). Ik zie het nut hier niet echt van in, kans op post-it wachtwoorden wordt nóg groter.

Wil je voorkomen dat de gebruiker een nieuw wachtwoord maakt dat lijkt op één van de meerdere oude wachtwoorden, dan is dit theoretisch mogelijk maar dan moet je de oude wachtwoorden op een manier opslaan dat je ze kan decrypten. Dat lijkt me onveilig en niet de bedoeling.

[GlowMouse]

Als het wachtwoord mijnwachtwoord!1 is, en je wilt mijnwachtwoord!2 kunnen afkeuren, dan kun je de wachtwoorden bijna net zo goed gelijk plain text opslaan omdat kraken veel makkelijker wordt.

[djexplo]

Cloud schreef op maandag 01 augustus 2011 @ 11:04: ...
Zo verander je elke keer van wachtwoord, maar niet op de juiste manier. Het probleem is dat als je alleen de hashes opslaat, je dit patroon niet kunt zien. Want een kenmerk van een goede hash is dat bij minimale verandering van de input, de output maximaal verandert. Op zich dus best een goede vraag, waarop ik nog even geen antwoord weet eigenlijk

Het komt er dus op neer dat hij meer informatie moet gaan opslaan b.v. letter frequentie, en wachtwoord lengte. Maar daardoor maak je de beveiliging juist minder sterk.

De beste oplossing is waarschijnlijk toch, oude wachtwoord vragen tegelijkertijd met nieuwe. Daar dan de vergelijking checks op doen. En van alle wachtwoorden daarvoor alleen de hash bewaren. Dus alleen een check doen of deze niet 100% gelijk zijn.

[LuCarD]

Je zou zoiets kunnen doen.

PHP:

$passes =  array('qwerty', 'qwerty1','1qwerty', 'mijnwachtwoord!1','mijnwachtwoord!2','mijnwachtwoord!3');
foreach ( $passes as $pass ) {
echo $pass . "> ". soundex($pass) . " > " . md5("zout".soundex($pass)) ."<br>";
}

De md5 versie van soundex opslaan en vergelijken.

[ Voor 10% gewijzigd door LuCarD op 01-08-2011 11:11 ]

[Gomez12]

Tja, wat vind je 2 wachtwoorden die wel / niet op elkaar lijken?

een 1 erachter gezet lijkt het dan op elkaar, of als iemand er gewoon de huidige maandnaam achter plakt, of combinatie van jaar - maand...

Persoonlijk ben ik nooit zo'n voorstander van dit soort systemen, het wekt imho irritatie op bij de bewuste gebruikers en voor de nitwit gebruikers werkt het niet want die verzinnen gewoon een systeem wat jij niet als op elkaar gelijkend beschouwt...

Enkel wachtwoord verandering in de x tijd desnoods aangevuld met dat het ww niet gelijk mag zijn aan laatste ww ( is heel vaak weer zo omheen te komen door na de verplichte ww-verandering het ww nogmaals te veranderen )
dus : test -(verplichte ww verandering)> qwerty -(handmatige ww verandering)> test

[Cloud]

Klopt, je kunt het oude wachtwoord vragen. Echter kun je dan dus alleen effectief het nieuwe wachtwoord met het huidige vergelijken; en geen historie van drie vorige wachtwoorden zoals de TS in eerste instantie zoekt.

Volgens mij is dit inderdaad onmogelijk zonder meer informatie per wachtwoord op te slaan waarmee je je beveiliging eerder zwakker maakt dan anders wat. Ik zou alleen vergelijken met het vorige wachtwoord en hopen dat men de hint snapt

[LuCarD]

Roteer de wachtwoord eisen!

Wachtwoord 1: max 1 Hoofdletter, kleine letters en cijfers
Wachtwoord 2: minimaal 2 Hoofdletters, kleine letters en leestekens, geen cijfers
etc.

[Japius]

Inventief! Uit het oogpunt van gebruiksvriendelijkheid zou ik het afraden, de gebruiker weet zo natuurlijk nooit meer wat zijn wachtwoord is.

[kokx]

Zoals Gomez12 al zegt, wekt dit een enorme irritatie op bij gebruikers. Dat je gebruikers aanraad om het wachtwoord te veranderen kan goed, maar ga ze niet verplichten om moeilijk te doen. Dat is namelijk vragen om dat ze hun wachtwoorden op gaan schrijven, met alle beveiligingsrisico's van dien.

Daarnaast moet je je ook beseffen dat hoe meer informatie je over een wachtwoord op gaat slaan, hoe makkelijker het te bruteforcen is. Als je bijvoorbeeld de soundex gaat opslaan, dan heb je al een stuk minder mogelijkheden om de juiste richting in te zitten met het bruteforcen van het wachtwoord.

@LuCarD: Dat is zo mogelijk NOG irriterender bij gebruikers, aangezien die dan een wachtwoord naar keuze niet kunnen gebruiken, en het ook totaal niet consistent is. Het klinkt meer als een gevalletje gebruikertje pesten dan om de gebruiker te helpen.

[Voutloos]

LuCarD schreef op maandag 01 augustus 2011 @ 11:15:
Roteer de wachtwoord eisen!

Wachtwoord 1: max 1 Hoofdletter, kleine letters en cijfers
Wachtwoord 2: minimaal 2 Hoofdletters, kleine letters en leestekens, geen cijfers
etc.

Als grapje bedoel, want dit is echt een belachelijk slecht idee.

[Coca-Cola]

Je geeft 't antwoord al: als je hashes gebruikt is 't simpelweg niet mogelijk.

Ligt eraan hoe je hashed, je kan hashes opslaan die je juist precies voor het vergelijken op gelijkheden kan gebruiken (googlen op fuzzy hashing for near deduplication), maar dat is niet echt deterministisch (dus dan kan je zien dat 2 passwords niet genoeg van elkaar verschillen, maar niet precies waarom dat zo is).

[ Voor 6% gewijzigd door Coca-Cola op 01-08-2011 11:23 ]

[Cloud]

@Coca-Cola
Niet dat ik het iemand aan zou raden (want het lijkt mij inderdaad onveiliger als hash-methode) maar heb je daar ook een voorbeeld van? Het klinkt wel interessant namelijk

[alwinuzz]

Offtopic: wat ik echt nooit snap zijn van die eisen van "maximaal x tekens lang".
Ik vraag me dan altijd af of ze het wachtwoord plain-text opslaan in een VARCHAR(10).

[LuCarD]

Voutloos schreef op maandag 01 augustus 2011 @ 11:19:
[...]
Als grapje bedoel, want dit is echt een belachelijk slecht idee.

duh!

Oke.. Wat voor een site hebben we het over? Ik ga een beetje vanuit dat het een bedrijfs site is waar alleen interne medewerkers gebruik van maken?

Dan is het naar mijn mening beter om de gebruiker opleiden dan zo'n ongebruiksvriendelijke oplossing te zoeken. Geef de gebruikers instructie over gebruik van wachtwoord applicatie's zoals Keepass. Daar bereik je naar mijn mening veel betere resultaten mee.

[Coca-Cola]

Cloud schreef op maandag 01 augustus 2011 @ 11:22:
@Coca-Cola
Niet dat ik het iemand aan zou raden (want het lijkt mij inderdaad onveiliger als hash-methode) maar heb je daar ook een voorbeeld van? Het klinkt wel interessant namelijk

Het komt er op neer dat je een hash per sectie van een woord (of eigenlijk gebruik je het normaal voor hele files, maar zou ook op woord delen moeten kunnen werken) en dat je een stukje van die hash opslaat als onderdeel van je uiteindelijke hash. Vervolgens maak je een nieuwe hash van het nieuwe wachtwoord en vergelijkt op hoeveel punten het verschilt van de hash van het vorige password. Als dit maar op 1 punt is dan is het wachtwoord bijna hetzelfde als het vorige.

offtopic:
My => 8466fa8e428bf83c4d2d9893b4bada64
Pa => a13df921d517c3e3508b5a752a79d53b
ss => 3691308f2a4c2f6983f2880d32e29c84
wo => e0a0862398ccf49afa6c809d3832915c
rd => eeec033a2c4d56d7ba16b69358779091
01 => 96a3be3cf272e017046d1b2674a52bd3

Final Hash:
8466a13d3691e0a0eeec96a3

New password:
My => 8466fa8e428bf83c4d2d9893b4bada64
Pa => a13df921d517c3e3508b5a752a79d53b
ss => 3691308f2a4c2f6983f2880d32e29c84
wo => e0a0862398ccf49afa6c809d3832915c
rd => eeec033a2c4d56d7ba16b69358779091
02 => a2ef406e2c2351e0b9e80029c909242d

8466a13d3691e0a0eeeca2ef

Verschil van 1 sectie, dus password lijkt teveel. Nu ik er wat meer over nadenk, is dit voor dit soort toepassingen toch niet echt geschikt . Op grote files kan je markers nemen tot waar je hashed en dan kan je rekening houden met wijzigingen in of aan het begin van de file zodat die geen effect hebben op de totale fuzzy hash, hier kan iemand gewoon 1 karakter toevoegen aan het begin en het werkt niet meer goed, of je moet per karakter hashen, maar dan is het meer een encoding

[ Voor 39% gewijzigd door Coca-Cola op 01-08-2011 11:34 ]

[engelbertus]

je kunt beter meteen de eigenschappen van het wachtwood proberen op te slaan.
bijvoorbeeld de lengtem en of welke posiie een hoofdletter, speciaal teken of cijfer is.
dan heb je genoeg om te kijken of het op elkaar lijkt, en geef je geen concrete wachtwoord inhoud prijs in een of andere plain text tabel.

als je dan die eigenschappen van het wachtwoord op een manier opslaat waarvan anderen niet makkelijk kunnen beredenere wat je hoe hebt opgeslagen, help je een hacker ook niet aan informatie waarmee ze accounts kunnen hacken, per slot van rekening sla je immers alleen ook eigenschappen van een oud wachtwoord op, dat dus niet meer werkt, en niet lijkt ophet actuele wachtwoord. ( want dat was immers juist het idee achter dit vraagstuk.

dus je slaat dan bijvoorbeeld op 8 tekens, 1 hoofdletter 1 cijfer, evt op welke posities, of je noteert voor elke positie de ëigenschappen" positie 1=letter 2=cijfer,3=teken 4=hoofdletter

om dan iets te kunnen hacken moet een hacker al in het systeem zijn binnen gedrongen en vervolgens wachtwoorden bedenken die niet lijken op wat hij heeft gevonden.

verder

zodra je wel een manier hebt gevonden om e.e.a. op te slaan heb je nog algoritme nodig die bepaald of het een op het ander lijkt.
wat me ook nog wel een latig vraagstuk lijkt.

roterende eisen zou ik niet doen. dan weet immers nooit iemand waar zijn wachtwoord aan moet voldoen. en wordt het bijna een invuloefening en kom je alleen om wachtwoorden die de gebruiker ook niet meer kan onthouden.

[alwinuzz]

engelbertus schreef op maandag 01 augustus 2011 @ 11:31:
dus je slaat dan bijvoorbeeld op 8 tekens, 1 hoofdletter 1 cijfer, evt op welke posities, of je noteert voor elke positie de ëigenschappen" positie 1=letter 2=cijfer,3=teken 4=hoofdletter

Dan sla je bijna het wachtwoord zelf plain-text op...

[ Voor 4% gewijzigd door alwinuzz op 01-08-2011 11:35 ]

[engelbertus]

wat cocacola zegt. je kunt van elke 2 letters na elkaar een hadh maken, en dan steeds een positie verschuiven. dan weet je precies hoeveel tekens er zijn veranderd ten opzichte van het vorge wachtwoord. e weet alleen niet wat het verschil precies is.
je moet ook best wel veel opslaan dan, met acht tekens heb je 7 hashes per wachtwoord nodig, stel hashes van 16 tekens, of 32. maar goed, heden ten dage is opslag hopeljk geen probleem meer.

verder heb ej als hacker dan alsnog een goede mogelijkheid om te raden wat het wachtwoord is, als je weet welk hash methode is gebruikt. immers, je kunt zo even een tabel maken van de hashes van alle combinaties van 2 tekens.

[kokx]

engelbertus schreef op maandag 01 augustus 2011 @ 11:31:
je kunt beter meteen de eigenschappen van het wachtwood proberen op te slaan.
bijvoorbeeld de lengtem en of welke posiie een hoofdletter, speciaal teken of cijfer is.
dan heb je genoeg om te kijken of het op elkaar lijkt, en geef je geen concrete wachtwoord inhoud prijs in een of andere plain text tabel.

als je dan die eigenschappen van het wachtwoord op een manier opslaat waarvan anderen niet makkelijk kunnen beredenere wat je hoe hebt opgeslagen, help je een hacker ook niet aan informatie waarmee ze accounts kunnen hacken, per slot van rekening sla je immers alleen ook eigenschappen van een oud wachtwoord op, dat dus niet meer werkt, en niet lijkt ophet actuele wachtwoord. ( want dat was immers juist het idee achter dit vraagstuk.

De reden dat je een wachtwoord hashed, is voorals een hacker in weet te breken in je database server. Om dan te voorkomen dat de wachtwoorden van je gebruikers meteen op straat liggen. Echter, als je dan meer informatie gaat opslaan, ga je de hacker ZEKER wel helpen. In wat jij aangeeft, is zeker voldoende om het aantal mogelijke wachtwoorden te halveren, en waarschijnlijk nog erger. Dat is dus zeker ongewenst.

Edit: @Coca-Cola: besef wel dat je dan het aantal subhashes niet af moet laten hangen van de lengte van het wachtwoord. Aangezien de hacker dan al een stuk meer weet over het wachtwoord. En daarnaast denk ik eigenlijk ook niet dat het zo'n goed idee is, aangezien een hacker dan gewoon je wachtwoord kan opsplitsen in de subwachtwoorden die jij hebt gebruikt voor het hashen. En een korter wachtwoord is een stuk sneller te bruteforcen. En 10x 1 teken achterhalen uit een hash, is 10x128 mogelijkheden (even aangenomen dat men 128 tekens kan gebruiken in eeen wachtwoord) kost toch een stuk minder tijd om te bruteforcen dan 128^10 mogelijkheden.

[ Voor 19% gewijzigd door kokx op 01-08-2011 11:43 ]

[Gomez12]

engelbertus schreef op maandag 01 augustus 2011 @ 11:31:
dus je slaat dan bijvoorbeeld op 8 tekens, 1 hoofdletter 1 cijfer, evt op welke posities, of je noteert voor elke positie de ëigenschappen" positie 1=letter 2=cijfer,3=teken 4=hoofdletter

Ok, dan heb je je beveiliging al zo goed als om zeep geholpen...
En wat is het eindresultaat? Dat mensen niet wachtwoorden met dezelfde schrijfstijl mogen hanteren... Nee, dat is lekker. Je mag dus de 2e x geen wachtwoord meer hebben wat begint met een letter, daarna een cijfer en dan een teken en daarna een hoofdletter...

Gaat echt gegarandeerd giga-problemen opleveren, oftewel mensen gaan het opschrijven en dan heb je dus een extreem verzwakte beveiliging in combinatie met post-its... Yep dat is echt de situatie waar je naartoe wilt.

[Coca-Cola]

Edit: @Coca-Cola: besef wel dat je dan het aantal subhashes niet af moet laten hangen van de lengte van het wachtwoord. Aangezien de hacker dan al een stuk meer weet over het wachtwoord. En daarnaast denk ik eigenlijk ook niet dat het zo'n goed idee is, aangezien een hacker dan gewoon je wachtwoord kan opsplitsen in de subwachtwoorden die jij hebt gebruikt voor het hashen. En een korter wachtwoord is een stuk sneller te bruteforcen.

Nou natuurlijk, in princiepe splits je het wachtwoord altijd op in x stukken (onafhankelijk van de lengte, maar je moet dan iets slims doen met hoeveel characters per hash) en neem je van elke x hashes een stukje om de finale hash te maken. Opzich sla je maar 1 hash op en alhoewel het inderdaad zwakker is dan een gewone hash, zit er vrij veel obscurity in wat het wel wat lastiger te hacken maakt

Ontopic: Hoe doet Windows dat eigenlijk? Die moeten dat dan ook ergens in AD opslaan toch?

[ Voor 5% gewijzigd door Coca-Cola op 01-08-2011 11:45 ]

[Rekcor]

Bedankt mensen! Ik ga voor de 1 wachtwoord-terug-check door gebruikers beiden te laten invoeren bij wijziging.

Wat mij betreft mag het topic op slot, maar ik kan me ook voorstellen dat er mensen zijn die door willen discussieren over hoe mijn originele probleem zo goed mogelijk opgelost kan worden...

[kokx]

@Coca-Cola: Ga je eerst eens goed verdiepen in hashing (zoals Wikipedia: SHA-1 ), voordat je conclusies gaat trekken die niet waar zijn. Een goede hash is *niet* op te delen in stukken waardoor deze gemakkelijker op te lossen word.

[engelbertus]

dat is niet waar alwinuz, ook weet een hacker niet op wat voor menier je het hebt opgeslagem ( ok, security by obscurity) maar toch effectief. en dan heb je als hacker alsnog de taak om dat uit te vinden, en vervolgens nog de taak, om iets te bedenken dat juist iets anders is dan wat er is opgeslagen. als je dus ipv opschrijft dat het een letter is, gebruik e daar een bit of byte voor, of een letter. Pi3tje4! wordt dan bijvoorbeeld 1242243

alle toegestane nieuwe wachtwoorden moeten dan bijvoorbeeld op minimaal 2 punten afwijken. dat plus dat er verder geen info over het concrete antwoord te vinden is, ( je weet niet welke reeksen een gebruiker wilde gebruiken zoals Pi3tje5? of pI3tj5@) dus de mogelijkheden voor een te kiezen wachtwoord zijn nog enorm veel, en je hetbt niks als basis. wat dus met pi3tje4! als basis al een stuk makkelijker zou worden. je kunt bijvoorbeeld met de hand nog alle mogelijkheden in een uurtje kunnen opschrijven.

plus dat als niemand begrjpt wat de code 1242243 betekent, dan kan ook niemand dat in zijn voordeel gebuiken.

overigens is een willekeurige code van 8 tekens, die dan wel ook als sterk wachtwoord geld, best te onthouden, en voor langere tijd bruikbaar. als je die niet op briefjes schrijf of uitdeelt tenminste. anders zet je immers altijd de deur wagenwijd open voor misbruik, juist door collegas of bekenden.

[Coca-Cola]

kokx schreef op maandag 01 augustus 2011 @ 11:47:
@Coca-Cola: Ga je eerst eens goed verdiepen in hashing (zoals Wikipedia: SHA-1 ), voordat je conclusies gaat trekken die niet waar zijn. Een goede hash is *niet* op te delen in stukken waardoor deze gemakkelijker op te lossen word.

Sorry hoor, ik weet precies hoe hashes werken, lees het topic anders nog even goed door. Ik draag (meer ter informatie dan als oplossing) een FUZZY hashing algoritme aan dat daadwerkelijk wordt gebruikt om strings te vergelijken op kleine afwijkingen (namelijk voor NEAR DEDUPLICATION van data). Zo'n hash bestaat dus uit gedeeltes van hashes. Als ik jouw wachtwoord in X karakters opsplits, elke X hash en daar stukjes uit ga halen en weer aan elkaar ga plakken, dan is die hash dus een stuk makelijker te 'kraken' dan 1 hash over het hele wachtwoord (althans, het is makelijker om een wachtwoord te vinden dat dezelfde hash oplevert, je weet nooit of je ook echt het orginele wachtwoord hebt gevonden, maar dat is ook niet meer nodig dan)

[Rekcor]

Nog een beveiligingsvraag: in mijn webapplicatie (in PHP/MySQL) moeten gebruikers sinds kort een lang/veilig wachtwoord kiezen. De gebruikers klagen hierover, omdat ze per dag erg vaak inloggen op het systeem.

Nu vroeg ik me af: als ik een hash van (de eerste 3-5 tekens van het wachtwoord + het ip-adres) opsla, hoe veilig is het dan om de gebruiker de mogelijkheid te geven om vanaf dat bekende ip-adres (d.w.z. het ip-adres van de pc op het kantoor, wat beveiligd is d.w.z. je komt er niet zomaar binnen) om met de eerste 3 tekens van het wachtwoord in te loggen?

Als men buiten het kantoor (bijv. vanaf thuis, in de trein, etc) in wil loggen, dan moet het met het lange wachtwoord.

En natuurlijk: het lange wachtwoord is altijd veiliger, maar dat wil men nu eenmaal niet.

[engelbertus]

Gomez12 schreef op maandag 01 augustus 2011 @ 11:38:
[...]

Ok, dan heb je je beveiliging al zo goed als om zeep geholpen...
En wat is het eindresultaat? Dat mensen niet wachtwoorden met dezelfde schrijfstijl mogen hanteren... Nee, dat is lekker. Je mag dus de 2e x geen wachtwoord meer hebben wat begint met een letter, daarna een cijfer en dan een teken en daarna een hoofdletter...

Gaat echt gegarandeerd giga-problemen opleveren, oftewel mensen gaan het opschrijven en dan heb je dus een extreem verzwakte beveiliging in combinatie met post-its... Yep dat is echt de situatie waar je naartoe wilt.

ok.maar dan kunnen we het dus eerst beter hebben over wat de definitie is van "lijkt op"

plus dat niemand weet wat voor code je hebt gebruikt bij het opslaan van de eigenschappen van een wachtwoord. ook die deel hashes kun je makkelijk met bruteforce / rainbowtable aanvallen.

dus als je ëigenschappen van een wachtwoord 1234 is zoals in mijn voorbeeld. en je stelt dat het op twee punten moet afwijken dan kunnen mensen een gelijkend wachtwoord maken door hoofdletters in kleine letters te veranderen. het is echter onbekend of iemand dat ook daadwerkelijk heeft gedaan voor zijn nieuwe wachtwoord, of het cijfer en het speciale teken te vervangen of om te wisselen. bij een langer wachtwoord heb je dan dus niet bepaald dat ej de mogelijkheden voor een nieuw wachtwoord hebt gehalveerd. hoogstens ingekort met 25%. maar juist dat van die overige 75% nog wel alles mogelijk is, en niet bekend is welke 75% dat dan is, zorgt ervoor dat een hacker alsnog alle combinaties moet proberen.

verdre lijkt het mij dat elke manier van opslaan van wachtwoorden of gegevens eigenlijk NOG meer info verstrekt aan een hacker. die subhashes zijn in mijn ogen dus ook gewoon erg gevaarlijk.

daarom lijkt het mij juist veel beter om op te slaan aan welke eisen een nieuw wachtwoord NIET mag voldoen, ipv op te slaan wat het nieuwe wahtwoord niet mag zijn, je verraad dan immers nog meer dan de eigenschappen waarop je wilt testen. dat vinden ze immers alsnog wel uit. het zal toch ergens gecodeerd moeten zijn hoe e.e.a. wordt getest

[Cartman!]

Ik denk dat er weinig te willen is, geef ze een keuze:

- lange wachtwoorden en betere veiligheid
- korte wachtwoorden en grote kans op gezeik en dat jij dan niet aansprakelijk bent voor hacks ed.

Kunnen ze niet veel makkelijker hun sessie langer geldig laten zijn?


edit: mmm... deze post gaat over het hebben van korte/lange wachtwoorden per ip-adres van een nieuwe vraag in n ander topic die nu merged is

[ Voor 21% gewijzigd door Cartman! op 01-08-2011 12:04 ]

[kokx]

Coca-Cola schreef op maandag 01 augustus 2011 @ 11:55:
[...]


Sorry hoor, ik weet precies hoe hashes werken, lees het topic anders nog even goed door. Ik draag (meer ter informatie dan als oplossing) een FUZZY hashing algoritme aan dat daadwerkelijk wordt gebruikt om strings te vergelijken op kleine afwijkingen (namelijk voor NEAR DEDUPLICATION van data). Zo'n hash bestaat dus uit gedeeltes van hashes. Als ik jouw wachtwoord in X karakters opsplits, elke X hash en daar stukjes uit ga halen en weer aan elkaar ga plakken, dan is die hash dus een stuk makelijker te 'kraken' dan 1 hash over het hele wachtwoord (althans, het is makelijker om een wachtwoord te vinden dat dezelfde hash oplevert, je weet nooit of je ook echt het orginele wachtwoord hebt gevonden, maar dat is ook niet meer nodig dan)

Fuzzy hashing heeft ook een totaal andere toepassing dan hashing voor security. Als je 2 erg lange strings of bestanden wilt vergelijken, is fuzzy hashing wel handig ja. Maar in dit geval is het om de wachtwoorden van gebruikers veilig te houden, en dan wil je het zo lastig mogelijk maken voor eventuele hackers.

[alwinuzz]

@engelbertus, hoe je het ook verwoordt, je slaat extra info op over het wachtwoord. Dit is vragen om een beveilingslek terwijl het amper nut heeft. "security by obscurity" is echt een k**te-manier om met wachtwoorden om te gaan.

Gelukkig kiest TS voor een goede oplossing.

[RobIII]

Rekcor schreef op maandag 01 augustus 2011 @ 11:57:
Nog een beveiligingsvraag

Die kan prima in je huidige topic

[engelbertus]

Coca-Cola schreef op maandag 01 augustus 2011 @ 11:55:
[...]


Sorry hoor, ik weet precies hoe hashes werken, lees het topic anders nog even goed door. Ik draag (meer ter informatie dan als oplossing) een FUZZY hashing algoritme aan dat daadwerkelijk wordt gebruikt om strings te vergelijken op kleine afwijkingen (namelijk voor NEAR DEDUPLICATION van data). Zo'n hash bestaat dus uit gedeeltes van hashes. Als ik jouw wachtwoord in X karakters opsplits, elke X hash en daar stukjes uit ga halen en weer aan elkaar ga plakken, dan is die hash dus een stuk makelijker te 'kraken' dan 1 hash over het hele wachtwoord (althans, het is makelijker om een wachtwoord te vinden dat dezelfde hash oplevert, je weet nooit of je ook echt het orginele wachtwoord hebt gevonden, maar dat is ook niet meer nodig dan)

laten we proberen hier iets mee te doen, en de langte van een deel van een wachtwoord te maximaleiseren op 4 tekens.

van alle mogelijkheden die je dan krijgt kun je een rainbowtable maken. dan kun je bij wijze van spreken gewoon het wachtwoord "opzoeken" voor alle combinaties van letters. je vind dan dus al alle letters die in je wachtwoord zitten.

immers de hash van 1 of 2 of 3 of 4 losse tekens zal nooit overeenkomen met een hash van een andere combinatie van 1, of 2 of 3 of 4 andere losse tekens.

[Gomez12]

engelbertus schreef op maandag 01 augustus 2011 @ 11:59:
[...]
dus als je ëigenschappen van een wachtwoord 1234 is zoals in mijn voorbeeld. en je stelt dat het op twee punten moet afwijken dan kunnen mensen een gelijkend wachtwoord maken door hoofdletters in kleine letters te veranderen. het is echter onbekend of iemand dat ook daadwerkelijk heeft gedaan voor zijn nieuwe wachtwoord, of het cijfer en het speciale teken te vervangen of om te wisselen. bij een langer wachtwoord heb je dan dus niet bepaald dat ej de mogelijkheden voor een nieuw wachtwoord hebt gehalveerd. hoogstens ingekort met 25%. maar juist dat van die overige 75% nog wel alles mogelijk is, en niet bekend is welke 75% dat dan is, zorgt ervoor dat een hacker alsnog alle combinaties moet proberen.

Het gaat juist niet om de wijzigingen, dat geeft opzich zoals je zelf zegt niet zo veel info ( wel iets, maar in 1e instantie heb je andere problemen ). Het gaat om de info over het huidige wachtwoord...

Als ik weet dat het 1e karakter een hoofdletter is dan hoef ik al meer dan 50 procent van het bruteforcen niet meer te doen (en dat is nog maar met een heel beperkte karakterset van a-z,A-Z,0-9), weet ik dat het 2e karakter een cijfer is, dan zit ik al op iets in de richting van 75% wat ik niet meer hoef te bruteforcen.

Je definieert gewoon precies hoe je wachtwoord eruit ziet, en daarmee elimineer je zelf al iets van 90% van de mogelijkheden bij wachtwoorden groter dan 4. Een wachtwoord van 8 karakters is zo gevonden als je 90% kan elimineren...

[engelbertus]

ik ben het met je eens alwinuz, maar wat zou je dan nog wel willen opslaan van -oude- wachtwoorden ?

ik geef slechts info over eigenschappen van een oud wacxhtwoord, hetgeen echt vele malen minder is dan concrete informatie over een oud wachtwoord.

wat TS nu doet is inderdaad een stuk handiger, maar doet bijna niets van wat hij oorspronkelijk vroeg.

maar goed, anders was de enige mogelijke reactie op de vraag van TS "NIET DOEN!"

overigens is mijn "oplossing" niet securitie by obscurity" dat zou slechts gelden voor een ingewikkelde manier om de eigenschappen op te slaan.

ga zelf maar eens na wat een hacker kan. hij kan er slechts een bruteforce attack mee verkorten met 25% of zo. gesteld dat hij allerlei andere zaken goed heeft gegokt.

[Joolee]

Wat ook nog een optie is is om i.p.v. een hash van vaste partjes, een hash maken van ieder los karakter type:
mijnWachtw00rd=PietJe
mijn-W-achtw-00-rd-=-P-iet-J-e

Je hoeft niet op te slaan hoeveel karakters er in iedere hash zitten maar je kunt wel gemakkelijk vergelijken. Dan moet je natuurlijk niet iedere hash volledig op gaan slaan, anders is het alsnog makkelijk te kraken. Met zo weinig karakters is het zelfs eenvoudig als je een salt gebruikt.

[Coca-Cola]

engelbertus schreef op maandag 01 augustus 2011 @ 12:06:
[...]


laten we proberen hier iets mee te doen, en de langte van een deel van een wachtwoord te maximaleiseren op 4 tekens.

van alle mogelijkheden die je dan krijgt kun je een rainbowtable maken. dan kun je bij wijze van spreken gewoon het wachtwoord "opzoeken" voor alle combinaties van letters. je vind dan dus al alle letters die in je wachtwoord zitten.

immers de hash van 1 of 2 of 3 of 4 losse tekens zal nooit overeenkomen met een hash van een andere combinatie van 1, of 2 of 3 of 4 andere losse tekens.

Ik weet niet precies wat je probeert te bewijzen, dat het minder veilig is dat een normale salted hash is mij wel duidelijk. In ieder geval klopt je verhaal niet helemaal. Ik sla 4 karakters pers hash op (bv. de eerste vier) van een hash over N karakters (stel 4). De kans is best groot dat je met meerdere sets van 4 karakters dezelfde eerste 4 karakters van een de hash hebt (simpelweg omdat je meer keus in karakters hebt dan er keuze is aan karakters in de hash). Je weet als je zoekt naar een een hash met die 4 karakters dus niet welke exacte karakters zijn gebruikt in het wachtwoord, alleen dat het een set is die dezelfde begin karakters in een hash oplevert.

Overigens zou je 2 hashes op kunnen slaan, een normale salted hash ter security en een fuzzy hash ter vergelijking. Dat zou het in ieder geval een stuk moeilijker maken. Feit blijft dat er veel informatie over hte wachtwoord zit in een relatief zwakke hash (vooral in de kennis over hoe de hash verkregen is)

[engelbertus]

Gomez12 schreef op maandag 01 augustus 2011 @ 12:10:
[...]

Het gaat juist niet om de wijzigingen, dat geeft opzich zoals je zelf zegt niet zo veel info ( wel iets, maar in 1e instantie heb je andere problemen ). Het gaat om de info over het huidige wachtwoord...

Als ik weet dat het 1e karakter een hoofdletter is dan hoef ik al meer dan 50 procent van het bruteforcen niet meer te doen (en dat is nog maar met een heel beperkte karakterset van a-z,A-Z,0-9), weet ik dat het 2e karakter een cijfer is, dan zit ik al op iets in de richting van 75% wat ik niet meer hoef te bruteforcen.

Je definieert gewoon precies hoe je wachtwoord eruit ziet, en daarmee elimineer je zelf al iets van 90% van de mogelijkheden bij wachtwoorden groter dan 4. Een wachtwoord van 8 karakters is zo gevonden als je 90% kan elimineren...

het is niet zo dat het hele nieuwe wachtwoord moet afwijken van het hele oude wachtwoord. het hooft bijvoorbeeld slechts op 2 punten af te wijken. je weet niet welke 2 punten dat zijn. dus eigenlijk ëlimineer"je niks voor een bruteforceattack. je weet verder ook niet of het eerste teken een cijfer of letter is. dat staat er immers niet.
stel een code voor de eigenschappen van een wachtwoord is 1234, en voor elke positie zijn 10 mogelijkheden, en het nieuwe wachtwoord moet qua eigenschappen HELEMAAL afwijken dan weet je dus dat de nieuwe code voor de eigenschappen niet meer 1234 mag zijn. maar wel nog alle andere comibanties met 1,2,3 en 4

alwinuzz schreef op maandag 01 augustus 2011 @ 12:36:
@engelbertus, het is leuk om hier je hersens over te kraken. Maar in de praktijk moet je ontzettend oppassen met "slimme" oplossingen voor beveiliging. Het is makkelijker en veiliger om de domme oplossing te gebruiken.

dan is het met de eigenlijke set nog een stuk moeilijker, er zijn immers net zoveel hoofdletters als kleine letters, dan nog 10 cijfers en ik geloof nog wel 30 speciale tekens.


het obscuritie deel zou ik dus alleen toevoegen om er voor te zorgen dat men uit de code van de eigenschappen niet kan opmaken welke aanduideing betekent dat het een letter betreft.

van een set wachtwoorden die je op mijn manier zou coderen kun je immers bepalen welk eigenschap het meest voorkomt, en dat is dan waarschijnlijk de code voor letters. dan heb je inderdaad iets weggegeven aan een hacker

[ Voor 8% gewijzigd door engelbertus op 01-08-2011 12:40 ]

[djexplo]

Misschien een "relatief" goede oplossing:

1x. Vraag met web-formulier: Oude wachtwoord + Nieuw wachtwoord
Sla dan het oude-wachtwoord plain-text op in een zip-bestand, wat je beveiligt met het nieuwe wachtwoord.
2x . Vraag met web-formulier: Oude wachtwoord + Nieuw wachtwoord
Open met het oude wachtwoord de zip-file, en kijk of het nieuwe wachtwoord gelijk is aan het nog oudere wachtwoord. Maak dan een nieuw beveiligd zip-bestand met beide oude wachtwoorden.

[Joolee]

djexplo schreef op maandag 01 augustus 2011 @ 12:27:
Misschien een "relatief" goede oplossing:

[...]

Dan is wel een heel strak plan. Alleen zou ik het dan encrypted in een DB gooien en niet in een zip bestandje

[engelbertus]

je kutn de gebruiker natuurlijk ook vragen om al zijn vorige wachtwoorden en die vergelijken met opgeslagen hashes. ;P

@cocacola.. als je inderdaad alleen een deel van een resulterende hash opslaat dan weet je inderdaad niets als hackrer en zou je eventueel slechts een reeks combinaties kunnen maken die dezelfde deelhash oplevert

echter, omdat een wachtwoord zo kort is, word die reeks niet heel erg lang, en mijn verwachting is dat die reeks alsnog unieke hashes oplevert, die je dus zou kunnen achterhalen door rainbowtabels te gebruiken.

[alwinuzz]

@engelbertus, het is leuk om hier je hersens over te kraken. Maar in de praktijk moet je ontzettend oppassen met "slimme" oplossingen voor beveiliging. Het is makkelijker en veiliger om de domme oplossing te gebruiken.

[Not Pingu]

Coca-Cola heeft opzich wel een goed idee, maar weet niet helemaal waar de klepel hangt

Wat je zou kunnen doen is het password gewoon hashen, en daarnaast een hash opslaan van het wachtwoord waarop een aantal operaties zijn losgelaten die de schrijfwijze minder belangrijk maken, zoals:
- alles lowercase
- leestekens eruit
- cijfers eruit of vervangen door een letter die er in het l33t alfabet op lijkt
- andere bewerkingen voortkomend uit kennis over gebruik van wachtwoorden

Dan pas je dezelfde bewerkingen toe op het nieuwe wachtwoord, je hasht het resultaat daarvan en vergelijkt dat met de bewerkte hash van het oude wachtwoord.

[Voutloos]

Je hasht met een reden: zodat het originele wachtwoord niet goedkoop achterhaald kan worden. En dit zou nog steeds op moeten gaan als de hash bekend is. Op dit punt gaat het algoritme van Coca-Cola echt finaal in vlammen op, want het is daarbij goedkoop om substrings te bruteforcen.

TL:DR : Gebruik dit algoritme aub nooit. Nee, geen gemaar, nooit.

Not Pingu schreef op maandag 01 augustus 2011 @ 12:52:
Dan pas je dezelfde bewerkingen toe op het nieuwe wachtwoord, je hasht het resultaat daarvan en vergelijkt dat met de bewerkte hash van het oude wachtwoord.

Dit is om precies dezelfde redenen een slecht idee. Bij dit algoritme kan je eerst bruteforcen met een veel beperkter set karakters.

[ Voor 36% gewijzigd door Voutloos op 01-08-2011 12:55 ]

[engelbertus]

dat klopt. ik type dit ook voor "n theorie" niet voor in de praktijk. dus voor het theoretisch geval (bijvoorbeeld TS) toch zoiets zou willen controleren.

je ontkomt er dan niet aan om toch "iets" op te slaan. de oplossing zoals met zipfie is ook wel erg slim bedacht.
plain text, of op een andere manier opgeslagen wachtwoorden geven iets weg, je sloeg het op om eigenschappen van een wachtwoord te kunnen vergelijken, om te voorkomen dat het makkelijk werd een logische reeks te ontdekken ( met het blote oog) in een rijtje wachtwoorden. het leek mij daarom beter om dan meteen de eigenschappen die werden getest, op te slaan, daarmee geef je MINDER info over een wachtwoord prijs dan wanneer je een wachtwoord op een of andere manier zelf opslaat ( al dan niet gehashed of encrypted, op een manier dat je nog wel kunt zien wat de eigenschappen zijn, die heb je immers nog steeds nodig)

in mijn oplossing ontdoe je de opgeslagen data juist van alle concrete informatie over een paswoord.en heb je alleen de te testen gegevens nog over.
daarom zei ik ook dat het belangrijk was om te weten wat "lijkt op" in deze zou betekenen en hoe dat wordt getest. dat je dan op gaat slaan welke postities welke type teken is, is "slechts" 1 soort eigenschappen.

en als je dat dan wel zo zou doen, geef je nog steeds nagenoeg niets weg aan een hacker. omdat de menier van opslaan van de eigenschappen obscuur kan zijn, maar ook omdat niet duidelijk is welke tekens zouden zijn veranderd in het nieuwe wachtwoord, wat dus inhoud dat je als hacker geen enkel teken op geen enkele positie kunt elimineren. dat is mijn punt. je kunt niets slimineren, en dat was volgens andere mensen juist wel zo. pas als je eist dat elk teken van een nieuw wachtwoord van een ander type moet zijn, kun je iets elimineren.


ik denk dat het in de praktijk niet zo heel erg zinvol is om 3 wachtwoorden terug te controleren. het is belangrijker een wachtwoord te hebben dat niet bekend is bij iemand anders, niet in een dictionary voorkomt, en niet te kort voor bruteforcen.
je moet het niet in plaintext opslaan. want dan krijg je sony/PSN achtige taferelen, en dat wil je natuurlijk echt niet.

[engelbertus]

Not Pingu schreef op maandag 01 augustus 2011 @ 12:52:
Coca-Cola heeft opzich wel een goed idee, maar weet niet helemaal waar de klepel hangt

Wat je zou kunnen doen is het password gewoon hashen, en daarnaast een hash opslaan van het wachtwoord waarop een aantal operaties zijn losgelaten die de schrijfwijze minder belangrijk maken, zoals:
- alles lowercase
- leestekens eruit
- cijfers eruit of vervangen door een letter die er in het l33t alfabet op lijkt
- andere bewerkingen voortkomend uit kennis over gebruik van wachtwoorden

Dan pas je dezelfde bewerkingen toe op het nieuwe wachtwoord, je hasht het resultaat daarvan en vergelijkt dat met de bewerkte hash van het oude wachtwoord.

lost dat iets op? een hash lijkt nooit op een andere hash als het goed is, dus ook de hash van fiets en fi3ts en fi4ts en lijken niet op elkaar, en op basis van een hash op basis van een aangepast wachtwoord kun je nog steeds niet concluderen dat het een op het ander lijkt.

[Not Pingu]

engelbertus schreef op maandag 01 augustus 2011 @ 12:56:
[...]


lost dat iets op? een hash lijkt nooit op een andere hash als het goed is, dus ook de hash van fiets en fi3ts en fi4ts en lijken niet op elkaar, en op basis van een hash op basis van een aangepast wachtwoord kun je nog steeds niet concluderen dat het een op het ander lijkt.

Daarom bewerk je het wachtwoord ook en hash je dat. Zo zie je in elk geval of iemand hetzelfde wachtwoord weer gebruikt maar dan met andere casing. En de wachtwoorden worden toch veilig opgeslagen.

Voutloos schreef op maandag 01 augustus 2011 @ 12:53:
Je hasht met een reden: zodat het originele wachtwoord niet goedkoop achterhaald kan worden. En dit zou nog steeds op moeten gaan als de hash bekend is. Op dit punt gaat het algoritme van Coca-Cola echt finaal in vlammen op, want het is daarbij goedkoop om substrings te bruteforcen.

TL:DR : Gebruik dit algoritme aub nooit. Nee, geen gemaar, nooit.

[...]
Dit is om precies dezelfde redenen een slecht idee. Bij dit algoritme kan je eerst bruteforcen met een veel beperkter set karakters.

Maar dan weet je nog niet wat het originele wachtwoord nou was.

[ Voor 36% gewijzigd door Not Pingu op 01-08-2011 12:58 ]

[Rekcor]

RobIII schreef op maandag 01 augustus 2011 @ 12:03:
[...]

Die kan prima in je huidige topic

Mmm... hij gaat nu wel ten onder in de discussie over die hashes...

[Rekcor]

Over dat bruteforcen: Ik heb nu gewoon

PHP:

sleep (1);

toegevoegd in het test-het-wachtwoord-script. Dat maakt het bruteforcen m.i. een stuk minder interessant...

[Voutloos]

Not Pingu schreef op maandag 01 augustus 2011 @ 12:58:
[...]


Daarom bewerk je het wachtwoord ook en hash je dat. Zo zie je in elk geval of iemand hetzelfde wachtwoord weer gebruikt maar dan met andere casing. En de wachtwoorden worden toch veilig opgeslagen.

NEEHEE. Op die manier hashen is een slecht idee, zelfs al doe je het enkel voor de historische data.

En historische data herleidbaar bewaren (zelfs al is het beveiligd met huidige wachtwoord) is ook een slecht plan: Zodra het huidige wachtwoord gelekt/gelogt/gekraakt wordt verklap je in een keer de oude wachtwoorden, en daarmee zet je een heel sneeuwbal effect mee in werken als gebruiker wachtwoorden hergebruikt. Ja, dat moeten gebruikers niet doen, maar dat betekent nog niet dat jij de gebruiker in deze kan beschermen van meer schade.

Rekcor schreef op maandag 01 augustus 2011 @ 13:00:
Over dat bruteforcen: Ik heb nu gewoon

PHP:

sleep (1);

toegevoegd in het test-het-wachtwoord-script. Dat maakt het bruteforcen m.i. een stuk minder interessant...

NEEHEEHEEHEE.

Als je er van uit gaat dat de aanvaller het systeem kent (Kerckhoffs's Principle / Shannon) kan de aanvaller dus bruteforcen zonder die sleep(). Het kan dan alsnog in je eigen code prima zijn, maar je beveiliging mag dus niet van een sleep() afhangen.

offtopic:
Holy shit, wat komen de onveilige ideeen hier in rap tempo langs. Praktisch iedereen hier mag eerst ff wat literatuur op dit vlak gaan lezen ipv hier lopen blaten.

[ Voor 5% gewijzigd door Voutloos op 01-08-2011 13:05 ]

[engelbertus]

Not Pingu schreef op maandag 01 augustus 2011 @ 12:58:
[...]


Daarom bewerk je het wachtwoord ook en hash je dat. Zo zie je in elk geval of iemand hetzelfde wachtwoord weer gebruikt maar dan met andere casing. En de wachtwoorden worden toch veilig opgeslagen.


[...]
[...]
Maar dan weet je nog niet wat het originele wachtwoord nou was.

dan kun je gaan bruteforcen met alleen kleine letters en bereik je het tegenovergestelde van salting?

[engelbertus]

Voutloos schreef op maandag 01 augustus 2011 @ 13:04:
[...]
NEEHEE. Op die manier hashen is een slecht idee, zelfs al doe je het enkel voor de historische data.

En historische data herleidbaar bewaren (zelfs al is het beveiligd met huidige wachtwoord) is ook een slecht plan: Zodra het huidige wachtwoord gelekt/gelogt/gekraakt wordt verklap je in een keer de oude wachtwoorden, en daarmee zet je een heel sneeuwbal effect mee in werken als gebruiker wachtwoorden hergebruikt. Ja, dat moeten gebruikers niet doen, maar dat betekent nog niet dat jij de gebruiker in deze kan beschermen van meer schade.


[...]
NEEHEEHEEHEE.

Als je er van uit gaat dat de aanvaller het systeem kent (Kerckhoffs's Principle / Shannon) kan de aanvaller dus bruteforcen zonder die sleep(). Het kan dan alsnog in je eigen code prima zijn, maar je beveiliging mag dus niet van een sleep() afhangen.

offtopic:
Holy shit, wat komen de onveilige ideeen hier in rap tempo langs. Praktisch iedereen hier mag eerst ff wat literatuur op dit vlak gaan lezen ipv hier lopen blaten.

plus, als de gebruiker dezelfde wachtwoorden op andere sites gebruikt, en de aanvaller weet ook maar een klein beetje over de gebruiker die hij aanvalt, dan is de gebruiker opeens bij andere sites ook erg kwetsbaar geworden.

[Rekcor]

Voutloos schreef op maandag 01 augustus 2011 @ 13:04:
NEEHEEHEEHEE.

Als je er van uit gaat dat de aanvaller het systeem kent (Kerckhoffs's Principle / Shannon) kan de aanvaller dus bruteforcen zonder die sleep().

Dit snap ik niet. Hoe zou dit dan moeten doen?

[Voutloos]

Rekcor schreef op maandag 01 augustus 2011 @ 13:08:
[...]


Dit snap ik niet. Hoe zou dit dan moeten doen?

Als ik de hash heb, ga ik wel op mijn eigen bak (botnet ) hashen ipv in jouw vertraagde script. Bijkomend voordeel is dan dat jij niet kan loggen dat ik aan het bruteforcen ben.

^ Term: Offline vs Online bruteforcing

[ Voor 5% gewijzigd door Voutloos op 01-08-2011 13:11 ]

[engelbertus]

Rekcor schreef op maandag 01 augustus 2011 @ 13:08:
[...]


Dit snap ik niet. Hoe zou dit dan moeten doen?

als iemand een server is binnengedrongen, de aanwezige code en database heeft beachtigd, dan kan die ook de code wijzigen, of op zijn eigen machine draaien misschien. dan kan die ook gewoon die sleep er uit knippen en vervolgens je database ontcijferen

[alwinuzz]

Rekcor schreef op maandag 01 augustus 2011 @ 11:57:
Nog een beveiligingsvraag: in mijn webapplicatie (in PHP/MySQL) moeten gebruikers sinds kort een lang/veilig wachtwoord kiezen. De gebruikers klagen hierover, omdat ze per dag erg vaak inloggen op het systeem.

Nu vroeg ik me af: als ik een hash van (de eerste 3-5 tekens van het wachtwoord + het ip-adres) opsla, hoe veilig is het dan om de gebruiker de mogelijkheid te geven om vanaf dat bekende ip-adres (d.w.z. het ip-adres van de pc op het kantoor, wat beveiligd is d.w.z. je komt er niet zomaar binnen) om met de eerste 3 tekens van het wachtwoord in te loggen?

Als men buiten het kantoor (bijv. vanaf thuis, in de trein, etc) in wil loggen, dan moet het met het lange wachtwoord.

En natuurlijk: het lange wachtwoord is altijd veiliger, maar dat wil men nu eenmaal niet.

Alternatief: bij een computer op kantoor is de login-timeout veel langer (uren ipv minuten).

Maar hoe bepaal je betrouwbaar (betrouwbaar genoeg) dat het een kantoor-pc is? Is het zo simpel als een IP whitelist, of zie iets over het hoofd?

[engelbertus]

als mensen veel moeten inloggen, vergeet men het toch niet snel, en is het snel aangeleerd ? veel moeten gebuiken is in dat opzicht een voordeel. ik heb juist moeite met digid, dat hoeft niet heel lang, maar ik gebruik het slechts 2 keer per jaar. en elke keer moet ik heeel goed nadenken. ook handig is dat dat soort sites vaak net iets afwijkende eisen aan je wachtwoord stellen, en je om die reden ook later moeilijk nog kunt bbedenken hoe je je wachtwoord ook weer hebt samengesteld, vooral als er op het loginscherm ( anders dan het aanmeldscherm) niet staat welke eisen het ook weer waren. want 3 keer fout is nieuwe aanvragen.... lang wachten, en dat is nog iritanter. moetje later nog weer tijd vrij maken om dat stomme klusje te doen.

een ip adres is volgens mij ook helemaal niet zo veilig, die kun je spoofen etc?

[Rekcor]

Voutloos schreef op maandag 01 augustus 2011 @ 13:10:
[...]
Als ik de hash heb, ga ik wel op mijn eigen bak (botnet ) hashen ipv in jouw vertraagde script. Bijkomend voordeel is dan dat jij niet kan loggen dat ik aan het bruteforcen ben.

^ Term: Offline vs Online bruteforcing

Ja maar dan zit jij toch nog niet in 'mijn' systeem? Wat heeft het voor zin om buiten mijn systeem te gaan hashen? Je wilt uiteindelijk toch weten of 'mijn' systeem jouw hash leuk vindt.

Overigens:

Contrary to previous posts, sleep provides not security whatsoever against crackers. They can quite easily create a multithreaded program that will try 1000 passwords at a time effectively disabling your sleep pause, and sessions don't help as each a request can make itself look like a new session. The only way to make this effective at all is to store the last time a user attempted to login in a database and onyl allow x tries per time period.
http://theserverpages.com/php/manual/en/function.sleep.php

engelbertus schreef op maandag 01 augustus 2011 @ 13:10:
[...]


als iemand een server is binnengedrongen, de aanwezige code en database heeft beachtigd,

Tsja, als hem dat is gelukt, heeft het nauwelijks zin meer om in nog in 'mijn' systeem in te breken...

[Gomez12]

Rekcor schreef op maandag 01 augustus 2011 @ 13:00:
Over dat bruteforcen: Ik heb nu gewoon

PHP:

sleep (1);

toegevoegd in het test-het-wachtwoord-script. Dat maakt het bruteforcen m.i. een stuk minder interessant...

Tja, en ik verhoog dan gewoon het aantal concurrent tries naar 100.000 zodat ik 1 sec last heb van jouw sleep, daarna wordt het opgevangen door eerdere tries die nu vrij komen...

Dat jouw servertje dan ietwat meer staat te roken da's niet mijn probleem.

[Coca-Cola]

offtopic:
Holy shit, wat komen de onveilige ideeen hier in rap tempo langs. Praktisch iedereen hier mag eerst ff wat literatuur op dit vlak gaan lezen ipv hier lopen blaten.

offtopic:
Mag ik, misschien ten overvloede even vermelden, dat ik al vanaf de allereerste post heb aangegeven dat het echt niet veilig is? Mijn enige reden voor die post was omdat iemand zei dat je op basis van een hash geen vergelijkingen kon doen om te bepalen of woorden op elkaar lijken

[Rekcor]

Gomez12 schreef op maandag 01 augustus 2011 @ 13:16:
[...]

Tja, en ik verhoog dan gewoon het aantal concurrent tries naar 100.000 zodat ik 1 sec last heb van jouw sleep, daarna wordt het opgevangen door eerdere tries die nu vrij komen...

Dat jouw servertje dan ietwat meer staat te roken da's niet mijn probleem.

Ik snap, dan gaat mijn servertje down, wat niet leuk is. Maar dan ben jij nog steeds niet binnen .

[Voutloos]

Coca-Cola schreef op maandag 01 augustus 2011 @ 13:17:
[...]

offtopic:
Mag ik, misschien ten overvloede even vermelden, dat ik al vanaf de allereerste post heb aangegeven dat het echt niet veilig is? Mijn enige reden voor die post was omdat iemand zei dat je op basis van een hash geen vergelijkingen kon doen om te bepalen of woorden op elkaar lijken

Als het niet veilig kan, kan het dus niet.

[Gomez12]

alwinuzz schreef op maandag 01 augustus 2011 @ 13:10:
[...]


Alternatief: bij een computer op kantoor is de login-timeout veel langer (uren ipv minuten).

Maar hoe bepaal je betrouwbaar (betrouwbaar genoeg) dat het een kantoor-pc is? Is het zo simpel als een IP whitelist, of zie iets over het hoofd?

Hangt ervanaf hoeveel controle je over die pc's hebt...

Je kan een combinatie van ip-adres en browser-string oid doen.

[engelbertus]

Rekcor schreef op maandag 01 augustus 2011 @ 13:16:
[...]


Ja maar dan zit jij toch nog niet in 'mijn' systeem? Wat heeft het voor zin om buiten mijn systeem te gaan hashen? Je wilt uiteindelijk toch weten of 'mijn' systeem jouw hash leuk vindt.

Overigens:


[...]


[...]


Tsja, als hem dat is gelukt, heeft het nauwelijks zin meer om in nog in 'mijn' systeem in te breken...

je vergeet even dat in je database misschien de data geencrypt kan zijn, zodat het achterhalen van een username/password, ook na het hacken van je server nog zeker zinvol is. waarom zou je ander je passwords niet als plaintext mogen opslaan? die kan iemand pas lezen als hij al binnen is.

iemand die op zijn eigen bak verder werkt om een password te vinden, heeft natuurlijk op een gegeven moment een positief resultaat. dan heeft ie dus een goed wachtwoord te pakken en logt ie alsnog gewoon met een wachtwoord in op jou bak. je hebt dan geen eens door dat er iets raars gebeurd is op jou machine, terwijl een van je gebruikers "gehacked" is.

[ Voor 19% gewijzigd door engelbertus op 01-08-2011 13:22 ]

[Low-Tech]

offtopic:
Misschien een idee om hier een Thematopic van te maken? Er wordt hier veel besproken wat geldt voor algemene beveiliging en niet zozeer de vraag van de TS. Sowieso is het opslaan van gebruikerswachtwoorden inclusief policy en beveiliging tegen (brute force) hacking altijd een veel bewogen onderwerp van discussie merk ik.

[engelbertus]

btw, als het eenvoudig, simpel en doeltreffend mogelijk was om tot x wachtwoordem terug te kunnen vergelijken met een nieuw wachtwoord, wat op zich effectief zou zijn tegen makkelijk te raden wachtwoorden, dan zou dat wel standaard door MS worden aangeboden.

daaruit blijkt dat dit blijkbaar niet kan zonder andere beveiligingsissues te introduceren, die nog onwenselijker zijn dan een wachtwoord dat op een oud wachtwoord zou lijken.

dus wat dat betreft : het kan niet op een veilige manier.

[coldasice]

Coca-Cola schreef op maandag 01 augustus 2011 @ 11:26:
[...]


Het komt er op neer dat je een hash per sectie van een woord (of eigenlijk gebruik je het normaal voor hele files, maar zou ook op woord delen moeten kunnen werken) en dat je een stukje van die hash opslaat als onderdeel van je uiteindelijke hash. Vervolgens maak je een nieuwe hash van het nieuwe wachtwoord en vergelijkt op hoeveel punten het verschilt van de hash van het vorige password. Als dit maar op 1 punt is dan is het wachtwoord bijna hetzelfde als het vorige.

offtopic:
My => 8466fa8e428bf83c4d2d9893b4bada64
Pa => a13df921d517c3e3508b5a752a79d53b
ss => 3691308f2a4c2f6983f2880d32e29c84
wo => e0a0862398ccf49afa6c809d3832915c
rd => eeec033a2c4d56d7ba16b69358779091
01 => 96a3be3cf272e017046d1b2674a52bd3

Final Hash:
8466a13d3691e0a0eeec96a3

New password:
My => 8466fa8e428bf83c4d2d9893b4bada64
Pa => a13df921d517c3e3508b5a752a79d53b
ss => 3691308f2a4c2f6983f2880d32e29c84
wo => e0a0862398ccf49afa6c809d3832915c
rd => eeec033a2c4d56d7ba16b69358779091
02 => a2ef406e2c2351e0b9e80029c909242d

8466a13d3691e0a0eeeca2ef

Verschil van 1 sectie, dus password lijkt teveel. Nu ik er wat meer over nadenk, is dit voor dit soort toepassingen toch niet echt geschikt . Op grote files kan je markers nemen tot waar je hashed en dan kan je rekening houden met wijzigingen in of aan het begin van de file zodat die geen effect hebben op de totale fuzzy hash, hier kan iemand gewoon 1 karakter toevoegen aan het begin en het werkt niet meer goed, of je moet per karakter hashen, maar dan is het meer een encoding

Iemand die weet dat je afzonderlijke delen van een woord gaat hashen, kan dit natuurlijk heel makkelijk raden. Als ik weet dat je delen bestaat uit losse symbolen, hoef ik die alleen te vergelijken met de hash van alle losse symbolen

[ajakkes]

Stel de mogelijke tekens zijn 12 AB en ab. Ik vraag een wachtwoord van minimaal 12 tekens en het wachtwoord wordt dus zoiets als 1Aa2BbbAA1Bb. Nu ga ik iets toepassen om de eigenschappen van mijn wachtwoord op te slaan. Bijvoorbeeld delen hashen. Ik krijg dan zoiets als
1A
a2
Bb
bA
A1
Bb

Ik hoef nu dus alleen nog maar een rainbow table te maken van alle 2 karaktercombinaties. Deze tabel is vele male korter dan een rainbowtable van alle combinaties van 12 karakters. Elk ander algoritme dat hier genoemd is om eigenschappen te hashen heeft dit nadeel. Zoiets als lowercaps en L33t conversie wordt mijn wachtwoord aaabbbbaaabb. Er blijven erg weinig 12 lettercombinaties over. Als dit slechts wordt gebruikt om informatie op te slaan hoef ik voor ieder karakter nog maar 3 keer te bruteforsen. Het eerste karakter kan immers alleen nog 1 A of a zijn.

Als je mijn oude wachtwoorden gaat opslaan en van mij verwacht dat ik iedere 3 maanden een nieuwe kies kan je er vergif op innemen dat bij een groot aantal gebruikers 1 van de oude wachtwoorden nog op veel andere lokaties gebruikt word. De gebruiker gaat er dan ten onrechte van uit dat het wachtwoord dat hij bij jou gewijzigd heeft bij het stelen van jouw database nog veilig is. Hij moet dus op alle lokaties alle wachtwoorden die hij ooit bij jou gebruikt heeft gaan wijzigen.

Als op een interne pc mijn wachtwoord uit de eerste 3 karakters bestaat en de rest uit eigenschappen van de pc waar ik achter zit moet je wel heel zeker weten dat de aanvaller niet deze eigenschappen kan overnemen. Kan hij doormiddel van een virus of mallware de inlogprocedure vanaf de interne pc uitvoeren?

Bijkomend nadeel is dat de gebruiker die ene keer dat hij het wachtwoord op een andere lokatie nodig heeft bijna zeker het wachtwoord niet meer weet. En als de gebruiker het relatief lange wachtwoord 25 keer per dag moet intikken gaat dit op den duur veel sneller.

Een lange time-out is denk ik een simpelere en meer gebruikte procedure. De gebruiker hoeft achter dezelfde pc mits hij hiervoor kiest het wachtwoord nog maar 1 keer per 24 uur in te voeren. Het wachtwoord blijjft langer veilig omdat het minder vaak wordt verstuurd en als de iemand anders toegang heeft tot het systeem is dit na 24 uur verlopen. Terwijl bij ongemerkt achterhalen van het wachtwoord het wachtwoord 3 maanden lang door de hacker gebruikt kan worden.

Van belang is wel dat de gebruiker een time-out periode kiest waarin hij verwacht zelf bezig te zijn en er geen anderen toegang hebben tot de pc of dat hij binnen de time-out zelf uitlogged om het risico zoveel mogelijk te beperken.

Nog een nadeel van het opslaan van wachtwoorden: Ik heb nog nooit iemand hoeven helpen die webmail gebruikt als regelmatige email client (omdat deze meermalen per week wordt ingevuld) en zeer regelmatig mensen met outlook express als client moeten helpen omdat ze het ingewikkelde wachtwoord 2 jaar geleden 1 keer hadden ingevuld en nu echt niet meer weten wat ze toen bedacht of aangeboden hadden gekregen.

[Rekcor]

@ajakkes: Jij zegt goede dingen, bedankt! Eigenlijk is beveiliging meer psychologie dan IT...

[GlowMouse]

* veilige oplossing heeft

djexplo schreef op maandag 01 augustus 2011 @ 10:59:
Een standaard wachtwoord formulier vraag altijd :
Bestaand Wachtwoord
Nieuw Wachtwoord
Herhaling Nieuw Wachtwoord

Of te wel als je dat gebruikt, heb je opdat moment een niet versleuteld versie van zijn oude wachtwoord.

Als je dit hebt, kun je het wachtwoord gebruiken om een lijstje met meerdere oude wachtwoorden mee te encrypten.

Om te testen op mate van verschil, kun je bijvoorbeeld alles converteren naar lowercase en dan de Levenshtein distance pakken.

[F.West98]

Coca-Cola schreef op maandag 01 augustus 2011 @ 11:55:
[...]


Sorry hoor, ik weet precies hoe hashes werken, lees het topic anders nog even goed door. Ik draag (meer ter informatie dan als oplossing) een FUZZY hashing algoritme aan dat daadwerkelijk wordt gebruikt om strings te vergelijken op kleine afwijkingen (namelijk voor NEAR DEDUPLICATION van data). Zo'n hash bestaat dus uit gedeeltes van hashes. Als ik jouw wachtwoord in X karakters opsplits, elke X hash en daar stukjes uit ga halen en weer aan elkaar ga plakken, dan is die hash dus een stuk makelijker te 'kraken' dan 1 hash over het hele wachtwoord (althans, het is makelijker om een wachtwoord te vinden dat dezelfde hash oplevert, je weet nooit of je ook echt het orginele wachtwoord hebt gevonden, maar dat is ook niet meer nodig dan)

Wat je dan kan doen is: vergelijking maken met oude wachtwoord bij nieuw wachtwoord (wat TS nu kiest), dan beide wachtwoorden die manier hashen, vergelijken, nieuwe wachtwoord-hash weggooien en er een gewone hash van maken en de oude wachtwoord manier-hash opslaan in andere tabel, en dan bij 3e wachtwoord manier-hash van nieuwe wachtwoord vergelijken met die uit tabel (1e) en de oude die je net invulde (ook hashen), enz

Dus:
3e x wachtwoord veranderen: (manier-hash is dus delen-ding zoals jij zegt)
User:
oude wachtwoord invullen
nieuwe wachtwoord invullen
server:
alle oudere (ouder dan oude wachtwoord in form) wachtwoorden uit tabel halen (manier-gehashed)
ingevulde wachtwoorden manier-hashen
alle manier-hashes vergelijken -> lijkt nieuwe wachtwoord teveel? opnieuw laten invullen door user
-> wachtwoord OK?
oude wachtwoord-manier-hash in tabel erbij zetten
nieuwe wachtwoord-manier-hash weggooien
nieuwe wachtwoord gewoon hashen en opslaan.

Zo weet jij zeker dat je kan vergelijken, en aangezien in tabel opgeslagen manier-hashes niet huidige wachtwoorden zijn en huidige wachtwoorden genoeg verschillen, (dus per letter hashen) kunnen hackers niets met de per-letter hash, die verschilt te veel van huidige wachtwoord die goed genoeg is gehashed, normaal nl.

[coldasice]

F.West98 schreef op maandag 01 augustus 2011 @ 15:04:

Zo weet jij zeker dat je kan vergelijken, en aangezien in tabel opgeslagen manier-hashes niet huidige wachtwoorden zijn en huidige wachtwoorden genoeg verschillen, (dus per letter hashen) kunnen hackers niets met de per-letter hash, die verschilt te veel van huidige wachtwoord die goed genoeg is gehashed, normaal nl.

maar hoe kom je aan de per letter hash van het oude wachtwoord als je daar alleen maar een complete hash van hebt?

edit: ik zie het al, op het moment dat je een nieuwe maakt, kun je de oude per letter hashen.....

[ Voor 8% gewijzigd door coldasice op 01-08-2011 15:13 . Reden: nieuw inzicht ]

[F.West98]

coldasice schreef op maandag 01 augustus 2011 @ 15:11:
[...]


maar hoe kom je aan de per letter hash van het oude wachtwoord als je daar alleen maar een complete hash van hebt?

die maakt ie als je het oude invult op formulier, complete hash staat in andere tabel, en wordt daarna if OK overschreven door nieuwe compleet-hash

Maar probleem met zelfde wachtwoord ergens anders blijft.

Je kan ook eenmalige inlogcodes gebruiken die worden geSMS't oid (maar dan wel van goede IP en van ander IP gewoon wachtwoord en geen eenmalige inlogcode)
oid of juist andersom

[ACM]

GlowMouse schreef op maandag 01 augustus 2011 @ 15:02:
Als je dit hebt, kun je het wachtwoord gebruiken om een lijstje met meerdere oude wachtwoorden mee te encrypten.

Yep. Maar zoals Voutloos hierboven al aangeeft zorgt het er wel voor dat als het huidige wachtwoord gekraakt wordt, dat je dan alsnog ook de historie prijsgeeft. Je zou natuurlijk alvast de afgeleide versie (lowercased, e.d.) kunnen opslaan, zodat je het iets lastiger maakt. Maar alle case-variaties op een wachtwoord proberen is nou ook weer niet zo'n grote hoeveelheid.

Wat is eigenlijk de achterliggende gedachte dat het wachtwoord niet te veel mag lijken op de vorige en waarom moet het elke 3 maanden worden gewijzigd? Wordt het daar echt veiliger van?

Als je bang bent voor afluisteren van verkeer moet je daar SSL voor inzetten. Als je bang bent dat specifieke accounts gekraakt worden vraag ik me af wat het risico is dat dat niet triviaal herhaald kan worden nadat het wachtwoord aangepast was.
Pas vooral op dat je mensen niet naar post-its op hun scherm jaagt, omdat het anders te lastig is een wachtwoord te onthouden (hoewel daar natuurlijk tegenwoordig tools als KeepassX voor bestaan).

[Rekcor]

ACM schreef op maandag 01 augustus 2011 @ 15:39:
Wat is eigenlijk de achterliggende gedachte dat het wachtwoord niet te veel mag lijken op de vorige en waarom moet het elke 3 maanden worden gewijzigd? Wordt het daar echt veiliger van?

Dat zijn goede vragen. Ik had eigenlijk aangenomen dat het natuurlijk veiliger is (omdat het bij al mijn werkgevers tot nu toe gebeurde).

Overigens verloopt e.e.a. al via HTTPS nu.

[ Voor 4% gewijzigd door Rekcor op 01-08-2011 16:13 ]

[MSalters]

Het is aantoonbaar onveiliger. De reden voor password roulatie is meer om de schade van gedeelde wachtwoorden te beperken. Je nieuwe collega die tijdens jouw vakantie jouw password gebruikt, bijvoorbeeld, die heeft 3 maanden later alleen je vorige password.

[Remus]

Rekcor schreef op maandag 01 augustus 2011 @ 16:13:
[...]

Dat zijn goede vragen. Ik had eigenlijk aangenomen dat het natuurlijk veiliger is (omdat het bij al mijn werkgevers tot nu toe gebeurde).

Overigens verloopt e.e.a. al via HTTPS nu.

Over het algemeen zorgen complexe password regels er juist voor minder veiligheid agv de invloed op de psychologie van de gebruiker. Gebruikers gefrustreerd, en schrijven ze wachtwoorden op, omdat ze dergelijke wachtwoorden niet kunnen onthouden etc.

Daarnaast wordt er vaak voor het afdwingen van regels technische onveiligheden geintroduceerd zoals het plaintekst of encrypted (ipv hashed) opslaan van een historie aan wachtwoorden om regels af te dwingen als 'je mag tig wachtwoorden niet hergebruiken', of zoals in dit topic 'je wachtwoord mag niet lijken op je tig vorige wachtwoorden'. Dit topic en sommige van de suggesties erin is het voorbeeld van wat je niet moet doen IMHO.

Als je data zo belangrijk is dat je een sterke beveiling nodig hebt, denk dan eerder aan een two-factor (of n-factor) authentication. Bijvoorbeeld een combinatie van een wachtwoord, een keyfob, een challenge/response met een e-identifier + smartcard, SSL client authentication, SMS login, iris-scan, vingerafdruk etc. Vaak zal je er dan achter komen dat je systeem helemaal niet zo belangrijk is dat het dergelijke draconische maatregelen vereist.

[Cartman!]

Wat ACM zegt klopt wel, wij zouden hier op t werk ook een policy krijgen waarbij je elke maand je password moest wijzigen en die mocht niet gelijk zijn aan de vorige 5 en moest minstens 2 speciale tekens hebben, x aantal hoofdletters en x aantal cijfers. Die meuk is gewoon niet te onthouden waardoor er al mensen begonnen met post-its. Die systeembeheerder werd daar boos op want dat was niet de bedoeling maar feit was dat hij zelf doorgeslagen was in zijn eisen. Nu kan ik gewoon elke 3 maanden wisselen tussen 2 passwords

Er is dus voor sommige regels wel wat voor te zeggen maar bedenk dat je het je gebruiker niet te moeilijk moet maken want dan gaan er dingen gebeuren die je niet meer met code kan oplossen (zoals dat mensen een post-it nodig hebben om het te onthouden).

[RobIII]

Ik vind 't ook nogal verschil maken tussen een beveiliging van de webshop van de fietswinkel op de hoek of de belastingdienst backend (om maar wat te roepen). Dat je gefrustreerd raakt van een twaalf tekens wachtwoord en op je sodemieter krijgt als je 't op een post-it zet is dan jammer in 't laatste geval: daar heb je je maar aan te conformeren. In 't eerste geval is 't doorgeslagen paranoia.

[Remus]

Cartman! schreef op maandag 01 augustus 2011 @ 16:33:
Wat ACM zegt klopt wel, wij zouden hier op t werk ook een policy krijgen waarbij je elke maand je password moest wijzigen en die mocht niet gelijk zijn aan de vorige 5 en moest minstens 2 speciale tekens hebben, x aantal hoofdletters en x aantal cijfers. Die meuk is gewoon niet te onthouden waardoor er al mensen begonnen met post-its. Die systeembeheerder werd daar boos op want dat was niet de bedoeling maar feit was dat hij zelf doorgeslagen was in zijn eisen. Nu kan ik gewoon elke 3 maanden wisselen tussen 2 passwords

De leukste die ik ooit heb meegemaakt (bij een Amerikaans bedrijf met vestigingen door heel Europa): Opeenvolgende tekens in je wachtwoord mogen niet naast elkaar voorkomen op het toetsenbord (zowel links/rechts als boven/beneden, inclusief de shift combinaties op de cijfer-regel).
Jammer dat die regel niet uit te leggen was aan gebruikers met een toetsenbord indelingen anders dan US-QWERTY, aangezien de regel gevalideerd werd tegen US QWERTY, wat natuurlijk niet werkt voor QWERTZ, AZERTY of een van de andere voorkomende indelingen met toetsen op een net andere plek.

En dat was slechts één van de regels waar je wachtwoord aan moest voldoen (er waren er 5 of meer). En heel veel sterke wachtwoorden voldeden niet(!) aan die regels. Waardoor je dan uiteindelijk maar ging voor de simpelste die werkte.

[Zoijar]

djexplo schreef op maandag 01 augustus 2011 @ 10:59:
Een standaard wachtwoord formulier vraag altijd :
Bestaand Wachtwoord
Nieuw Wachtwoord
Herhaling Nieuw Wachtwoord

Of te wel als je dat gebruikt, heb je opdat moment een niet versleuteld versie van zijn oude wachtwoord.

Zolang je die check dan client-side in script doet is het wel ok. Niet je wachtwoorden plain over de lijn sturen en het server-side doen.

[engelbertus]

het komt er dus op neer dat gebruikers eenmalig een achtwoord moeten kiezen dat niet te kort is.

wat maakt verder een sterk wachtwoord?
elke combinatie is toch theoretisch even sterk?

dat sterke wachtwoord heeft dus t emaken met psychologie, en dus de vraag of mensen wel doen wat gevraagd wordt, een combinatie kiezen uit alle beschikbare letters, cijfers en leestekens etcetera.


ik heb zon 15 jaar geleden van de hogeschool een code gekregen die ik bijna nooit gebruikte, maar die ik wel nog steeds uit mijn hoofd ken. een willekeurige reeks cijfers en letters van 8 tekens.

de regels voor een sterk wachtwoord zorgen er dus voor dat de mogelijke letters echt worden gebruikt zodat bruteforce niet kan volstaan met de kleine lettertjes.

dan heb je daarna nog dat mensen het wachtwoord op andere anieren kunnen achterhalen: afkijken, de postit note lezen, of er om vragen zodat in de vakantie toch nog iemand de mail in de gaten kan houden of noem maar op.

en daarnaast helpen sociale factoren zoals datums die je van iemand kent.

maar dan hebben we het dus over colegas en bekenden, en gaat het dus over of mensen wel de discipline hebben om een wachtwoord geheim te houden.

ëen hacker van buitenaf kan alleen maar uitgaan van bruteforce, en vind het dus fijn dat er oude pswords, of info erover wordt opgeslagen in de tabel. de collega heeft die niet nodig want die wist zelf al wat het oude wachtwoord van de collega is. het is dus het beste om een goed wachtwoord te hebben, bijvoorbeeld een echt random code, die mensen dan maar uit hun hoofd moeten leren. maar dan hoeft dat ook maar eenmalig. als mensen het dan nog op postitnotes zetten, of uitlenen, dan moet je daar tegen optreden met sancties.

als dat allemaal niet goed genoeg kan werken zijn idd chalenge response, systemen, of gewoon van die token/ apparaatjes een oplossing lijkt me. al zou een collega dan ook weer het wachtwoord kunnen afkijken etc. de tokens moten dus dan ook nog wel aan een gebruiker gekoppeld moeten worden, of nog voorzien zijn van bijvoorbeeld een pas met sleutel oid. die dus persoonlijk is. bij grote bedrijven lijkt me dat toepasbaar. scholen hebben al eigen toegangspassen, betaalsystemen etc. net zo als supermarkten passen hebben, en overheden,
overige bedrijven hebben ook al vaak passen tbv toegangscontrole en tijdreistraie.
nu kun je nog discussieren over hoe wenselijk het is dat je op die manier zo traceerbaar wordt, maar feitelijk ben je op dat moment voor je baas aan het werk, die betaalt je salaris, en mag dan wel enige vorm van discretie en veiligheid eisen lijkt me.

[Rekcor]

Interessant artikel:

http://www.baekdal.com/tips/password-security-usability

en

http://www.baekdal.com/tips/the-usability-of-passwords-faq

De auteur beweert o.m. dat "this is fun" een beter wachtwoord is dan "Z$%sff$A"

[engelbertus]

klopt, het is 3 tekens langer

[ACM]

MSalters schreef op maandag 01 augustus 2011 @ 16:27:
Je nieuwe collega die tijdens jouw vakantie jouw password gebruikt, bijvoorbeeld, die heeft 3 maanden later alleen je vorige password.

Die situatie zou natuurlijk bij voorkeur uberhaupt niet nodig moeten zijn

RobIII schreef op maandag 01 augustus 2011 @ 16:36:
Dat je gefrustreerd raakt van een twaalf tekens wachtwoord en op je sodemieter krijgt als je 't op een post-it zet is dan jammer in 't laatste geval: daar heb je je maar aan te conformeren.

Er zijn maar weinig mensen die een volledig willekeurige reeks van 12 karakters kunnen onthouden. Als er een patroontje in zit, bijvoorbeeld door nepwoordjes erin te verwerken (bijv een "pronouncable password") dan wordt het alweer wat eenvoudiger. Maar als de password-policy zo veilig is dat je uiteindelijk gewoon je werk niet kan doen, dan is er alsnog wat mis met die policy
Dan moet je maar kijken of je het met meer dan alleen een wachtwoord kan realiseren.

Zoijar schreef op maandag 01 augustus 2011 @ 17:12:
Zolang je die check dan client-side in script doet is het wel ok. Niet je wachtwoorden plain over de lijn sturen en het server-side doen.

Dat lijkt me juist niet zo'n goed idee. Ten eerste zorg je er voor dat je de oude wachtwoorden opstuurt naar die gebruiker, en voor de juiste data-flow moet je dat eigenlijk al doen voor dat de verificatie van het bestaande wachtwoord is gedaan of de verificatiestap zelf 2x.
Daarnaast leg je een scripting-eis bij de client die op zich overbodig is met een normaal formulier.
Verder dwing je af dat je de wachtwoordversleuteling aan de client-side ligt, wat met moderne hashing-algoritmen op moderne browsers nog steeds veel trager is dan met native implementaties. En je dus eerder zal kiezen voor een relatief zwakke versleuteling. Bovendien vereis je dat alle benodigde aanvullende versleutelingsinformatie of challenge-response informatie, zoals salts, ook al op voorhand bij de login-procedure bekend moeten zijn.
En het is maar de vraag of het zoveel veiliger is als je toch al SSL gebruikt voor je datatransmissie. Het enige aanvullende voordeel dat je hebt is dat er nooit een moment op de server is waar het wachtwoord unhashed is.
En je zou het zelfs zo simpel kunnen maken dat uiteindelijk de hash uberhaupt genoeg is om in te kunnen loggen... (dus dat ie niet gebruteforced hoeft te worden, maar direct inzetbaar is).

[RobIII]

ACM schreef op maandag 01 augustus 2011 @ 17:43:
Er zijn maar weinig mensen die een volledig willekeurige reeks van 12 karakters kunnen onthouden. Als er een patroontje in zit, bijvoorbeeld door nepwoordjes erin te verwerken (bijv een "pronouncable password") dan wordt het alweer wat eenvoudiger. Maar als de password-policy zo veilig is dat je uiteindelijk gewoon je werk niet kan doen, dan is er alsnog wat mis met die policy
Dan moet je maar kijken of je het met meer dan alleen een wachtwoord kan realiseren.

Val nou effe niet over de details van die post (12 tekens); het gaat erom dat als er een "strenge" policy is dat 't dan meestal wel te verdedigen is (of moet zijn) wanneer de risico's hoog zijn en/of er veel op 't spel staat. Of 't dan 12 tekens of 8 is of...

Daarbij zijn wachtwoorden van 12 tekens, mits je bijv. een ezelsbruggetje kunt gebruiken, prima te doen. Onthoud gewoon (bijv.) een zin als: "Ik ben geboren in '77 en heb 1 broer en 1 zus" => ibgi77eh1be1z. (Crap, dat zijn er 13 ). Het is weer andere koek als je iedere X-tijd een wachtwoord voorgeschreven krijgt in de categorie "n$9o@E%8^07%".

Voor de rest eens met je post overigens hoor

[ACM]

Rekcor schreef op maandag 01 augustus 2011 @ 17:37:
Interessant artikel:

http://www.baekdal.com/tips/password-security-usability

en

http://www.baekdal.com/tips/the-usability-of-passwords-faq

De auteur beweert o.m. dat "this is fun" een beter wachtwoord is dan "Z$%sff$A"

Interessante redenatie. Voor online hacks is het idd ruim voldoende en zolang je netjes overal verschillende wachtwoorden gebruikt is het ook voor offline-hacks waar:
http://www.baekdal.com/ti...ity-reply-to-security-now

Zijn technische argumentatie klopt bij offline hacks echter niet helemaal. Salts maken bijvoorbeeld niet uit voor de complexiteit van het doorrekenen. Dus de brute-forceaanval wordt niet moeilijker van geen salt vs een salt van 20 willekeurige bytes.
Een salt voeg je toe om te voorkomen dat enerzijds mensen met hetzelfde wachtwoord dezelfde hash krijgen en anderzijds dat je een eenmaal gegenereerde hash kan hergebruiken om ze tegen meerdere verschillende wachtwoorden te houden (bijv dmv een rainbow table of het brute forcen van een lijst hashes).

Het maakt dus wel degelijk uit voor offline attacks of je een wachtwoord hebt dat effect uit maar 27 verschillende tekens bestaat, of een met een stuk meer. Als we voor het gemak aannemen dat ie met md5 is opgeslagen en ik alleen in dat wachtwoord geinteresseerd ben, dan kan ik op mijn GP-GPU-systeem er meer dan 5 miljard per seconde genereren! Oftewel, een 11-karakter wachtwoord van 27 tekens kost dan net geen 13 dagen. Je zou de q en x nog weg kunnen laten bij je eerste pogingen en het zo naar minder dan 6 dagen terugbrengen. Als ik niet weet of en hoeveel hoofdletters er zijn, dan wordt het al bijna 59 jaar met de huidige technologie en dezelfde brute force aanpak.

Als dat wachtwoord verder uniek voor dat gebruik is, dan is er verder weinig mee aan de hand. Maar zijn technische toelichting mbt salts is onzin
Een zwaardere hashing, bijv 5000x md5 herhalen maakt bovenstaande tijden natuurlijk al een stuk minder werkbaar. Als je dan ook nog een cryptografisch meer verantwoorde hash gebruikt (bijv >= sha256) en een methode waarbij de key-space niet verwaterd dan wordt het nog veel beter.

[ Voor 6% gewijzigd door ACM op 01-08-2011 18:13 ]

[Voutloos]

Er staan wel meer fouten in dat baekdal.com artikel, en t staat al een tijdje bij mij op de todo om eens compleet de grond in te boren. Maar het idee van een (niet al te obvious) zinnetje gebruiken is op zich prima.

[ Voor 15% gewijzigd door Voutloos op 01-08-2011 20:14 ]

[Rekcor]

Voutloos schreef op maandag 01 augustus 2011 @ 20:11:
Er staan wel meer fouten in dat baekdal.com artikel, en t staat al een tijdje bij mij op de todo om eens compleet de grond in te boren. Maar het idee van een (niet al te obvious) zinnetje gebruiken is op zich prima.

En als ik nu eens een woordenlijst download (http://www.zoefzoek.com/index.php?page=lijsten), het systeem 3 woorden laat kiezen, en per woord 1 teken laat veranderen?

fiets opgemerkt banaan

wordt dan bijv.

fieTs 0pgemerkt b@naan

Dus: het systeem genereert een gemakkelijk te onthouden, en tamelijk lang wachtwoord.

Low-Tech schreef op maandag 01 augustus 2011 @ 13:21:

offtopic:
Misschien een idee om hier een Thematopic van te maken? Er wordt hier veel besproken wat geldt voor algemene beveiliging en niet zozeer de vraag van de TS. Sowieso is het opslaan van gebruikerswachtwoorden inclusief policy en beveiliging tegen (brute force) hacking altijd een veel bewogen onderwerp van discussie merk ik.

Wat ik mooi zou vinden als conclusie op deze thread, is een kant-en-klaar beveiligingsscript in PHP/MySQL (en evt wat ports naar .NET, etc), wat voldoende veilig is voor de gemiddelde Willems Webshop. Dat scheelt misschien ook een hoop discussies/vragen in de toekomst.

[coldasice]

Voutloos schreef op maandag 01 augustus 2011 @ 20:11:
Er staan wel meer fouten in dat baekdal.com artikel, en t staat al een tijdje bij mij op de todo om eens compleet de grond in te boren.

Dit artikel snijdt echt wel hout en natuurlijk zijn er dingen ter verbetering maar roepen dat je dit wel even de grond in boort slaat nergens op. Om het wat constructiever te laten klinken: Ik denk dat iedereen meer geinteresseerd is in je aanbevelingen en verbeteringen.

[IceM]

Ik kan er overheen gelezen hebben maar er is toch wel een soort van oplossing voor dit probleem?

• Versleutel de laatste X wachtwoorden met een methode waarvan de encryptie key (een salt+hash van) het oude wachtwoord is
• Bij wijzigen ww vraag je om het oude en nieuwe wachtwoord en decrypt de laaste X wachtwoorden aan de hand van het opgegeven oude wachtwoord
• Test het nieuwe wachtwoord tegen de laatste X wachtwoorden bij succesvolle decryptie
• Als het nieuwe wachtwoord goed is versleutel je de laatste X wachtwoorden met (een salt+hash) van het nieuwe wachtwoord

Waarom je de gebruikers zo erg lastig moet vallen is een andere vraag...

[engelbertus]

als het echt zulke belangrijke info is, dan is het och ook egrg nuttig om bijvoorbeeld keycards te maken met een sterk wachtwoord, die dan ook persoonlijk is.dan vraag je de grbeuikers om eens in de zoveel tijd de keycard te updaten met een nieuw wachtwoord en klaar, hoeft er niks onthouden te worden, en kan de key zo lang zijn als je zelf wilt. zorg ervoor dat de readers de key niet in plain text versturenen dan is dat ook veilig zonder de gebruiker lastog te vallen
voor pcs zijn losse readers, of toetsenborden met readers
en voor andere zaken zijn ook readers voor bijvoorbeeld toegangscontrole.

ik neem namelijk aan dat wanneer elke 3 maanden weer een onmogelijk moeilijk paswoord gekozen moet worden als policy het ook wel om top secret stuff gaat, waarvan de beveiliging best iets mag kosten, iov de gebruikers met de ergernis op te zadelen en alle onveilige toestanden die gebruikers vervolgens kunnen besluiten te bedenken.

[Remus]

IceM schreef op dinsdag 02 augustus 2011 @ 23:23:
Ik kan er overheen gelezen hebben maar er is toch wel een soort van oplossing voor dit probleem?

• Versleutel de laatste X wachtwoorden met een methode waarvan de encryptie key (een salt+hash van) het oude wachtwoord is
• Bij wijzigen ww vraag je om het oude en nieuwe wachtwoord en decrypt de laaste X wachtwoorden aan de hand van het opgegeven oude wachtwoord
• Test het nieuwe wachtwoord tegen de laatste X wachtwoorden bij succesvolle decryptie
• Als het nieuwe wachtwoord goed is versleutel je de laatste X wachtwoorden met (een salt+hash) van het nieuwe wachtwoord

Waarom je de gebruikers zo erg lastig moet vallen is een andere vraag...

Omdat dat dat onveilige situaties geeft wanneer jouw database in verkeerde handen valt. Kraak je het laatste wachtwoord, dan beschik je vervolgens over een volledige password history van de gebruiker. En aangezien gebruikers nogal eens wachtwoorden hergebruiken (maak mijzelf daar ook wel eens schuldig aan), heb je dus potentieel direct toegang tot andere accounts van de gebruiker.

Eerlijkgezegd zijn dit soort password policies een wassen neus die alleen maar voor meer problemen zorgen dan dat ze oplossen.