Wachtwoordeisen

[stereohead]

Lieve Devvers,

Nu las ik net deze .plan: Analyse: zwakke wachtwoorden op Tweakers.net.

Ik blijk dus een slecht wachtwoord te hebben, en wou dit graag veranderen. Nu kwam ik erachter dat er tegenwoordig nogal wat eisen aan het wachtwoord worden gesteld.

Namelijk:

- Minimaal 8 tekens
Hier kan ik me in vinden, anders wordt Brute Force te makkelijk.

- Minimaal 1 hoofdletter,
Dit heeft maar weinig invloed op de sterkte van een wachtwoord, die ene hoofdletter staat toch bijna altijd op een voorspelbare plaats. Zoals jullie overigens zelf aangeven in het artikel.

- Minimaal 1 cijfer of speciaal teken.
Dit heeft tevens maar weinig invloed op de sterkte van een wachtwoord, want ook hierbij geld dat die bijna altijd op een voorspelbare plaats staat.

Wat helemaal raar is, is dat jullie aan het eind van het artikel de tip geven om een zinnetje van willekeurige woorden te gebruiken (ala "correct horse battery staple"). Maar zo'n wachtwoord wordt dus helemaal niet toegestaan!

Kortom. Het advies in het artikel, en de eisen aan het wachtwoord spreken elkaar tegen.

Concreet. Ik zou graag zien dat de eisen aan het wachtwoord opgeheven worden. Op misschien de minimale lengte na. Uiteindelijk is het toch de verantwoordelijkheid van de gebruiker zelf om een veilig wachtwoord te kiezen.

[SinergyX]

Mee eens, veelal als mensen zo'n regel zien, maken ze iets van: Stereohead1 als wachtwoord, voldoet allemaal.

Zoals ik al in de reactie aangaf, mijn wachtwoord kan dus maar op 2 manieren achterhaald worden, bruteforce en het jatten van de (oude) MD5'ed tabel. Beide gevallen is dat toch niet afhankelijk van de sterkte van mijn wachtwoord, maar de beveiliging van deze site?

Daarbij heb ik leuke complexe wachtwoorden, maar aangezien ik mobiel nonstop wordt uitgelogt, ooit geprobeerd een complex wachtwoord te typen op je mobiel? Wachtwoord opslaan op je mobiel is nog een slechter idee dan een zwak wachtwoord.

[.oisyn]

Mijn mening: BE-LA-CHE-LIJK!

Kom op zeg, het is een fucking t.net account. Hoe belangrijk is dat? Laat mij verdomme zelf bepalen hoe veilig mijn wachtwoord is. Dat t.net advies geeft over de sterkte, niets over te klagen. Maar ga alsjeblieft niet van die domme eisen verzinnen. Een hoofdletter? Alsjeblieft zeg. Zelfs het volgens t.net supersterke "tnet'swachtwoordeisenzuigenkont" voldoet niet.

Mijn huidige wachtwoord is blijkbaar sterk genoeg (geen mailtje gehad), maar bevat geen hoofdletter, dus ik laat het er maar bij, maar dit gaat werkelijkwaar helemaal nergens over.

(En dan te bedenken dat een crewlid onlangs nog zei dat het alleen maar een advies was, en geen eis. Niets van waar dus. Kan de post alleen zo snel even niet terugvinden.)

[ Voor 13% gewijzigd door .oisyn op 13-09-2011 14:41 ]

[RaZ]

Ik heb wel een melding gehad over een te zwak wachtwoord. Die melding kan ik vervolgens gewoon wegklikken, ik word nergens gedwongen een anders wachtwoord te kiezen. Ja, die van mij is 7 karakters.

Maar ik heb er toch vraagtekens bij. Uit onderzoek is gebleken dat mijn wachtwoord zwak is voor md5. T.net stapt van md5 af. Hoe zwak zal m'n wachtwoord dan nog zijn als er overgestapt wordt naar een andere methode.

Dat is namelijk niet getest (of niet gemeld). Ik zie dus zelf niets in het wijzigen van het wachtwoord. Tot op heden weet ik niet beter of die melding is op basis van de oude manier, en dus niet meer actueel.

[MicroWhale]

Bovendien:
Ik probeer mijn wachtwoord te veranderen, maar hij blijft klagen dat ik er geen hoofdletter in heb gestopt. En dat terwijl er wel degelijk een hoofdletter in zit.

Als je dan een artikel plaatst over veilige wachtwoorden, zorg dan dat de t.net policy op dat artikel aansluit.

[.oisyn]

Hier trouwens een link waaruit blijkt dat dergelijke eisen sowieso onzin zijn: http://www.infoworld.com/...word-size-does-matter-531

[Quacka]

.oisyn schreef op dinsdag 13 september 2011 @ 14:37:
Mijn mening: BE-LA-CHE-LIJK!

Kom op zeg, het is een fucking t.net account. Hoe belangrijk is dat? Laat mij verdomme zelf bepalen hoe veilig mijn wachtwoord is. Dat t.net advies geeft over de sterkte, niets over te klagen. Maar ga alsjeblieft niet van die domme eisen verzinnen. Een hoofdletter? Alsjeblieft zeg. Zelfs het volgens t.net supersterke "tnet'swachtwoordeisenzuigenkont" voldoet niet.

(En dan te bedenken dat een crewlid onlangs nog zei dat het alleen maar een advies was, en geen eis. Niets van waar dus. Kan de post alleen zo snel even niet terugvinden.)

Toch kan het best gevaarlijk zijn, lees mijn berichten:
[bug] V&A beoordeling plaatsen zonder reden

Anderzijds zullen mensen die zoals wij geregeld op de site komen snel genoeg merken als iemand anders er iets mee doet.

Ik zou het trouwens wel een prettig idee vinden als ik een popupje krijg als ik sinds het laatste bezoek ben ingelogd op een nieuwe locatie. Daarmee kan je zeg maar zo'n locatie veilig verklaren.

dus:
Ik log een keer in bij een vriend en een dag later als ik weer thuis ben krijg ik een popupje:

"Gisteren was je om tijdstip XX:XX ingelogd op -ip adres- -browser x-. Klik voor opties:
- Locatie toevoegen aan vertrouwde locaties
- eenmalig gebruik
- HELP ik heb gisteren helemaal niet gelogd.

Vanuit HELP wordt je gelijk naar een waarschuwingspagina doorgestuurd, met daarin tips waar je op kunt letten (mogelijk zelfs dat tweakers kan laten zien wat er gisteren gedaan is met je account). Verder wordt dan meteen gevraagd om je wachtwoord te veranderen en je emailadres te controleren.
Controle kan ook gedaan worden op basis van een cookie.

(natuurlijk moeten deze waarschuwingen uitgezet kunnen worden...: vrijheid blijheid wat dat betreft)

[DrivinUCrazy]

In dat geval schakelt iedereen het uit, of staat het zelfs standaard uit. Dan moet je dus bewust gaan kijken of je ergens anders bent ingelogd... Maar wacht, dat kan al!

Zie hier al je actieve sessies:
https://secure.tweakers.net/my.tnet/sessions

[Quacka]

klopt, maar dan moet je kijken: dat doe je maar zelden.

Het gaat erom dat je erop gewezen wordt (met vrije keuze natuurlijk)
Als tweakers veiligheid zo belangrijk vind, dan kunnen ze beter daarnaar kijken dan alleen melden dat de helft van de gebruikers een te simpel wachtwoord heeft.

[.oisyn]

Quacka schreef op dinsdag 13 september 2011 @ 15:08:
[...]

Toch kan het best gevaarlijk zijn, lees mijn berichten:
[bug] V&A beoordeling plaatsen zonder reden

Je houdt er geen rekening mee dat om de wachtwoorden zo makkelijk te kraken je eerst toegang moet hebben tot de database van MD5 wachtwoorden. Die momenteel niet eens meer bestaat door het nieuwe hash algoritme dat gebruikt wordt.

[RemcoDelft]

.oisyn schreef op dinsdag 13 september 2011 @ 14:37:
Mijn mening: BE-LA-CHE-LIJK!

Kom op zeg, het is een fucking t.net account. Hoe belangrijk is dat? Laat mij verdomme zelf bepalen hoe veilig mijn wachtwoord is.

Dat niet alleen, zolang de wachtwoorden ook nog onbeveiligd worden verzonden, heeft het allemaal bar weinig nut.

[CyBeR]

Met dergelijke eisen kan 'correct horse battery staple' niet ingevoerd worden, terwijl dat beduidend sterker is dan 'Tw3akers' wat wel mag. (Los van dat dat specifieke wachtwoord natuurlijk geen goed idee meer is.)

[ Voor 21% gewijzigd door CyBeR op 13-09-2011 15:45 ]

[.oisyn]

RemcoDelft schreef op dinsdag 13 september 2011 @ 15:42:
[...]

Dat niet alleen, zolang de wachtwoorden ook nog onbeveiligd worden verzonden, heeft het allemaal bar weinig nut.

Dat worden ze dus niet, er zit (optioneel weliswaar) een challenge/response systeem in, en tegenwoordig verloopt het via SSL.

[ Voor 62% gewijzigd door .oisyn op 13-09-2011 15:44 ]

[RaZ]

T.net gebruikt nu nog geen https site-wide gezien. Ik zie nogsteeds http:// staan.

Vervolgens gaat m'n cookie unencrypted over de lijn, ik zie 2 links staan naar een XML & RSS feed, met daarin m'n sessie-id.

Zonder mijn wachtwoord te hebben, kan iemand in mijn netwerk m'n ID opvangen, en al ingelogd op t.net komen onder mijn naam. En die kan dus site-wide ook posten.

