:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
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...
Hulp wordt niet gewaardeerd. Zoek het dus zelf uit
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.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 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
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
.
Viva-forum heeft volgens mij geen expliciet verkoop-gedeelte waardoor imho oplichting een veel minder grote rol gaat spelen.:
[...]
Tegelijkertijd kom ik dagelijks op tweakers en heb ik het echt wel door als er iets in mijn postgeschiedenis staat waarvan ik niets weet
Hier is een los stukje marktplaats waar meubelstuk zijn imho toch ietwat meeteelt aan de vertrouwensbasis. Oftewel wat extra uitgebuit kan worden bij misbruik.
:strip_exif()/u/3333/pumpkin_avatar.gif?f=community){kind=avatar}
Zie Ceritficaat error:
[...]
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
Intentionally left blank
/u/34216/avatar-60x60.png?f=community){kind=avatar}
:strip_exif()/u/2087/osiris_ani.gif?f=community)
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 ]
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.
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.
Same difference. Dan doe je je metingen nog een keer en krijg je alles gedeeld door 1.4:
Maar dit is geen SHA-1, maar een SHA-2-variant, welke volgens Wikipedia 1,4x zo langzaam is
De snelheid waarmee SHA1 en SHA2-256 zich tot elkaar verhouden is verder lineair qua data-doorvoer.
All my posts are provided as-is. They come with NO WARRANTY at all.
:strip_exif()/u/18996/GoT_avatar.gif?f=community){kind=avatar}
Ok... laten we hier beginnen. 8 tekens, 26 letters.
26 ^ 8 = 208827064576 mogelijkheden
Als het op dezelfde lokatie staat... inderdaad niet zinnig, anders verdubbelt het opeens de hoeveelheid tekens
52 ^ 8 = 53459728531456
Ok... dit vergroot de mogelijkheden.
10 cijfers + ~20 speciale tekens?
Now we're getting somewhere...
82 ^ 8 = 2044140858654976
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
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.:
[...]
De eisen zijn slim genoeg imho
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 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
:strip_icc():strip_exif()/u/37421/kt666.jpg?f=community)
Ik heb geen notificatiebalk of mailtje gekregen (ik zit bij de "goede" 50%:
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.
), 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.Dat is natuurlijk helemaal geen probleem als je op je werk achter NAT of een proxy zit.
Wat de neuk ìs een productteam en waarom werkt dat onafhankelijk van de crew?:
Fair enough
.edit: nee, eigenlijk niet fair enough. Waarom beslist een productteam over dergelijke eisen?
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:
HTML:
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?
Overigens:
Vele uren? Moet je dan geen 9 of 10 tekens vereisen?
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 ]
Verstuurd vanaf mijn Computer®
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'.
Ik zeg: pak PHP + CURL erbij en probeer het?:
Mag ik trouwens een carriage return in mijn wachtwoord hebben?
[ Voor 17% gewijzigd door Osiris op 14-09-2011 04:22 ]
Dat zou ik ook voorstellen. Maak er gewoon 1024 van ofzo, het is te hopen dat niemand daaraan komt.:
[...]
Dat kan nu natuurlijk sowieso nog wel; je zult 't altijd nog server-side moeten checken uiteraard
En ik bedoelde 't ook eigenlijk als 'opkrikken naar een limiet die in de praktijk niet gehaald zal worden'.
Ik bedoelde het meer als "Mag ik alsjeblieft een carriage return in mijn wachtwoord op t.net hebben?[...]
Ik zeg: pak PHP + CURL erbij en probeer het?
".
Verstuurd vanaf mijn Computer®
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/1/femme.png?f=community)
Mooi, dan zijn we het volgens mij allemaal eens met elkaar. Waar is het productteam?
Waar is het productteam?
Verstuurd vanaf mijn Computer®
Want dat stimuleert wachtwoord hergebruik totaaaaaal niet:
[...]
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
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.
Dat ben ik dus, bonzz.netninja en MI6:
Mooi, dan zijn we het volgens mij allemaal eens met elkaar.
.
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":
[...]
Want dat stimuleert wachtwoord hergebruik totaaaaaal niet
Intentionally left blank
Waarom beslissen jij, bonzz.netninja en MI6 dan stomme dingen?:
[...]
Dat ben ik dus, bonzz.netninja en MI6
>"Overigens vind ik het persoonlijk niet verkeerd om enigszins dwingend het gebruik van een relatief sterk wachtwoord te forceren":
[...]
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"
<"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 ]
Verstuurd vanaf mijn Computer®
/u/105682/crop5f9808e589a0e_cropped.png?f=community)
:strip_icc():strip_exif()/u/354461/images.jpg?f=community)
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.
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 ]
mobo: Asus Prime B450-Plus // cpu: AMD Ryzen 5 2600X // graka: Asus Dual Radeon RX 580 OC 8GB GDDR5 // mem: Corsair Vengeance LPX CMK16GX4M2B3200C16 // opslag: Crucial MX500 500GB
:strip_icc():strip_exif()/u/2646/shine.jpg?f=community)
Dit is echt een schitterend gebied vanwege de vele literatuur die er over beschikbaar is inclusief empirische resultaten:
[...]
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"
Specifiek over bovenstaande password mnemonics: Human selection of mnemonic phrase-based 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 ]
In UTF-8 zijn het ook 17 bytes hoor
Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?
Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Oh mischien heeft 'wc' de newline erbij geteld. 17, 18, bleh:
In UTF-8 zijn het ook 17 bytes hoor
Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?
All my posts are provided as-is. They come with NO WARRANTY at all.
Bij ons is dit een wachtwoord van 38 bytes; het komt namelijk zo aan op de server::
In UTF-8 zijn het ook 17 bytes hoor
Overigens ben ik wel benieuwd over welke encoding CyBeR het dan heeft?
code:
(en wordt vervolgens afgekeurd vanwege geen letters) 1
| ლ(ಠ益ಠ)ლ |
[ Voor 6% gewijzigd door crisp op 15-09-2011 08:14 ]
Intentionally left blank
:strip_exif()/u/102476/apple2.gif?f=community)
/u/37496/icon.png?f=community){kind=icon}
En in deze heeft Femme de lead:
[...]
Dat ben ik dus, bonzz.netninja en MI6
(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 ]
vuistdiep in het post-pc tijdperk van Steve | Joepie joepie. Dat ging echt toppie! | https://www.dedigitaletuin.nl
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.
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.:
[...]
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 18% gewijzigd door CyBeR op 15-09-2011 10:06 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
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 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat doen wij niet, dat doet je browser...:
[...]
Dat hoop ik toch echt van niet, want om je wachtwoord door htmlspecialchars() oid te gooien gaat dus echt nergens over
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 ]
Intentionally left blank
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?!
%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 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het is echt serieus je browser die dat doet; testscriptje::
[...]
.edit: blijkbaar zitten daar wel html entities in
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| <?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
Intentionally left blank
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
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 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
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
.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
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Alle major browsers doen dat hetzelfde; het staat ook in de HTML5 specificatie:
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
Intentionally left blank
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik zat meer te denken aan het stelen van de hashes alleen, maar als je beiden hebt dan heb je uiteraard volledig gelijk
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.
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.:
[...]
Ik zat meer te denken aan het stelen van de hashes alleen, maar als je beiden hebt dan heb je uiteraard volledig gelijk
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.
All my posts are provided as-is. They come with NO WARRANTY at all.
De salt kan toch in een los bestand staan, buiten de webroot, dat je include met PHP?
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.
Verstuurd vanaf mijn Computer®
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
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.
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?
Verstuurd vanaf mijn Computer®
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
Als wachtwoorden opslaan in aparte bestanden niet zo praktisch is, waarom zou dat met salts dan wel zo zijn?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
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.
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.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.
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 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
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 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
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.:
[...]
Als wachtwoorden opslaan in aparte bestanden niet zo praktisch is, waarom zou dat met salts dan wel zo zijn?
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.
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.
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.
Hoe kraak je zoiets dan? Bruteforce gaat niet volgens mij, daarvoor is de basissalt al te lang.
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.:
[...]
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
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 ]
Verstuurd vanaf mijn Computer®
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/1830/acm.png?f=community)
Je kan zonder salt helemaal niets genereren.
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.
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.
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.
Verstuurd vanaf mijn Computer®
:strip_exif()/u/172480/thunder_small.gif?f=community)
Mijn vertrouwde wachtwoord zonder hoofdletter: 27 bits. Uitstekelbaars
.edit: wel apart dat hoofdletters meer entropie opleveren dan kleine letters.
.edit: wel apart dat hoofdletters meer entropie opleveren dan kleine letters.
[ Voor 35% gewijzigd door .oisyn op 16-09-2011 17:49 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Met 1 teken erbij is het wel genoeg
Randgevallen zal je altijd houden waarbij de gebruiker het 'wel voldoende' vindt, maar ons algoritme het daar niet mee eens is...
Daar ben ik het niet geheel mee eens. Het is gebleken dat je de gemiddelde gebruiker op het gebied van wachtwoorden best als 'dom' kan beschouwen, dus er mag best wat opvoedkundige waarde uitgaan van een wachtwoordpolicy, vermits die policy ook redelijk is en de gebruiker weer niet te veel belemmerd in het kiezen van een goed wachtwoord.
Redelijkheid is in het geding als de policy bepaalde eisen stelt die niet noodzakelijk bijdragen aan extra veiligheid bij een bepaald gekozen wachtwoord, dus moeten die eisen worden bijgesteld zodat het een betere indicatie geeft van de veiligheid van een bepaald wachtwoord. De entropy-berekening van ACM is een methode daartoe, maar we doen eigenlijk al langer een soort entropybereking van het wachtwoord in de vorm van de wachtwoordsterktemeter - alles wat minder dan 'vrij sterk' is zouden we eigenlijk kunnen afwijzen.
Je kan pleiten voor 'geen restricties', maar wij als Tweakers.net hebben ook een bepaalde zorgplicht naar onze gebruikers, waaronder de zorg om persoonsgegevens veilig te bewaren. Dat betekent dus automatisch dat wij verplicht zijn om een bepaalde mate van beveiliging op te dringen aan onze gebruikers waar het om hun account gaat.
Intentionally left blank
Maargoed mijn favoriete wachtwoord bestaat dus uit random 6 kleine letters + 2 cijfers. Deze is toch veilig tegen dictionary en bruteforce attacks. Om maar even een voorbeeld te nemen, google geeft aan dat mijn wachtwoord 'sterk' is.:
[...]
Met 1 teken erbij is het wel genoeg
Randgevallen zal je altijd houden waarbij de gebruiker het 'wel voldoende' vindt, maar ons algoritme het daar niet mee eens is...
[...]
Ik denk dus het algoritme te streng is.
Had al wel verwacht dat niet iedereen mijn mening zou delen
. Ik ga hier dan ook verder niet op in. Niet om de discussie uit de weg te gaan, maar om het een beetje ontopic te houden.
[ Voor 44% gewijzigd door stereohead op 18-09-2011 10:23 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik ga er voor het gemak vanuit dat het huidige algoritme ook wel weer eens gekraakt zal worden.
En het aantal mogelijkheden met 8 karakters is blijkbaar gewoon snel genoeg te doorlopen.
Verstuurd vanaf mijn Computer®
Je wachtwoord is binnen een paar minuten gekraakt bij gebruik van MD5:
http://golubev.com/gpuest.htm
Met 10 miljard pogingen per seconde op een nieuwe GPU gaat het hard
Een wachtwoord bestaande uit alleen kleine letters plus cijfers met lengte 8 heeft slechts 36^8 = 2821109907456 (ca 2821 miljard) oplossingen.Gemiddeld genomen zal het wachtwoord dan dus gevonden worden na 2821 / 10 / 2 = 141 seconden oftewel 2 minuten en 21 seconden
Ter vergelijk PKBDF2 oplossingen zoals nu door tweakers toegepast zijn te vergelijken met de methoden voor MS Office 2007, WinZip/AES en WPA (iteraties verschillen, hash algo's evt ook) die slechts 50 duizend tot 1 miljoen passwords per seconde kunnen testen (zie gelinkte tabel).
Concreet: je wachtwoord kun je echt beter wat langer/complexer maken en een update zoals nu door t.net snijdt hout
[ Voor 10% gewijzigd door Rukapul op 18-09-2011 17:49 ]
MD5 is niet gekraakt (niet in de context van het omkeren van een hash althans - hij is hoogstens niet meer collision-resistant, wat voor de toepassing van het opslaan van wachtwoorden weinig uitmaakt). Het doel van MD5 is een snel message digest algoritme met een goede distributie van de hash space. Juist die eigenschap "snel" maakt het eigenlijk ongeschikt voor het gebruik van het hashen van wachtwoorden - dat is het feitelijk altijd al geweest.:
[...]
Ik ga er voor het gemak vanuit dat het huidige algoritme ook wel weer eens gekraakt zal worden.
Daarnet zei ik dat t.net geen MD5 meer gebruikt - dat is niet per se waar. Wat ik eigenlijk bedoelde te zeggen was dat ze geen md5($password) meer deden. PBKBF is een key derivation function dat gebruik maakt van key stretching en een bestaand hasing algoritme om de tijd van een enkele hash zo lang mogelijk te maken. Het is prima mogelijk om MD5 te gebruiken als hashing algoritme voor PBKBF, en feitelijk staat nergens dat t.net dat niet doet.
[ Voor 43% gewijzigd door .oisyn op 18-09-2011 18:55 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik moet zeggen dat jouw post ook wel hout snijdt:
[...]
Concreet: je wachtwoord kun je echt beter wat langer/complexer maken en een update zoals nu door t.net snijdt hout
.Maar alsnog, waarom een T.net password 'veiliger' maken dan b.v. een gmail password. Ik neem aan dat google ook wel serieus nadenkt over dit soort kwesties.
Ik vind het positief dat T.net haar users op de hoogte brengt van de veiligheid van hun wachtwoorden. Maar vind nog steeds dat het de verantwoordelijkheid van de gebruiker is om een veilig wachtwoord te kiezen.
Je mag als T.net dan wel een zorgplicht hebben, maar 'zorgen' betekend niet dat je je users met een stok moet gaan slaan tot ie z'n bord leeg vreet.
Sorry dat ik zo eigenwijs ben, maar ik wil graag m'n huidige, slechte wachtwoord vervangen door mn favoriete, betere wachtwoord.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/8/oog3.png?f=community)
"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan
Nice
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat is ook wat er in dit topic wordt voorgesteld en we uiteindelijk ook wel willen gaan implementeren: op het moment dat uit een entropy-check blijkt dat een wachtwoord voldoet aan een bepaalde minimum-sterkte dan worden er verder geen inhoudelijke restricties meer opgelegd
Intentionally left blank
Beetje offtopic maar ook geen nieuw topic waard: ik ben wel nieuwsgierig hoeveel crewleden er precies zijn en hoeveel daarvan een notificatie hebben gekregen. Om dus te zien of mensen met een "waardevol" account ook echt een beter wachtwoord kiezen, of dat dit niet uitmaakt.
Verstuurd vanaf mijn Computer®
Dit topic is gesloten.