Dat heeft 0,0 met wachtwoorden te maken natuurlijk.

[.oisyn]

RaZ schreef op dinsdag 13 september 2011 @ 15:47:
T.net gebruikt nu nog geen https site-wide gezien. Ik zie nogsteeds http:// staan.

Voor inloggen en ww wijzigen gebruiken ze HTTPS

Vervolgens gaat m'n cookie unencrypted over de lijn, ik zie 2 links staan naar een XML & RSS feed, met daarin m'n sessie-id.

In je cookie staat niet je wachtwoord. Als je je sessie hebt gelinkt aan je ip is hij ook zo goed als niet te misbruiken door iemand anders.

[Quacka]

.oisyn schreef op dinsdag 13 september 2011 @ 15:39:
[...]

Je houdt er geen rekening mee dat om de wachtwoorden zo makkelijk te kraken je eerst toegang moet hebben tot de database van MD5 wachtwoorden. Die momenteel niet eens meer bestaat door het nieuwe hash algoritme dat gebruikt wordt.

Ik ben geen hacker , maar als je iemands gebruikersnaam hebt, dan kan je toch gewoon gaan proberen om het wachtwoord te kraken?
Daar heb je toch de database niet voor nodig?

Of zit er wel een beveiliging bij tweakers die dit voorkomt?

[Wceend]

.oisyn schreef op dinsdag 13 september 2011 @ 15:51:
[...]

Voor inloggen en ww wijzigen gebruiken ze HTTPS


[...]

In je cookie staat niet je wachtwoord. Als je je sessie hebt gelinkt aan je ip is hij ook zo goed als niet te misbruiken door iemand anders.

behalve voor alle tweakers bij grote bedrijven die via een proxy naar buiten gaan. Het bezit van het cookie is dus voldoende om de sessie over te nmen.

[CyBeR]

.oisyn schreef op dinsdag 13 september 2011 @ 15:51:
[...]
In je cookie staat niet je wachtwoord. Als je je sessie hebt gelinkt aan je ip is hij ook zo goed als niet te misbruiken door iemand anders.

Maar laat het sessie-id nou het makkelijkst te vinden zijn voor mensen in hetzelfde netwerk als jij, die dus in vrijwel alle gevallen van hetzelfde IP-adres gebruik maken.

Niet dat dit makkelijk te voorkomen is...

[Verwijderd]

Quacka schreef op dinsdag 13 september 2011 @ 15:54:
[...]
Of zit er wel een beveiliging bij tweakers die dit voorkomt?

Meestal bouw je iets in zodat je niet 10000den wachtwoorden per uur kunt proberen, door bv. een vertraging tussen elke poging in te bouwen.

[crisp]

RaZ schreef op dinsdag 13 september 2011 @ 15:47:
[...] ik zie 2 links staan naar een XML & RSS feed, met daarin m'n sessie-id.

offtopic:
dat is niet je sessie-id

[Mektheb]

Typisch gevalletje van, als me account gehackt is ga ik zeuren bij Tweakers, doen ze het voor me is het ook niet goed >.<

heb er geen moeite mee het aangegeven is als er een wachtwoord redelijk zwak is.

[ Voor 25% gewijzigd door Mektheb op 13-09-2011 16:33 ]

[.oisyn]

Quacka schreef op dinsdag 13 september 2011 @ 15:54:
[...]

Ik ben geen hacker , maar als je iemands gebruikersnaam hebt, dan kan je toch gewoon gaan proberen om het wachtwoord te kraken?
Daar heb je toch de database niet voor nodig?

Een roundtrip naar de t.net server kost velen malen langer (in de orde van grootte van tientallen milliseconden) dan het uitvoeren van een enkele MD5 hash (tienden van microseconden), waarbij dat laatste met behulp van een GPU ook nog eens enorm geparallelliseerd kan worden.

Het verschil in tijd is daardoor ongeveer een factor miljard - waar t.net er 14 seconden over doet, zul jij er dus 14 miljard seconden (~444 jaar) over doen. En dan vergeet ik voor het gemak maar even dat je na een paar pogingen niet eens meer mag proberen.

[leuk_he]

Dan doet de developer het voorstel een zinnetje te gebruiken (wat vele malen veiliger is dan een "H@x0r123" )

Vervolgens werkt dat niet omdat er een hoofdletter en een nummer in voor moet komen...

[.oisyn]

crisp schreef op dinsdag 13 september 2011 @ 16:30:
[...]

offtopic:
dat is niet je sessie-id

Komt er ook nog een inhoudelijke reactie van een devver?

[crisp]

.oisyn schreef op dinsdag 13 september 2011 @ 16:36:
[...]

Komt er ook nog een inhoudelijke reactie van een devver?

Ik kan je mijn mening geven, maar de requirements mbt de wachtwoordeisen zijn opgesteld door ons productteam, dus een inhoudelijke reactie zal van hun moeten komen

[.oisyn]

Fair enough
.edit: nee, eigenlijk niet fair enough. Waarom beslist een productteam over dergelijke eisen?

[ Voor 77% gewijzigd door .oisyn op 13-09-2011 16:45 ]

[MicroWhale]

crisp schreef op dinsdag 13 september 2011 @ 16:39:
[...]

Ik kan je mijn mening geven, maar de requirements mbt de wachtwoordeisen zijn opgesteld door ons productteam, dus een inhoudelijke reactie zal van hun moeten komen

Tijd dus voor de architect, die over invulling van dergelijke eisen gaat, om eens stevig te gaan praten met het product-team (dat mijns inziens wel kan stellen dat er ingelogd dient te worden, maar niet gaat over de security eisen die aan het inloggen zelf gesteld dienen te worden. Als ze dat wel doen dan is dat een typisch gevalletje business die zich met inhoudelijke IT zaken bezighoudt.)

[Osiris]

Overigens:

HTML:

<input type="password" name="NwPassword1" id="NwPassword1" maxlength="32">

Dus een beetje mooie lange zin als passphrase gaat sowieso niet lukken

Sowieso apart om daar een max aan te hebben? Het wordt toch gehasht, nobody cares als je daar een paragraaf Lorem ipsum indrukt lijkt me?

[ Voor 28% gewijzigd door Osiris op 13-09-2011 19:20 ]

[leuk_he]

.oisyn schreef op dinsdag 13 september 2011 @ 16:45:
Waarom beslist een productteam over dergelijke eisen?

Missschien wel een heel goede vraag. Want waarom een wachtwoord van die kwaliteit verplicht stellen, als er vervolgens deze over een niet httpsverbinding verstuurd wordt (diginotar heeft nog wat certificaten in de aanbieding ). En wellicht kunnen cookies daarna ook nog gebruikt worden om de sessie over te nemen (niet geprobeerd....)

Juist door zo'n complex wachtwoord te eisen moet dit ergens anders vastgelegd worden. in de .plan staan wat goede ideeën, maar vervolgens zie ik ook wat tweakers suggesties doen die NIET safe zijn.

Nee, hier is NIET goed over nagedacht door degene die hier de opdracht voor gegeven heeft.

[Gomez12]

.oisyn schreef op dinsdag 13 september 2011 @ 14:37:
Mijn mening: BE-LA-CHE-LIJK!

Kom op zeg, het is een fucking t.net account. Hoe belangrijk is dat?

Aan de andere kant, er zit wel een V&A stuk aanvast waar mensen opgelicht etc kunnen worden.

In 1e instantie had ik ook zoiets van : Boeiuh, maar toen las ik ergens over V&A en dan komt het wmb wel in een iets ander licht te staan. Dat is gewoon geld wat daar verhandeld wordt en deels telt daar ook de betrouwbaarheid van het forum mee.

Als .oisyn bijv iets zou aanbieden zou ik sneller geneigd zijn om gelijk geld over te maken dan als jantje het doet, oisyn die zie ik nog wel eens langskomen op GoT etc. etc. dat zit wel goed.

[crisp]

leuk_he schreef op dinsdag 13 september 2011 @ 19:42:
[...]


Missschien wel een heel goede vraag. Want waarom een wachtwoord van die kwaliteit verplicht stellen, als er vervolgens deze over een niet httpsverbinding verstuurd wordt

uhm, sinds gisteren gaan alle my.tnet pagina's over https hoor

[crisp]

Osiris schreef op dinsdag 13 september 2011 @ 19:19:
Overigens:

HTML:

<input type="password" name="NwPassword1" id="NwPassword1" maxlength="32">

Dus een beetje mooie lange zin als passphrase gaat sowieso niet lukken

Sowieso apart om daar een max aan te hebben? Het wordt toch gehasht, nobody cares als je daar een paragraaf Lorem ipsum indrukt lijkt me?

True dat, lijkt mij een stukje legacy wat wel opgeruimd mag worden

Overigens vind ik het persoonlijk niet verkeerd om enigszins dwingend het gebruik van een relatief sterk wachtwoord te forceren, maar het voorbeeld van een pass-phrase (wat tegenwoordig als zeer sterk wordt beschouwd) geeft wel aan dat we enigszins op dat niveau juist teveel beperkingen hebben ingebouwd. Ik denk dat het inderdaad wel raadzaam is hier nog eens goed over na te denken

[.oisyn]

Je wilt wel een limiet. Zeker met een dure hash functie wil je voorkomen dat DoS attacks mogelijk zijn door simpelweg hele lange passphrases toe te staan. Het mag imho wel wat langer ja, maar het hoeft natuurlijk ook geen 1024 te zijn. Maar goed, 32 is dan nog redelijk. Zelf gebruik ik al jaren een zelfgemaakte variant op LastPass (geloof ik, ik heb LastPass zelf nooit gebruikt ik heb alleen de term horen vallen hier) met gegenereerde wachtwoorden van 16 tekens, en je staat er verbaasd van hoe vaak dat nog misgaat. Dan copy/paste je je wachtwoord in het veld, vervolgens wordt ie afgekapt tot 12 tekens oid, en dan zit je je bij het inloggen af te vragen waarom het niet werkt (omdat bij het inlogveld de limiet juist weer niet bestaat )

[leuk_he]

crisp schreef op dinsdag 13 september 2011 @ 22:15:
[...]

uhm, sinds gisteren gaan alle my.tnet pagina's over https hoor

eeh...ja.... schaam.

[.oisyn]

Gomez12 schreef op dinsdag 13 september 2011 @ 19:45:
[...]

Aan de andere kant, er zit wel een V&A stuk aanvast waar mensen opgelicht etc kunnen worden.

Maar hoe helpen de nieuwe strenge wachtwoordeisen daar aan mee dan? 6 tekens bruteforcen via de loginprocedure van t.net gaat 'm ook niet echt worden.

[ Voor 13% gewijzigd door .oisyn op 13-09-2011 22:54 ]

[Gomez12]

.oisyn schreef op dinsdag 13 september 2011 @ 22:52:
[...]

Maar hoe helpen de nieuwe strenge wachtwoordeisen daar aan mee dan? 6 tekens bruteforcen via de loginprocedure van t.net gaat 'm ook niet echt worden.

Ach, 16 gebruikers hebben momenteel een 1-karakter wachtwoord. Geef mij de gebruikersnamen en ik ben best bereid om die te brute-forcen hoor...

Maar het ging mij niet specifiek om de eisen, maar meer om jouw stukje dat een t.net account niet belangrijk is. Bij 99% van alle sites / fora etc ben ik het met je eens. Maar bij t.net dan net weer niet omdat er daar ook gewoon een stukje marktplaats aanvasthangt.

Een wachtwoord van het viva-forum vind ik onbelangrijk (wow, iemand plaatst iets raars onder mijn naam in mijn vakantie). Als iemand onder jouw naam bijv de nieuwe TombRaider beta te koop aanbiedt op V&A dan denk ik dat er redelijk wat mensen instinken als ze jouw post-geschiedenis nakijken.
Daarom vind ik bij t.net een wachtwoord wel enige waarde hebben en mogen er best eisen aan het wachtwoord gesteld worden wmb.

De eisen zelf vind ik discutabel, magoe.

[Quacka]

crisp schreef op dinsdag 13 september 2011 @ 22:15:
[...]

uhm, sinds gisteren gaan alle my.tnet pagina's over https hoor

Ehm. Mag ik dan zeggen dat 'jullie' nieuwsbericht een rare kop heeft?
De kop had moeten zijn:
'Tweakers herstelt beveiligingslek en past veiligheidsbeleid aan'
(nog korter ook)

Nu wordt er in de kop alleen naar de gebruikers gewezen...

[.oisyn]

Gomez12 schreef op dinsdag 13 september 2011 @ 23:10:
Als iemand onder jouw naam bijv de nieuwe TombRaider beta te koop aanbiedt op V&A dan denk ik dat er redelijk wat mensen instinken als ze jouw post-geschiedenis nakijken.

Tegelijkertijd kom ik dagelijks op tweakers en heb ik het echt wel door als er iets in mijn postgeschiedenis staat waarvan ik niets weet . Maar wat jij zegt over het Viva forum gaat dan toch net zo goed op? Daar lopen ook vast wel meubelstukken rond die door iedereen gekend en vertrouwd worden.

Quacka schreef op dinsdag 13 september 2011 @ 23:35:
[...]


Ehm. Mag ik dan zeggen dat 'jullie' nieuwsbericht een rare kop heeft?
De kop had moeten zijn:
'Tweakers herstelt beveiligingslek en past veiligheidsbeleid aan'
(nog korter ook)

Nu wordt er in de kop alleen naar de gebruikers gewezen...

Behalve bij het aanmaken van een account zie ik het beveiligingslek niet. T.net biedt al jaren de optie aan om de wachtwoor "versleuteld te versturen" (eigenlijk een challenge/response system, maar soit), en dat staat standaard aan.

[ Voor 34% gewijzigd door .oisyn op 13-09-2011 23:41 ]

[alex3305]

crisp schreef op dinsdag 13 september 2011 @ 22:15:
[...]

uhm, sinds gisteren gaan alle my.tnet pagina's over https hoor

Jammer dat Google Chrome dan aangeeft dat de verbinding met de site niet goed is en dat zeer waarschijnlijk delen op de site niet goed beveiligd zijn, waardoor er wordt aangeraden geen persoonlijke informatie te delen .

[Gomez12]

.oisyn schreef op dinsdag 13 september 2011 @ 23:39:
[...]

Tegelijkertijd kom ik dagelijks op tweakers en heb ik het echt wel door als er iets in mijn postgeschiedenis staat waarvan ik niets weet . Maar wat jij zegt over het Viva forum gaat dan toch net zo goed op? Daar lopen ook vast wel meubelstukken rond die door iedereen gekend en vertrouwd worden.

Viva-forum heeft volgens mij geen expliciet verkoop-gedeelte waardoor imho oplichting een veel minder grote rol gaat spelen.

Hier is een los stukje marktplaats waar meubelstuk zijn imho toch ietwat meeteelt aan de vertrouwensbasis. Oftewel wat extra uitgebuit kan worden bij misbruik.

[crisp]

alex3305 schreef op dinsdag 13 september 2011 @ 23:40:
[...]

Jammer dat Google Chrome dan aangeeft dat de verbinding met de site niet goed is en dat zeer waarschijnlijk delen op de site niet goed beveiligd zijn, waardoor er wordt aangeraden geen persoonlijke informatie te delen .

Zie Ceritficaat error

[CyBeR]

Kan trouwens iemand de spatie uit de titel fixen?

[Osiris]

.oisyn schreef op dinsdag 13 september 2011 @ 22:39:
Je wilt wel een limiet. Zeker met een dure hash functie wil je voorkomen dat DoS attacks mogelijk zijn door simpelweg hele lange passphrases toe te staan. Het mag imho wel wat langer ja, maar het hoeft natuurlijk ook geen 1024 te zijn. Maar goed, 32 is dan nog redelijk.

32 bytes 10 000 maal door `sha256sum` halen: 14 seconden.
1024 bytes 10 000 maal door `sha256sum` halen: 14 seconden.

Ok, 100 000 iteraties: 32 bytes: 2 minuten en 27,506 seconden.
100 000 iteraties 1024 bytes: 2 minuten en 28,481 seconden.

Hmm, da's wel apart.. Ik verwacht op z'n minst toch íets verschil..

[ Voor 9% gewijzigd door Osiris op 14-09-2011 00:53 ]

[CyBeR]

Doe maar niet, want het langdurige zit 'm in de hoeveelheid iteraties, niet in de lengte van je passphrase. SHA1 hasht als een mallemoer, dus je moet echt een flink verschil in grootte hebben wil 't echt wat uitmaken. Een moderne server kan enkele honderden MB's per seconde hashen.

[Osiris]

Maar dit is geen SHA-1, maar een SHA-2-variant, welke volgens Wikipedia 1,4x zo langzaam is

Denk dat we dus wel kunnen concluderen dat een potentieel DoS-risico geen reden is voor een max. password-length van 32. Of 1024 for that matter. Althans, in het geval van SHA-256. Ik kan zo snel geen *nix-CLI-proggie vinden wat die maffe hash-functie die T.net gebruikt doet.

[CyBeR]

Osiris schreef op woensdag 14 september 2011 @ 01:22:
Maar dit is geen SHA-1, maar een SHA-2-variant, welke volgens Wikipedia 1,4x zo langzaam is

Same difference. Dan doe je je metingen nog een keer en krijg je alles gedeeld door 1.4 De snelheid waarmee SHA1 en SHA2-256 zich tot elkaar verhouden is verder lineair qua data-doorvoer.

[Wolfboy]

stereohead schreef op dinsdag 13 september 2011 @ 14:04:
- Minimaal 8 tekens
Hier kan ik me in vinden, anders wordt Brute Force te makkelijk.

Ok... laten we hier beginnen. 8 tekens, 26 letters.
26 ^ 8 = 208827064576 mogelijkheden

- Minimaal 1 hoofdletter,
Dit heeft maar weinig invloed op de sterkte van een wachtwoord, die ene hoofdletter staat toch bijna altijd op een voorspelbare plaats. Zoals jullie overigens zelf aangeven in het artikel.

Als het op dezelfde lokatie staat... inderdaad niet zinnig, anders verdubbelt het opeens de hoeveelheid tekens

52 ^ 8 = 53459728531456

- Minimaal 1 cijfer of speciaal teken.
Dit heeft tevens maar weinig invloed op de sterkte van een wachtwoord, want ook hierbij geld dat die bijna altijd op een voorspelbare plaats staat.

Ok... dit vergroot de mogelijkheden.

10 cijfers + ~20 speciale tekens?

Now we're getting somewhere...
82 ^ 8 = 2044140858654976

Wat helemaal raar is, is dat jullie aan het eind van het artikel de tip geven om een zinnetje van willekeurige woorden te gebruiken (ala "correct horse battery staple"). Maar zo'n wachtwoord wordt dus helemaal niet toegestaan!

Geen vreemde tekens verkleint het aantal mogelijkheden misschien wat kwa tekens, maar je hebt opeens wel veel meer tekens.

a-z + spatie = 27 met ~32 tekens?
27 ^ 32 = 6362685441135942358474828762538534230890216321

Kortom. Het advies in het artikel, en de eisen aan het wachtwoord spreken elkaar tegen.

De eisen zijn slim genoeg imho

[CyBeR]

Wolfboy schreef op woensdag 14 september 2011 @ 02:16:
[...]
De eisen zijn slim genoeg imho

Niet dus, want met 'correct horse battery staple' (eventussendoor: spaties in een wachtwoord? wat een geniaal idee!*) ben je beduidend beter af dan met Tw3akers, om maar een voorbeeld te noemen.

Ik heb dit toevallig laatst ook even zitten proberen; mijn laptop kan 70 miljoen MD5sums per seconde uitproberen. En dat is dan een laptop met een mobile kaartje van 2009 (en waarschijnlijk niet de best geoptimaliseerde software). Een moderne bak met wat serieuzere GPU's kan er een miljard per seconde doen. Met die snelheid is élk 8-karakterig wachtwoord binnen no-time geraden, ongeacht hoeveel speciale karakters je gebruikt.

Sterker nog: voor heel veel van die wachtwoorden (ook dit heb ik proefondervindelijk ondervonden) kun je de MD5 gewoon in google prikken en dan zoekt die 't in een van de geindexeerde rainbow tables op. Kost je nog geen seconde.

Het enige wat ons op dit moment redt tegen dit soort aanvallen op hashes is lengte.


*) De grap is dus dat de meeste mensen van 'correct horse battery staple' direct 'correcthorsebatterystaple' maken omdat ze het concept spatie in je wachtwoord niet snappen.

[ Voor 7% gewijzigd door CyBeR op 14-09-2011 02:25 ]

[Mentalist]

.oisyn schreef op dinsdag 13 september 2011 @ 14:37:
Mijn huidige wachtwoord is blijkbaar sterk genoeg (geen mailtje gehad), maar bevat geen hoofdletter, dus ik laat het er maar bij, maar dit gaat werkelijkwaar helemaal nergens over.

Ik heb geen notificatiebalk of mailtje gekregen (ik zit bij de "goede" 50% ), maar mijn wachtwoord is niet uitzonderlijk sterk (ook niet echt slecht, maar het kan beter). Ik was van plan een betere te verzinnen, maar dat ga ik nu dus mooi niet doen.

.oisyn schreef op dinsdag 13 september 2011 @ 15:51:
In je cookie staat niet je wachtwoord. Als je je sessie hebt gelinkt aan je ip is hij ook zo goed als niet te misbruiken door iemand anders.

Dat is natuurlijk helemaal geen probleem als je op je werk achter NAT of een proxy zit.

.oisyn schreef op dinsdag 13 september 2011 @ 16:45:
Fair enough
.edit: nee, eigenlijk niet fair enough. Waarom beslist een productteam over dergelijke eisen?

Wat de neuk ìs een productteam en waarom werkt dat onafhankelijk van de crew?

Osiris schreef op dinsdag 13 september 2011 @ 19:19:
Overigens:

HTML:

<input type="password" name="NwPassword1" id="NwPassword1" maxlength="32">

Dus een beetje mooie lange zin als passphrase gaat sowieso niet lukken

Sowieso apart om daar een max aan te hebben? Het wordt toch gehasht, nobody cares als je daar een paragraaf Lorem ipsum indrukt lijkt me?

Nouja je wil niet dat mensen de laatste Transformers film in base64 als wachtwoord gaan gebruiken, maar 32 karakters is wel héél kort.

Overigens:

quote: http://tweakers.net/nieuw...wachtwoord-te-hebben.html

Deze aanpak bleek efficiënter dan een brute-forceaanval. Het zou immers vele uren geduurd hebben om alle mogelijke wachtwoorden van maximaal acht tekens te berekenen,

Vele uren? Moet je dan geen 9 of 10 tekens vereisen?

CyBeR schreef op woensdag 14 september 2011 @ 02:24:
*) De grap is dus dat de meeste mensen van 'correct horse battery staple' direct 'correcthorsebatterystaple' maken omdat ze het concept spatie in je wachtwoord niet snappen.

http://xkcd.com/936/

Ik haal hier geen spaties uit hoor.

Mag ik trouwens een carriage return in mijn wachtwoord hebben?

[ Voor 8% gewijzigd door Mentalist op 14-09-2011 03:09 ]

[Osiris]

W3ird_N3rd schreef op woensdag 14 september 2011 @ 03:04:
[...]

Nouja je wil niet dat mensen de laatste Transformers film in base64 als wachtwoord gaan gebruiken, maar 32 karakters is wel héél kort.

Dat kan nu natuurlijk sowieso nog wel; je zult 't altijd nog server-side moeten checken uiteraard Besides, PHP heeft ook een maximum POST-data-limiet, maximum execution-time.

En ik bedoelde 't ook eigenlijk als 'opkrikken naar een limiet die in de praktijk niet gehaald zal worden'.

W3ird_N3rd schreef op woensdag 14 september 2011 @ 03:04:
Mag ik trouwens een carriage return in mijn wachtwoord hebben?

Ik zeg: pak PHP + CURL erbij en probeer het?

[ Voor 17% gewijzigd door Osiris op 14-09-2011 04:22 ]

[Mentalist]

Osiris schreef op woensdag 14 september 2011 @ 04:21:
[...]

Dat kan nu natuurlijk sowieso nog wel; je zult 't altijd nog server-side moeten checken uiteraard Besides, PHP heeft ook een maximum POST-data-limiet, maximum execution-time.

En ik bedoelde 't ook eigenlijk als 'opkrikken naar een limiet die in de praktijk niet gehaald zal worden'.

Dat zou ik ook voorstellen. Maak er gewoon 1024 van ofzo, het is te hopen dat niemand daaraan komt.

[...]

Ik zeg: pak PHP + CURL erbij en probeer het?

Ik bedoelde het meer als "Mag ik alsjeblieft een carriage return in mijn wachtwoord op t.net hebben? ".

[Wolfboy]

CyBeR schreef op woensdag 14 september 2011 @ 02:24:
Niet dus, want met 'correct horse battery staple' (eventussendoor: spaties in een wachtwoord? wat een geniaal idee!*) ben je beduidend beter af dan met Tw3akers, om maar een voorbeeld te noemen.

Hangt natuurlijk heel erg van je hashing algoritme af (een salt helpt daarbij natuurlijk ook wel iets, mits dit algoritme geheim blijft).

Sterker nog: voor heel veel van die wachtwoorden (ook dit heb ik proefondervindelijk ondervonden) kun je de MD5 gewoon in google prikken en dan zoekt die 't in een van de geindexeerde rainbow tables op. Kost je nog geen seconde.

Wederom... salted hashes gebruiken van hebben rainbow tables weinig nut meer.

[.oisyn]

Wolfboy schreef op woensdag 14 september 2011 @ 02:16:
[...]
Ok... laten we hier beginnen. 8 tekens, 26 letters.
26 ^ 8 = 208827064576 mogelijkheden

Nee, laten we hier beginnen:

De keyspace is aⁿ, met a het aantal verschillende karakters dat je in kan voeren en n de lengte van het wachtwoord. Welke van de twee heeft meer zin om te verhogen, denk je?

De eisen zijn dom. Ik wil 'n' vergroten en 'a' klein houden om het makkelijk te kunnen onthouden, maar t.net eist van mij dat ik 'a' vergroot. De eisen helpen ook niet, want iemand die nu geen hoofdletter heeft denkt "oh, dan begin ik gewoon met een hoofdletter". Als iedereen dat doet blijft a dus gewoon exact gelijk.

En daarnaast, iedereen schijnt het alweer te vergeten, maar ze gebruiken dus geen MD5 hash meer, en het nu gebruikte algoritme is absoluut niet zo snel te kraken - en dit geldt dan ook nog eens alleen als de database bloot ligt, want via het inlogscherm kraken is sowieso een factor miljarden trager. Er wordt nu iets afgedekt dat niet echt lek meer was, maar aan andere serieuzere problemen (sessie stelen) wordt niet gewerkt

[ Voor 40% gewijzigd door .oisyn op 14-09-2011 12:05 ]

[crisp]

maar aan andere serieuzere problemen (sessie stelen) wordt niet gewerkt

Dat is - kan ik je vertellen - een foute aanname

[Wolfboy]

.oisyn schreef op woensdag 14 september 2011 @ 11:58:
[...]

Nee, laten we hier beginnen:

De keyspace is aⁿ, met a het aantal verschillende karakters dat je in kan voeren en n de lengte van het wachtwoord. Welke van de twee heeft meer zin om te verhogen, denk je?

Hangt van de verhoudingen af natuurlijk, maar zoals de rest van m'n post wel duidelijk maakt is een langer wachtwoord al snel zinniger ja.

De eisen zijn dom. Ik wil 'n' vergroten en 'a' klein houden om het makkelijk te kunnen onthouden, maar t.net eist van mij dat ik 'a' vergroot.

De eisen zijn idd dom, de kwaliteitsindicatie lijkt me wel correct. Een betere eis lijkt me om een bepaalde entropy te vereisen.

[Femme]

MrWilliams schreef op dinsdag 13 september 2011 @ 19:06:
[...]

Tijd dus voor de architect, die over invulling van dergelijke eisen gaat, om eens stevig te gaan praten met het product-team (dat mijns inziens wel kan stellen dat er ingelogd dient te worden, maar niet gaat over de security eisen die aan het inloggen zelf gesteld dienen te worden. Als ze dat wel doen dan is dat een typisch gevalletje business die zich met inhoudelijke IT zaken bezighoudt.)

Het productteam is niet de business maar bestaat uit mensen die visueel, interactie een functioneel ontwerp doen. Dat zijn dus allemaal dingen die op de gebruikservaring betrekking hebben, zo ook de eisen die aan het wachtwoord gesteld worden. Daarin willen we een balans vinden tussen veiligheid en gebruiksvriendelijkheid. Wij staan gewoon open voor feedback van onze bezoekers (en van development) en luisteren ook als er niet 'stevig' gepraat wordt.

Het lijkt me zinvol om de eisen voor het wachtwoord aan te passen zodat lengte en gebruik van verschillende soorten tekens (cijfers, lowercase letters, uppercase letters en bijzondere tekens) tegen elkaar worden afgewogen.

[Mentalist]

Mooi, dan zijn we het volgens mij allemaal eens met elkaar. Waar is het productteam?

[CyBeR]

Wolfboy schreef op woensdag 14 september 2011 @ 09:31:
[...]
Hangt natuurlijk heel erg van je hashing algoritme af (een salt helpt daarbij natuurlijk ook wel iets, mits dit algoritme geheim blijft).

Tegen brute-forcen helpt een salt niets. Dat wil zeggen, je moet dan wel elk wachtwoord dat je hebt apart brute-forcen, maar als je sowieso al achter een enkel wachtwoord aan zat maakt dat niets uit.

Het type hash in zichzelf maakt ook niet zo heel veel uit (het blijft een stukje data van een paar karakters), alleen wordt voor moderne password storage gebruik gemaakt van heel veel iteraties van dezelfde hash om 't langer te laten duren.

[...]
Wederom... salted hashes gebruiken van hebben rainbow tables weinig nut meer.

Dat is waar. Maar dat deed t.net eerder niet, dat was gewoon 'md5(passwd)' in de db.

[alex3305]

Fijn om te horen Femme. Zo vind ik het persoonlijk fijn om een lang wachtwoord te hebben zonder hoofdletters of vreemde tekens, maar wel met cijfers en lowercase letters. Dat kan echter nog steeds zo veilig zijn dat hoofdletters en/of vreemde tekens niet per se nodig zijn.

Daarnaast heeft het, helaas, als oorzaak dat ik nu mijn t.net wachtwoord niet verander omdat ik per se geen hoofdletters of vreemde tekens erin wil hebben.

[DRaakje]

crisp schreef op dinsdag 13 september 2011 @ 22:23:
[...]

True dat, lijkt mij een stukje legacy wat wel opgeruimd mag worden

Overigens vind ik het persoonlijk niet verkeerd om enigszins dwingend het gebruik van een relatief sterk wachtwoord te forceren

Want dat stimuleert wachtwoord hergebruik totaaaaaal niet
Wat mijn inziens een veel groter probleem is, want niet alle sites hashen de wachtwoorden, en dan kan je nog wel een ijzersterk wachtwoord hebben, als het bekend is, dan is het bekend.

[Femme]

W3ird_N3rd schreef op woensdag 14 september 2011 @ 15:11:
Mooi, dan zijn we het volgens mij allemaal eens met elkaar. Waar is het productteam?

Dat ben ik dus, bonzz.netninja en MI6 .

[crisp]

DRaakje schreef op woensdag 14 september 2011 @ 16:12:
[...]

Want dat stimuleert wachtwoord hergebruik totaaaaaal niet

Wat bedoel je precies? Een sterk wachtwoord hoeft niet te betekenen dat het voor een mens ook onmogelijk te onthouden is. Zoals in dit topic al meer gezegd is is een zogenaamde 'pass-phrase', bijvoorbeeld "op een dag keek ik omhoog en zag ik een roze koe", waarschijnlijk sterker dan iets als "oMg$1"

[Mentalist]

Femme schreef op woensdag 14 september 2011 @ 16:15:
[...]

Dat ben ik dus, bonzz.netninja en MI6 .

Waarom beslissen jij, bonzz.netninja en MI6 dan stomme dingen?

crisp schreef op woensdag 14 september 2011 @ 16:17:
[...]

Wat bedoel je precies? Een sterk wachtwoord hoeft niet te betekenen dat het voor een mens ook onmogelijk te onthouden is. Zoals in dit topic al meer gezegd is is een zogenaamde 'pass-phrase', bijvoorbeeld "op een dag keek ik omhoog en zag ik een roze koe", waarschijnlijk sterker dan iets als "oMg$1"

>"Overigens vind ik het persoonlijk niet verkeerd om enigszins dwingend het gebruik van een relatief sterk wachtwoord te forceren"
<"Want dat stimuleert wachtwoord hergebruik totaaaaaal niet "

Ik denk dat DRaakje het las als dat jij het eens bent met de huidige eisen. En ja, als je zulke eisen krijgt ga je ook een standaard wachtwoord verzinnen wat aan de bekende eisen voldoet. (anders moet je tig moeilijke wachtwoorden onthouden) En dan krijg je dus Tw3aker, G4thering, HOOFDLETTERkleineletter$p€ciaalteken of zelfs "Wachtw00rd" (voldoet aan alle eisen!).

Tegelijk is "geefmetoegangofmehomiesdoenpipategenjekoppie" niet toegestaan, want:
• Geen hoofdletter.
• Geen cijfer of speciaal teken.
• Meer dan 32 karakters.

[ Voor 7% gewijzigd door Mentalist op 14-09-2011 22:38 ]

[Ozzie]

Zou er niet gewoon gebruik gemaakt kunnen worden van dezelfde functie die bepaald of je wachtwoord sterk is of niet?
Zo was mijn (nieuwe) wachtwoord toen ik hem invoerde volgens de kwaliteit meting "supersterk". Toen ik account aanpassen drukte kreeg ik de melding dat er ook nog een hoofdletter in mijn wachtwoord moest. Terwijl die volgens de 'meting' al supersterk was.

[Yezpahr]

Mijn wachtwoord voldoet de komende 10 jaar nog wel: ლ(ಠ益ಠ)ლ

En dat is een geintje natuurlijk .
In feite maakt het niet uit hoe veilig je wachtwoord is.
Er zijn altijd manieren om weer meer rekenkracht te bemachtigen en om weer meer hashes te vergelijken per seconde.

De enige manier om een wachtwoord veilig te krijgen is ervoor te zorgen dat het alle mogelijk tekens bevat die de computer maar snapt.
Je kunt ook een cijfercombinatie doen, maar uiteindelijk zal alles wel te brute-forcen zijn en hangt het er vanaf hoe de algoritmes door de mogelijkheden cyclen.

Ook algoritmes kennen hun flaws die ervoor zorgen dat ze bepaalde mogelijkheden buitensluiten.
Als je dus DIE uitzonderingen kent, dan ben je veilig. Theoretisch...

*edit*
En Ozzie bewijst dat die eisen meestal alleen maar frustratie met zich meebrengen.
Zonder dat zo iets verandering in het risico brengt.

[ Voor 87% gewijzigd door Yezpahr op 14-09-2011 23:24 ]

[Rukapul]

crisp schreef op woensdag 14 september 2011 @ 16:17:
[...]

Wat bedoel je precies? Een sterk wachtwoord hoeft niet te betekenen dat het voor een mens ook onmogelijk te onthouden is. Zoals in dit topic al meer gezegd is is een zogenaamde 'pass-phrase', bijvoorbeeld "op een dag keek ik omhoog en zag ik een roze koe", waarschijnlijk sterker dan iets als "oMg$1"

Dit is echt een schitterend gebied vanwege de vele literatuur die er over beschikbaar is inclusief empirische resultaten

Specifiek over bovenstaande password mnemonics: Human selection of mnemonic phrase-based passwords

We show the majority of survey respondents based their mnemonic passwords on phrases that can be found on the Internet, and we generate a mnemonic password dictionary as a proof of concept. Our 400,000-entry dictionary cracked 4% of mnemonic passwords; in comparison, a standard dictionary with 1.2 million entries cracked 11% of control passwords.

Op Google Scolar is enorm veel te vinden over (in)effectieve password policies inclusief een flink aantal papers met empirische resultaten:
password policy usable security empirical entropy of een subset danwel variatie erop. Cranor, Anderson en anderen hebben goede informatieve publicaties op hun naam staan.

The true cost of unusable password policies: password use in the wild
Password memorability and security: Empirical results
etc

De grap is dat juist heel veel 'good practices' bewezen ineffectief zijn omdat het niet aansluit op de mens.

[ Voor 10% gewijzigd door Rukapul op 14-09-2011 23:23 ]

[CyBeR]

Yezpahr schreef op woensdag 14 september 2011 @ 22:56:
Mijn wachtwoord voldoet de komende 10 jaar nog wel: ლ(ಠ益ಠ)ლ

Hehehe. In de achtergrond zijn dat 18 karakters.

[crisp]

CyBeR schreef op woensdag 14 september 2011 @ 23:24:
[...]


Hehehe. In de achtergrond zijn dat 18 karakters.

Jep, nog geen UTF8 hier helaas...

[.oisyn]

In UTF-8 zijn het ook 17 bytes hoor

Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?

[CyBeR]

.oisyn schreef op donderdag 15 september 2011 @ 00:07:
In UTF-8 zijn het ook 17 bytes hoor

Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?

Oh mischien heeft 'wc' de newline erbij geteld. 17, 18, bleh

[crisp]

.oisyn schreef op donderdag 15 september 2011 @ 00:07:
In UTF-8 zijn het ook 17 bytes hoor

Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?

Bij ons is dit een wachtwoord van 38 bytes; het komt namelijk zo aan op de server:

code:

ლ(ಠ益ಠ)ლ

(en wordt vervolgens afgekeurd vanwege geen letters)

[ Voor 6% gewijzigd door crisp op 15-09-2011 08:14 ]

[NomoDigger]

Ozzie schreef op woensdag 14 september 2011 @ 22:40:
Zou er niet gewoon gebruik gemaakt kunnen worden van dezelfde functie die bepaald of je wachtwoord sterk is of niet?
Zo was mijn (nieuwe) wachtwoord toen ik hem invoerde volgens de kwaliteit meting "supersterk". Toen ik account aanpassen drukte kreeg ik de melding dat er ook nog een hoofdletter in mijn wachtwoord moest. Terwijl die volgens de 'meting' al supersterk was.

Dit vind ik wel een goede eigenlijk. Met wat tips erbij die zeggen hoe je een wachtwoord "sterker" kan maken.

[Wolfboy]

CyBeR schreef op woensdag 14 september 2011 @ 15:20:
[...]


Tegen brute-forcen helpt een salt niets. Dat wil zeggen, je moet dan wel elk wachtwoord dat je hebt apart brute-forcen, maar als je sowieso al achter een enkel wachtwoord aan zat maakt dat niets uit.

Als je de salted hash te pakken krijgt zonder de salt (en/of het algoritme, salt ervoor, salt erachter, salt er doorheen) is het opeens een stuk lastiger. Dan helpt een salt heel veel tegen brute-forcen.

[bonzz.netninja]

Femme schreef op woensdag 14 september 2011 @ 16:15:
[...]


Dat ben ik dus, bonzz.netninja en MI6 .

En in deze heeft Femme de lead (we verdelen doorgaans de issues/onderwerpen een beetje om het behapbaar te maken, ik houd mij meer bezig met PW, V&A en Mobile gerelateerde zaken) (maar ik denk natuurlijk wel mee)

[ Voor 4% gewijzigd door bonzz.netninja op 15-09-2011 09:56 ]

[CyBeR]

Wolfboy schreef op donderdag 15 september 2011 @ 09:39:
[...]
Als je de salted hash te pakken krijgt zonder de salt (en/of het algoritme, salt ervoor, salt erachter, salt er doorheen) is het opeens een stuk lastiger. Dan helpt een salt heel veel tegen brute-forcen.

Zonder de salt kan de originele code er ook niets mee. Als iemand de hash heeft is 't veilig om aan te nemen dat 'ie de salt ook heeft. Dat zijn namelijk stukjes informatie die onlosmakelijk met elkaar verbonden zijn. En zodanig ook meestal gewoon aan elkaar geplakt in de db staan. Bijvoorbeeld, UNIX password hashes:


$1$CqaUu7e4$c14V.Mu1LJTXnlfAd.t8D1

De salt is 'CqaUu7e4' en de hash 'c14V.Mu1LJTXnlfAd.t8D1'.

Salt ervoor of salt erachter, mwah maakt alles *2 als je 't niet weet, niet zo spannend dus in the grand scheme of things. Verder: als een aanvaller je wachtwoordendatabase heeft is 't ook alweer niet onredelijk om aan te nemen dat 'ie ook je code in kan zien.

crisp schreef op donderdag 15 september 2011 @ 08:13:
[...]

Bij ons is dit een wachtwoord van 38 bytes; het komt namelijk zo aan op de server:

code:

ლ(ಠ益ಠ)ლ

(en wordt vervolgens afgekeurd vanwege geen letters)

Het lijkt me zeer sterk dat een wachtwoordveld door de server eerst gehtmlencode wordt, voordat 't naar de database gaat. De client levert 't niet zo aan, namelijk.

[ Voor 18% gewijzigd door CyBeR op 15-09-2011 10:06 ]

[.oisyn]

crisp schreef op donderdag 15 september 2011 @ 08:13:
[...]

Bij ons is dit een wachtwoord van 38 bytes; het komt namelijk zo aan op de server:

code:

ლ(ಠ益ಠ)ლ

Dat hoop ik toch echt van niet, want om je wachtwoord door htmlspecialchars() oid te gooien gaat dus echt nergens over

[ Voor 9% gewijzigd door .oisyn op 15-09-2011 11:21 ]

[crisp]

.oisyn schreef op donderdag 15 september 2011 @ 11:20:
[...]

Dat hoop ik toch echt van niet, want om je wachtwoord door htmlspecialchars() oid te gooien gaat dus echt nergens over

Dat doen wij niet, dat doet je browser...

CyBeR schreef op donderdag 15 september 2011 @ 10:05:
[...]

Het lijkt me zeer sterk dat een wachtwoordveld door de server eerst gehtmlencode wordt, voordat 't naar de database gaat. De client levert 't niet zo aan, namelijk.

De client levert het dus wel zo aan via een pagina die als ISO-8859-15 geserveerd is...

[ Voor 39% gewijzigd door crisp op 15-09-2011 11:25 ]

[.oisyn]

Nee hoor, je browser gaat echt geen html entities maken van tekst. Hij post het als application/x-www-form-urlencoded, dus de tekens worden geurlencode:

%26%234314%3B%28%26%233232%3B%26%2330410%3B%26%233232%3B%29%26%234314%3B

Vervolgens zie je die data niet, want PHP decodet dat weer als een UTF-8 string. Je script ziet dus gewoon 17 tekens. Hoe de pagina geserveerd wordt doet er niet toe.

.edit: blijkbaar zitten daar wel html entities in . Dan hebben jullie waarschijnlijk gewoon een script dat dat doet. Why?!

[ Voor 19% gewijzigd door .oisyn op 15-09-2011 11:34 ]

[crisp]

.oisyn schreef op donderdag 15 september 2011 @ 11:29:
[...]
.edit: blijkbaar zitten daar wel html entities in . Dan hebben jullie waarschijnlijk gewoon een script dat dat doet. Why?!

Het is echt serieus je browser die dat doet; testscriptje:

PHP:

<?php

header('Content-Type: text/html; charset=ISO-8859-15');

?>
<!doctype html>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
<form action="" method="post">
    <input name="s" type="text">
    <input type="submit">
</form>
<p>POST:</p>
<pre><?php
    echo htmlspecialchars(print_r($_POST, 1));
?></pre>

En als je wilt verifieren dat het niet PHP is die stom doet, check dan ook maar wat er over de lijn gaat

[CyBeR]

Ik sta gecorrigeerd. Voor ISO-8859-15 geldt dat inderdaad.

Ik stel voor dat t.net een beetje rap-achtig met de tijd meegaat en UTF-8 gaat gebruiken.

Kut, net te laat om niet gequote te worden

[ Voor 92% gewijzigd door CyBeR op 15-09-2011 12:02 ]

[crisp]

CyBeR schreef op donderdag 15 september 2011 @ 11:57:
[...]


Dat doet mijn browser niet zonder het verteld te worden.


[...]


Als jullie er een script tussen proppen (waarom in godsnaam?) dat eerst alle velden htmlencode, dan wel ja, maar zolang jullie geen domme scripts inserten (even tussendoor, scripts die shit uithalen met je wachtwoord == giant red flag) komt 't gewoon als UTF-8 aan. Hoogstens urlencoded zoals .oisyn al zegt.

Test het zelf met het script hierboven als je me niet geloofd...

[.oisyn]

Ah, wederom een gat in de HTTP standaard. Niemand zegt wat er moet gebeuren als je een karakter wilt encoden dat niet in je encoding past. De ene browser stuurt een HTML entity, de ander luistert naar RFC3986 en encodet 'm gewoon als UTF-8. Of ze worden gewoon gereplaced met een willekeurig karakter (zoals een vraagteken) .

Lekker handig voor de inlogprocedure ook. Dat betekent dat als je je wachtwoord wijzigt met de ene browser, je mogelijk niet kan inloggen met de andere browser

[crisp]

.oisyn schreef op donderdag 15 september 2011 @ 12:27:
Ah, wederom een gat in de HTTP standaard. Niemand zegt wat er moet gebeuren als je een karakter wilt encoden dat niet in je encoding past. De ene browser stuurt een HTML entity, de ander luistert naar RFC3986 en encodet 'm gewoon als UTF-8. Of ze worden gewoon gereplaced met een willekeurig karakter (zoals een vraagteken) .

Lekker handig voor de inlogprocedure ook. Dat betekent dat als je je wachtwoord wijzigt met de ene browser, je mogelijk niet kan inloggen met de andere browser

Alle major browsers doen dat hetzelfde; het staat ook in de HTML5 specificatie

[crisp]

CyBeR schreef op donderdag 15 september 2011 @ 11:57:
Ik sta gecorrigeerd. Voor ISO-8859-15 geldt dat inderdaad.

Ik stel voor dat t.net een beetje rap-achtig met de tijd meegaat en UTF-8 gaat gebruiken.

mja, we zouden wel willen maar zolang PHP nog niet volledig unicode-compliant is en dat dus ook een hoop workarounds vergt beginnen we daar liever nog niet aan (het is sowieso een behoorlijke ingreep)...

[.oisyn]

crisp schreef op donderdag 15 september 2011 @ 12:46:
[...]

Alle major browsers doen dat hetzelfde; het staat ook in de HTML5 specificatie

Ah ok

[ Voor 8% gewijzigd door .oisyn op 15-09-2011 13:49 ]

[Wolfboy]

CyBeR schreef op donderdag 15 september 2011 @ 10:05:
[...]


Zonder de salt kan de originele code er ook niets mee. Als iemand de hash heeft is 't veilig om aan te nemen dat 'ie de salt ook heeft. Dat zijn namelijk stukjes informatie die onlosmakelijk met elkaar verbonden zijn. En zodanig ook meestal gewoon aan elkaar geplakt in de db staan. Bijvoorbeeld, UNIX password hashes:

Ik zat meer te denken aan het stelen van de hashes alleen, maar als je beiden hebt dan heb je uiteraard volledig gelijk

Salt ervoor of salt erachter, mwah maakt alles *2 als je 't niet weet, niet zo spannend dus in the grand scheme of things. Verder: als een aanvaller je wachtwoordendatabase heeft is 't ook alweer niet onredelijk om aan te nemen dat 'ie ook je code in kan zien.

Mwah... kan. Al zie ik toch vaker SQL injection exploits waarbij alle data zichtbaar is dan exploits waarbij de hele code ook zichtbaar is.

Niet ondenkbaar natuurlijk, maar zeker geen gegeven.

[CyBeR]

Wolfboy schreef op donderdag 15 september 2011 @ 15:18:
[...]
Ik zat meer te denken aan het stelen van de hashes alleen, maar als je beiden hebt dan heb je uiteraard volledig gelijk

Aangezien de salt en de hash eigenlijk nooit apart worden opgeslagen, kun je stellen dat de kans dat iemand alleen de hash heeft vrij klein is.

Mwah... kan. Al zie ik toch vaker SQL injection exploits waarbij alle data zichtbaar is dan exploits waarbij de hele code ook zichtbaar is.

Niet ondenkbaar natuurlijk, maar zeker geen gegeven.

Uiteraard kan het zo zijn dat iemand alleen de database-gegevens te pakken krijgt. Maar dan geldt nog steeds dat het niet weten of de salt voor- of achteraan moet, bijvoorbeeld, slechts een verdubbeling van de search space betekent. En dat is er van uitgaande dat je dom bent.

Over het algemeen is het namelijk moeilijker om die data úit de tabel te krijgen dan data er ín te krijgen. Dat kun je namelijk doen door een account aan te maken. Daarna weet je het wachtwoord van dat account (dat heb je er immers zelf in zitten proppen) en kun je het weer extraheren zoals geprocessed door het systeem. Gegeven dat je de plaintext weet is het achterhalen welke soort hash er precies gebruikt is en welke manier over 't algemeen een kwestie van een paar mogelijkheden proberen.

[Mentalist]

CyBeR schreef op donderdag 15 september 2011 @ 15:43:
Aangezien de salt en de hash eigenlijk nooit apart worden opgeslagen, kun je stellen dat de kans dat iemand alleen de hash heeft vrij klein is.

De salt kan toch in een los bestand staan, buiten de webroot, dat je include met PHP?

[...]

Uiteraard kan het zo zijn dat iemand alleen de database-gegevens te pakken krijgt. Maar dan geldt nog steeds dat het niet weten of de salt voor- of achteraan moet, bijvoorbeeld, slechts een verdubbeling van de search space betekent. En dat is er van uitgaande dat je dom bent.

En als je nou echt een klotesalt neemt?

Neem bijvoorbeeld dit als basis-salt:

F];^rzm4p~<xD.RoPs3$v%7r;?'=WmG[4"fx4QX?#YhwWMzN@ShKe$&8XUtY-T@

Dat vul je dan aan met (extrasalt):

Wachtwoordhash start met (of neem karakter X van de hash):
A: "lorem"
B: "ipsum"
C: "dolor"
etc

En dan maak je de finale hash (tis lang geleden dat ik PHP heb gedaan, maar je snapt wat ik bedoel, je kan beter geen md5 gebruiken natuurlijk ):

$hashvoordatabase = md5($basissalt.$wachtwoordhash.$extrasalt);

Zelfs bruteforce lijkt me zo vrij lastig en de volledige hashmethode kan je alleen achterhalen met toegang tot de harde schijf van de server.

[.oisyn]

W3ird_N3rd schreef op donderdag 15 september 2011 @ 20:52:
[...]

De salt kan toch in een los bestand staan, buiten de webroot, dat je include met PHP?

Het is niet per se de bedoeling van een salt dat ie onbekend moet blijven. Waar het om gaat is dat, door elke gebruiker een eigen salt te geven, rainbowtables niet meer geschikt zijn om te gebruiken.

Als je de salt in een apart bestand op gaat slaan, waarom deed je dat dan niet al met het wachtwoord zelf?

[ Voor 5% gewijzigd door .oisyn op 15-09-2011 20:58 ]

[Mentalist]

.oisyn schreef op donderdag 15 september 2011 @ 20:56:
[...]

Het is niet per se de bedoeling van een salt dat ie onbekend moet blijven. Waar het om gaat is dat, door elke gebruiker een eigen salt te geven, rainbowtables niet meer geschikt zijn om te gebruiken.

Hmm, salten adhv. de gebruikersnaam ofzo? Misschien ook wel leuk.

Je kan iig dusdanig complex salten dat het eigenlijk niet te bruteforcen is. Desnoods stop je de laatste transformers film in base64 in je salt.

Als je de salt in een apart bestand op gaat slaan, waarom deed je dat dan niet al met het wachtwoord zelf?

Omdat je op deze manier de PHP-code, dat aparte bestand èn de database te pakken moet krijgen. En omdat wachtwoorden of hashes in losse bestanden niet zo praktisch zijn?

[.oisyn]

W3ird_N3rd schreef op donderdag 15 september 2011 @ 20:59:
[...]

Hmm, salten adhv. de gebruikersnaam ofzo? Misschien ook wel leuk.

Op zich een optie maar geeft moeilijkheden als je een gebruikersnaam wilt kunnen wijzigen (je weet het originele wachtwoord niet, dus je kunt ook geen nieuwe hash berekenen). Typisch sla je gewoon een random string op bij de hash van het wachtwoord

Omdat je op deze manier de PHP-code, dat aparte bestand èn de database te pakken moet krijgen. En omdat wachtwoorden of hashes in losse bestanden niet zo praktisch zijn?

Als wachtwoorden opslaan in aparte bestanden niet zo praktisch is, waarom zou dat met salts dan wel zo zijn?

[CyBeR]

W3ird_N3rd schreef op donderdag 15 september 2011 @ 20:52:
[...]

De salt kan toch in een los bestand staan, buiten de webroot, dat je include met PHP?

Dat zou inhouden dat de salt voor elke gebruiker hetzelfde is. Dat doet het punt van salted wachtwoordhashes nogal teniet.

Bovendien: de salt hoeft niet geheim te blijven. Die dient slechts twee redenen: het gebruik van rainbow tables onmogelijk (of toch op z'n mist heel irritant) te maken, en ervoor zorgen dat twee gebruikers die hetzelfde wachtwoord gebruiken, niet dezelfde hash hebben.

Idealiter is de salt dus gewoon 100% random.

En als je nou echt een klotesalt neemt?

Neem bijvoorbeeld dit als basis-salt:

F];^rzm4p~<xD.RoPs3$v%7r;?'=WmG[4"fx4QX?#YhwWMzN@ShKe$&8XUtY-T@

Dat vul je dan aan met (extrasalt):

Wachtwoordhash start met (of neem karakter X van de hash):
A: "lorem"
B: "ipsum"
C: "dolor"
etc

En dan maak je de finale hash (tis lang geleden dat ik PHP heb gedaan, maar je snapt wat ik bedoel, je kan beter geen md5 gebruiken natuurlijk ):

$hashvoordatabase = md5($basissalt.$wachtwoordhash.$extrasalt);

Zelfs bruteforce lijkt me zo vrij lastig en de volledige hashmethode kan je alleen achterhalen met toegang tot de harde schijf van de server.

Tsja, je maakt 't inderdaad iets lastiger en de eerste drie kneuzen zullen waarschijnlijk afhaken maar écht een veiliger geheel heb je er niet mee.


Voor de duidelijkheid: salts zijn in zichzelf geen beveiliging van hashes ofzo. Ze dienen alleen om het brute-forcen moeilijker te maken.

[ Voor 4% gewijzigd door CyBeR op 15-09-2011 21:37 ]

[Osiris]

CyBeR schreef op donderdag 15 september 2011 @ 21:35:
Voor de duidelijkheid: salts zijn in zichzelf geen beveiliging van hashes ofzo. Ze dienen alleen om het brute-forcen moeilijker te maken.

Afhankelijk van hoe je de salt implementeert natuurlijk denk ik niet dat 't echt veel tegen brute-forcen doet.. Immers, als ik uit mijn brute-force-proggie het volgende terugkrijg: "4QX?#YhwWMhottentottententententoonstelling" dan weet ik wel wat de salt en wat het wachtwoord is

Je eerder genoemde rainbowtables daarentegen

[ Voor 5% gewijzigd door Osiris op 15-09-2011 21:41 ]

[.oisyn]

Behalve dat jij uit je brute force nooit zo'n lang wachtwoord zult krijgen. Áls je gaat brute forcen, dan doe je dat met kennis van de salt zelf (dus niet hash($poging) maar hash($salt . $poging)), want dat scheelt een hele hoop tijd. Per gebruiker is de tijd om het wachtwoord te kraken dan weliswaar niet zoveel groter als zonder salt, maar je kunt niet meer alle gebruikers tegelijk doen.

[ Voor 73% gewijzigd door .oisyn op 15-09-2011 22:56 ]

[Mentalist]

.oisyn schreef op donderdag 15 september 2011 @ 21:02:
[...]

Als wachtwoorden opslaan in aparte bestanden niet zo praktisch is, waarom zou dat met salts dan wel zo zijn?

Omdat ik eraan dacht om het allemaal met één salt te doen die voor iedere gebruiker hetzelfde is. Met die salt erbij re-hash je natuurlijk, dus het is met 1000 hashes voor je neus niet obvious wat de salt is.

Iedere user een eigen salt geven geeft zover ik me kan bedenken theoretisch ook geen extra veiligheid. Sterker nog, omdat iedere user een eigen salt krijgt stop je die salt waarschijnlijk (omdat het makkelijk is) ook in de database - ligt je salt alsnog op straat als de database is gehackt. Ik lees nu de post van .oisyn, het kraken zal inderdaad een stuk langer duren.

CyBeR schreef op donderdag 15 september 2011 @ 21:35:
Dat zou inhouden dat de salt voor elke gebruiker hetzelfde is. Dat doet het punt van salted wachtwoordhashes nogal teniet.

Waarom?

Vertel mij, waarom? Ik kan me niet verzinnen waarom dat het punt teniet doet. Je breekt rainbowtables en je kan zonder de salt geen aanval beginnen.

Bovendien: de salt hoeft niet geheim te blijven. Die dient slechts twee redenen: het gebruik van rainbow tables onmogelijk (of toch op z'n mist heel irritant) te maken, en ervoor zorgen dat twee gebruikers die hetzelfde wachtwoord gebruiken, niet dezelfde hash hebben.

Hmm, met dat tweede heb je een punt. Ook al is dat op zich ook geen heel groot probleem zolang je nog steeds niks kan kraken.

Tsja, je maakt 't inderdaad iets lastiger en de eerste drie kneuzen zullen waarschijnlijk afhaken maar écht een veiliger geheel heb je er niet mee.

Hoe kraak je zoiets dan? Bruteforce gaat niet volgens mij, daarvoor is de basissalt al te lang.

Osiris schreef op donderdag 15 september 2011 @ 21:40:
[...]

Afhankelijk van hoe je de salt implementeert natuurlijk denk ik niet dat 't echt veel tegen brute-forcen doet.. Immers, als ik uit mijn brute-force-proggie het volgende terugkrijg: "4QX?#YhwWMhottentottententententoonstelling" dan weet ik wel wat de salt en wat het wachtwoord is

Je eerder genoemde rainbowtables daarentegen

Met mijn methode gaat dat dus niet, want de zon is met een beetje pech opgebrand tegen de tijd dat jouw bruteforceproggie mijn 63 random karakters(+extrasalt+wachtwoordhash) heeft gebruteforced.

Dus het beste is volgens mij een random salt per gebruiker om bruteforce te vertragen en een geheime niet-unieke salt buiten de webroot om enige aanval waarbij de hacker de geheime salt niet heeft weten te verkrijgen volstrekt nutteloos te maken.

[ Voor 5% gewijzigd door Mentalist op 15-09-2011 22:56 ]

[.oisyn]

W3ird_N3rd schreef op donderdag 15 september 2011 @ 22:49:
Waarom?

Vertel mij, waarom? Ik kan me niet verzinnen waarom dat het punt teniet doet. Je breekt rainbowtables en je kan zonder de salt geen aanval beginnen.

Je kunt een nieuwe rainbowtable genereren die je op alle gebruikers kunt toepassen. En hoe meer gebruikers, hoe interessanter het wordt om een dergelijke custom rainbowtable te genereren.

[ACM]

W3ird_N3rd schreef op donderdag 15 september 2011 @ 22:49:
Waarom?

Vertel mij, waarom? Ik kan me niet verzinnen waarom dat het punt teniet doet. Je breekt rainbowtables en je kan zonder de salt geen aanval beginnen.

De aanleiding van deze en de diverse andere discussies was ons onderzoek waarbij we een dictionary-attack uitvoerden. Die attack werkt door domweg woorden uit een lijstje te halen (of varianten erop te genereren) en die te hashen. Als je zo'n hash dan tegen 300.000 losse wachtwoorden aan kan houden is dat een hele efficiente manier om het gehele wachtwoordbestand te kraken. Het genereren van hashes is relatief duur, het vergelijken ervan is relatief goedkoop ook tegen een hele berg wachtwoorden.

In jouw voorstel is het slechts heel marginaal duurder om de salt te moeten gebruiken dan om gewoon geen salt te hebben bij de door ons uitgevoerde aanval. Als je er voor zorgt dat elke opgeslagen hash een eigen salt heeft, zorg je er automatisch voor dat je niet meer 300.000 vergelijkingen met 1 gegenereerde hash kunt doen, maar dat je de hele hash-constructieprocedure per wachtwoord moet uitvoeren.
En dat was nou net het 'dure' deel... dus hoe meer je een eventuele aanvaller dwingt dat te herhalen, hoe beter.

E.e.a. is natuurlijk wel te combineren, een losse systeem-salt kan gebruikt worden zodat een gevonden wachtwoordlijst nog een component mist, dat elders staat opgeslagen. Maar echt heel veel voegt dat niet toe voor de beveiliging.

Hoe kraak je zoiets dan? Bruteforce gaat niet volgens mij, daarvoor is de basissalt al te lang.

Zodra je de basissalt weet is de lengte totaal niet van belang. Je zult sowieso ervan uit moeten gaan dat als je wachtwoordlijst achterhaald kon worden, dat ook je basissalt dan niet veilig is...

[Mentalist]

.oisyn schreef op donderdag 15 september 2011 @ 22:58:
[...]

Je kunt een nieuwe rainbowtable genereren die je op alle gebruikers kunt toepassen. En hoe meer gebruikers, hoe interessanter het wordt om een dergelijke custom rainbowtable te genereren.

Je kan zonder salt helemaal niets genereren.

ACM schreef op donderdag 15 september 2011 @ 23:16:
[...]

De aanleiding van deze en de diverse andere discussies was ons onderzoek waarbij we een dictionary-attack uitvoerden. Die attack werkt door domweg woorden uit een lijstje te halen (of varianten erop te genereren) en die te hashen. Als je zo'n hash dan tegen 300.000 losse wachtwoorden aan kan houden is dat een hele efficiente manier om het gehele wachtwoordbestand te kraken. Het genereren van hashes is relatief duur, het vergelijken ervan is relatief goedkoop ook tegen een hele berg wachtwoorden.

In jouw voorstel is het slechts heel marginaal duurder om de salt te moeten gebruiken dan om gewoon geen salt te hebben bij de door ons uitgevoerde aanval. Als je er voor zorgt dat elke opgeslagen hash een eigen salt heeft, zorg je er automatisch voor dat je niet meer 300.000 vergelijkingen met 1 gegenereerde hash kunt doen, maar dat je de hele hash-constructieprocedure per wachtwoord moet uitvoeren.
En dat was nou net het 'dure' deel... dus hoe meer je een eventuele aanvaller dwingt dat te herhalen, hoe beter.

Ik begrijp het (begreep het na de post van .oisyn ook al, die ik nog niet had gezien toen ik dat postte ).

Maar dan nog is een geheime salt niet zinloos.

E.e.a. is natuurlijk wel te combineren, een losse systeem-salt kan gebruikt worden zodat een gevonden wachtwoordlijst nog een component mist, dat elders staat opgeslagen. Maar echt heel veel voegt dat niet toe voor de beveiliging.

Het is relatief simpel toe te voegen en àls de systeem-salt dan niet is gelekt dan reduceer je de kraak van de gelekte database van "dit gaat even duren" naar "vergeet het maar".

Zodra je de basissalt weet is de lengte totaal niet van belang.

Dat begrijp ik, maar ik ga er juist vanuit dat je de hacker die mogelijk niet te pakken krijgt.

Je zult sowieso ervan uit moeten gaan dat als je wachtwoordlijst achterhaald kon worden, dat ook je basissalt dan niet veilig is...

Dat is inderdaad mogelijk, maar het is toch een extra drempel. Er zijn ook veel hacks waarbij de hacker alleen de database weet binnen te hengelen, in die gevallen is de database absoluut waardeloos als je zo'n geheime salt hebt.

[CyBeR]

W3ird_N3rd schreef op donderdag 15 september 2011 @ 23:35:
[...]


Maar dan nog is een geheime salt niet zinloos.

[...]

Het is relatief simpel toe te voegen en àls de systeem-salt dan niet is gelekt dan reduceer je de kraak van de gelekte database van "dit gaat even duren" naar "vergeet het maar".

[...]

Dat begrijp ik, maar ik ga er juist vanuit dat je de hacker die mogelijk niet te pakken krijgt.

Voor dit soort data (in essentie configuratiedata) kun je er niet van uitgaan dat die geheim blijft. Als een haxx0rer inbreekt is zoiets het eerste waar 'ie achteraan gaat. En dan heb je dus een probleem: je wilt dan eigenlijk je salt veranderen, maar dat kan niet want je weet niet hoe je de wachtwoorden dan opnieuw moet hashen. Hier veroorzaak je dus een probleem voor jezelf. Zelfs als 't geen inbreker was maar een configuratiefout (zoals .php's die niet intepreted worden, dat komt nog best vaak voor) dan is je salt compromised en moet je dus een nieuwe gebruiken. Kan niet.

Dat is inderdaad mogelijk, maar het is toch een extra drempel. Er zijn ook veel hacks waarbij de hacker alleen de database weet binnen te hengelen, in die gevallen is de database absoluut waardeloos als je zo'n geheime salt hebt.

Die extra drempel is alleen niet zo heel boeiend voor je beveiliging. Een salt helpt tegen rainbow tables en (als bijkomstigheid) identieke hashes, meer niet. Je moet 't ook niet voor meer dan dat gebruiken.

En met een enkele systeemsalt heb je dat laatste voordeel dus niet en dat eerste is dan ook al niet meer boeiend want in plaats van md5(passwd) laat de hacker z'n systeem gewoon md5(salt+pw) uitrekenen. Een compleet oninteressante stap dus. Zoals je wellicht in het artikel las is kraken tegenwoordig ongeveer even snel als een rainbow table downloaden.

[ Voor 17% gewijzigd door CyBeR op 16-09-2011 01:03 ]

[Verwijderd]

Een geheime salt is zinloos want de salt maakt dan technisch gezien deel uit van het wachtwoord.