De Devschuur Coffee Corner - Iteratie 2

[ValHallASW]

.oisyn schreef op woensdag 06 juni 2012 @ 14:56:
Ik merk overigens dat een google search op de md5 van mijn oude standaard wachtwoord ook een hit geeft, inclusief de correcte invoer

Het is jammer dat je niet kunt googlen op een /deel/ van de hash: door op de volledige hash te zoeken wordt die effectief publiek...

Nouja, mooi moment om maar eens een eigen correct horse battery staple te bedenken ;-)

[BtM909]

Waarom zou je niet op een deel kunnen zoeken?

Daarnaast waarom wordt de data effectief publiek?

[StM]

En in hoeverre is het erg dat je hash bekend raakt? Zolang maar niet bekend is waar hij voor staat. En als je wachtwoord toch maar 8-9 tekens is, staat hij toch al in een rainbowtable.

[RayNbow]

BtM909 schreef op woensdag 06 juni 2012 @ 15:56:
Daarnaast waarom wordt de data effectief publiek?

Het wordt misschien niet echt publiek, maar je query komt wel in Google's querylog te staan.

[PrisonerOfPain]

Eerst WinRT door je strot proberen te duwen en nu die infantiele UI changes, beetje jammer dat ik zo van die IDE afhankelijk ben.

[ValHallASW]

BtM909 schreef op woensdag 06 juni 2012 @ 15:56:
Waarom zou je niet op een deel kunnen zoeken?

Omdat dat niet werkt.

Daarnaast waarom wordt de data effectief publiek?

Omdat google (in ieder geval deels) bekend maakt waar op gezocht wordt.

StM schreef op woensdag 06 juni 2012 @ 15:57:
En in hoeverre is het erg dat je hash bekend raakt? Zolang maar niet bekend is waar hij voor staat. En als je wachtwoord toch maar 8-9 tekens is, staat hij toch al in een rainbowtable.

Euh. Ja, goed punt. Ik zat in de gedachte dat het daarmee een interessanter target is, maar dat is natuurlijk onzin. Het zit 'm in de combinatie hash met andere informatie, niet de losse hash, en daar heb je dan geen last van.

[TJHeuvel]

RayNbow schreef op woensdag 06 juni 2012 @ 15:58:
[...]

Het wordt misschien niet echt publiek, maar je query komt wel in Google's querylog te staan.

1 rij in een pool van miljoenen/miljarden queries?

[Soultaker]

Je hebt een hash nodig om een brute-force aanval op te zetten, aangezien goede authenticatiesystemen ofwel expliciet rate-limited zijn (maximaal drie pogingen per minuut, bijvoorbeeld), ofwel impliciet (je kunt maximaal zoveel requests per seconde op een webserver doen). Dus is het vrijgeven van hashes wel degelijk problematisch als je password niet ontzettend sterk is.

Ik gebruik wel een aantal passwords die best binnen een paar dagen te kraken zouden zijn als je er een MD5 hash van hebt. Die maak ik dus mooi niet openbaar.

[.oisyn]

Hey Soultaker, doe jij eens reageren op mijn leetness. Anders sta ik voor niets te patsen

[GateKeaper]

Pfoei..... kneep 'm wel even toen ik las hoeveel wachtwoorden van onze collega tweakers in 'combo_not.txt' staan, maar die van mij staat er gelukkig niet tussen.

Binnenkort toch maar eens beginnen met het creëren van verschillende wachtwoorden per website. Heb 't nu ingedeeld naar persoonlijkheidsgraad. Registreren omdat noodzaak (torrentsite's, simpele forums, verplicht voor download) is simpel wachtwoord, iets persoonlijker, maar geen ramp (marktplaats, ebay) is moeilijk maar niet te, email, linkedin, paypal hebben mijn hoogste graad. Toch maar van af stappen dus... wordt me nu te heet onder de voeten.

[BtM909]

ValHallASW schreef op woensdag 06 juni 2012 @ 16:01:
[...]

Omdat dat niet werkt.

Wat werkt er niet? Als je een deel zoekt en je krijgt een hit, dan kan je toch kijken in het betreffende resultaat of je hele hash er staat

Omdat google (in ieder geval deels) bekend maakt waar op gezocht wordt.

Euh. Ja, goed punt. Ik zat in de gedachte dat het daarmee een interessanter target is, maar dat is natuurlijk onzin. Het zit 'm in de combinatie hash met andere informatie, niet de losse hash, en daar heb je dan geen last van.

Precies Even los van 't feit dat die ene zoekquery eigenlijk nergens verder publiek bekend wordt

[.oisyn]

BtM909 schreef op woensdag 06 juni 2012 @ 16:57:
[...]

Wat werkt er niet? Als je een deel zoekt en je krijgt een hit

Dát werkt er dus niet. Je kunt niet op een deel zoeken met Google, dan vindt ie niets. Hij zoekt alleen op hele woorden.

De MD5 van "password" is 5f4dcc3b5aa765d61d8327deb882cf99
[google=5f4dcc3b5aa765d61d8327deb882cf99]
[google=f4dcc3b5aa765d61d8327deb882cf9]

[ Voor 19% gewijzigd door .oisyn op 06-06-2012 17:00 ]

[RobIII]

GateKeaper schreef op woensdag 06 juni 2012 @ 16:55:
Pfoei..... kneep 'm wel even toen ik las hoeveel wachtwoorden van onze collega tweakers in 'combo_not.txt' staan, maar die van mij staat er gelukkig niet tussen.

Het is natuurlijk niet uitgesloten dat de "hackers" de overige ~155.000.000 wachtwoorden niet ook hebben

[GateKeaper]

RobIII schreef op woensdag 06 juni 2012 @ 17:03:
[...]

Het is natuurlijk niet uitgesloten dat de "hackers" de overige ~155.000.000 wachtwoorden niet ook hebben

Hey psst... doe es niet zo lullig?

Maar je hebt zeker een punt... vanavond mijn #1 pwd dan maar alvast overal gaan wijzigen. #2 't weekend maar even doen, en de rest komt gaande weg wel.

[BtM909]

.oisyn schreef op woensdag 06 juni 2012 @ 17:00:
[...]

Dát werkt er dus niet. Je kunt niet op een deel zoeken met Google, dan vindt ie niets. Hij zoekt alleen op hele woorden.

De MD5 van "password" is 5f4dcc3b5aa765d61d8327deb882cf99
[google=5f4dcc3b5aa765d61d8327deb882cf99]
[google=f4dcc3b5aa765d61d8327deb882cf9]

WTF

Ik had wildcard wel in m'n hoofd zitten, maar dat werkt dus alleen op hele woorden ... Kom ik nu pas achter.

[Rutix]

PrisonerOfPain schreef op woensdag 06 juni 2012 @ 16:00:
Eerst WinRT door je strot proberen te duwen en nu die infantiele UI changes, beetje jammer dat ik zo van die IDE afhankelijk ben.

Zo erg is de UI toch niet. En er komt vast weer een extension zoals bij VS2010 die je alles laat customizen .

[BtM909]

En toch krijg ik partial resultaten als ik de 5 weghaal, maar dat komt zeer waarschijnlijk omdat dit soort kreten erin staan

1.5f4dcc3b5aa765d61d8327deb882cf99
$1$5f4dcc3b5aa765d61d8327deb882cf99

En Google die terecht of onterecht die 5 "wegfiltert"

[ Voor 12% gewijzigd door BtM909 op 06-06-2012 17:11 ]

[Cloud]

RobIII schreef op woensdag 06 juni 2012 @ 17:03:
[...]

Het is natuurlijk niet uitgesloten dat de "hackers" de overige ~155.000.000 wachtwoorden niet ook hebben

Daarom heb ik ook meteen de mensen die ik ken met een LinkedIn account geadviseerd het wachtwoord z.s.m. te wijzigen; zelfs al staat je wachtwoord er niet in. Wachtwoord van mijn vrouw stond er gelukkig ook niet in.

[Soultaker]

.oisyn schreef op woensdag 06 juni 2012 @ 16:28:
Hey Soultaker, doe jij eens reageren op mijn leetness. Anders sta ik voor niets te patsen

Die had ik gemist! (Eigenlijk is dit ook niet het meest geschikte topic voor discussie van een flashgame. Ik zal de volgende keer een spielerij-topic openen ofzo.)

Erg mooie oplossing; ook lekker efficiënt: O(N×log N) in plaats van mijn O(N×2^N) aanpak. Die 2×3 buffers van jou zijn ook wel mooi; ik gebruikte daar altijd een 3×5 structuur voor (zoals in Robomecha bijvoorbeeld maar die zijn eigenlijk nogal lomp (hoewel ze de helft minder vergelijkingen doen; maar ja, wat koop je daarvoor).

[ Voor 22% gewijzigd door Soultaker op 06-06-2012 18:58 ]

[F.West98]

Gelukkig is mijn moeilijke pass sha1 en md5 niet bekend. Mijn gemakkelijke pass wel. Deze gebruik ik op dingen als mijn eigen kleine site enzo..
LinkedIn had ik toch al niet, dus dat is geen probleem. Wel ga ik eens een eigen lang pass bedenken. Op school vindt iedereen mijn moeilijke met 14 karakters al vreselijk lang maar dat is nog maar de medium. De makkelijke die dus bekend is is 12 karakters en de moeilijkste is 10 karakters.. Hmmm onveilig .
Maar moeilijk te raden en enkel bij ING en 3vCash.

[Sardaukar]

.Gertjan. schreef op woensdag 06 juni 2012 @ 09:43:
[...]

Ben wel benieuwd naar de horror verhalen Misschien dat de eerste TFS versies niet echt een succes waren, maar inmiddels is het wel een redelijk goed systeem hoor.

TFS is gewoon slecht in versiebeheer als je het vergelijkt met systemen als Mercurial of Git. Zeker Git maakt workflows mogelijk die je met TFS niet voor elkaar kan krijgen.

Een paar van mijn bevindingen:

• http://walkingthestack.bl...server-issues-rename.html
• http://walkingthestack.bl...dation-server-issues.html

(En dan laat ik er nog een hoop liggen waar ik geen zin had om een artikel over te schrijven).

[PrisonerOfPain]

Rutix schreef op woensdag 06 juni 2012 @ 17:10:
[...]

Zo erg is de UI toch niet. En er komt vast weer een extension zoals bij VS2010 die je alles laat customizen .

http://blogs.msdn.com/b/v...design-with-all-caps.aspx

[Verwijderd]

Het probleem is dat ik vaak zelfs al niet meer weet op welke sites ik allemaal een acount heb met hetzelfde wachtwoord .

[Alex)]

PrisonerOfPain schreef op woensdag 06 juni 2012 @ 22:50:
[...]


http://blogs.msdn.com/b/v...design-with-all-caps.aspx

"That said, we will enable you to customize the casing, and we are exploring options for how to expose that choice. "

'nuff said. Zo heel erg overtuigd van "the direction of other Microsoft user experiences" is het Visual Studio-team dus eigenlijk niet.

[Not Pingu]

Je leest nu overal: "Mijn wachtwoord staat er ook tussen (als ik de eerste 8 tekens van de hash weghaal)!"
De structuur van de eerste 8 tekens in de hashlist valt wel op Maar misschien is dat omdat de lijst alfabetisch gesorteerd is en dit slechts de 1e 6 miljoen uit de totale 161 miljoen zijn.
Maar omdat iedereen de eerste 8 tekens uit de hash van zijn eigen wachtwoord weghaalt, weet je toch totaal niet zeker dat het echt de hash van jouw pw is? Akkoord, 16^8~4,3 miljard en dat is binnen dit domein betrekkelijk weinig. Maar al vind je een hash die minus de eerste 8 tekens identiek is aan de jouwe, dan nog is de kans dat dat daadwerkelijk jouw wachtwoord is, kleiner dan de kans dat je de Staatsloterij wint.

Maar stel nou dat Linkedin iets doet met die eerste 8 tekens van de hash, ze vervangt door iets anders. Aan de ene kant verhoog je de kans op collisions (de hackende partij haalt bij een brute force attack de eerste 8 tekens van zijn hashes weg) en zul je dus pakweg 4,3 miljard collisions per hash vinden. Alleen zit het daadwerkelijke wachtwoord dan ergens in die set van 4,3 miljard. En zie die er maar eens uit te halen.

Of denk ik nou fout?

edit: je hebt dan wel aan 1 van die collisions genoeg om in te kunnen loggen op het desbetreffende account

[ Voor 4% gewijzigd door Not Pingu op 07-06-2012 00:21 ]

[.oisyn]

Not Pingu schreef op donderdag 07 juni 2012 @ 00:19:
Maar al vind je een hash die minus de eerste 8 tekens identiek is aan de jouwe, dan nog is de kans dat dat daadwerkelijk jouw wachtwoord is, kleiner dan de kans dat je de Staatsloterij wint.

O'rly? Je hebt 128 bits aan informatie over, dat zijn 2¹²⁸ =~ 3,4e38 mogelijkheden. Er zijn slechts 161 miljoen LinkedIn gebruikers. Met een perfect uniforme distributie liggen er dus gemiddeld ongeveer 3,4e38 / 161e6 = 2,1e30 ongebruikte 128 bits hashes tussen elke gebruikte hash. De kans dat de onderste 128 bits van de hash van jouw wachtwoord niet uniek is is dus astronomisch klein.

De kans dat je de Staatsloterij wint (gegarandeerde hoofdprijs, niet de jackpot) is ongeveer 1 op 5 miljoen.

Je moet je ook realiseren dat er in de praktijk lang niet zoveel wachtwoorden zijn als dat er 128 bits hashes zijn. Zelfs als we uitgaan van een volledige 7-bits ASCII charset, dan nog heb je 19 tekens nodig om die 128 bit space te vullen. En in de realiteit gebruikt men niet alle tekens, maar slechts letters, cijfers en nog een paar leestekens - zeg 75 verschillende karakters. Dan heb je minstens 21 tekens nodig, veel meer dan de gemiddelde wachtwoordlengte.

[ Voor 29% gewijzigd door .oisyn op 07-06-2012 01:44 ]

[Mikerd]

Toch nog een beetje de nacht doorbrengen met javascripten.. Kan het ook niet laten.

[Not Pingu]

.oisyn schreef op donderdag 07 juni 2012 @ 01:21:
De kans dat je de Staatsloterij wint (gegarandeerde hoofdprijs, niet de jackpot) is ongeveer 1 op 5 miljoen.

Je moet je ook realiseren dat er in de praktijk lang niet zoveel wachtwoorden zijn als dat er 128 bits hashes zijn. Zelfs als we uitgaan van een volledige 7-bits ASCII charset, dan nog heb je 19 tekens nodig om die 128 bit space te vullen. En in de realiteit gebruikt men niet alle tekens, maar slechts letters, cijfers en nog een paar leestekens - zeg 75 verschillende karakters. Dan heb je minstens 21 tekens nodig, veel meer dan de gemiddelde wachtwoordlengte.

En de kans dat het je wachtwoord is, is ca. 1 op de 4,3 miljard. Zoals ik al zei: binnen het domein is dat weinig, maar het betekent wel dat een brute force aanval 4,3 miljard-1 collisions produceert die NIET je wachtwoord zijn. Het zal erg lastig zijn voor een attacker om daaruit op te maken wat echt een wachtwoord is en wat niet.

[D-Raven]

Alex) schreef op woensdag 06 juni 2012 @ 23:33:
[...]


"That said, we will enable you to customize the casing, and we are exploring options for how to expose that choice. "

'nuff said. Zo heel erg overtuigd van "the direction of other Microsoft user experiences" is het Visual Studio-team dus eigenlijk niet.

Als ik t zo lees dan vind ik de redenen waarom ze het menu in hoofdletters weergeven maar vaag...

[Jan_V]

Sardaukar schreef op woensdag 06 juni 2012 @ 22:46:
[...]


TFS is gewoon slecht in versiebeheer als je het vergelijkt met systemen als Mercurial of Git. Zeker Git maakt workflows mogelijk die je met TFS niet voor elkaar kan krijgen.

Een paar van mijn bevindingen:

• http://walkingthestack.bl...server-issues-rename.html
• http://walkingthestack.bl...dation-server-issues.html

(En dan laat ik er nog een hoop liggen waar ik geen zin had om een artikel over te schrijven).

Dat het anders werkt als de DVCS'en van tegenwoordig hoeft natuurlijk niet per definitie slecht te zijn. Het is enkel gebaseerd op een 'oudere' (?) gedachte van versiebeheer.
Afgezien van het read-only maken van ingecheckte bestanden vind ik TFS prettiger werken dan SVN, CVS en VSS. (maar dat is persoonlijk natuurlijk)

Nadeel van de huidige DVCS'en is dat het volgens mij (nog) lastig is om ze binnen je organisatie te plaatsen. Zelf heb ik wel een server draaien met Mercurial er op, maar handig opzetten was het niet. Als organisatie kan ik me voorstellen dat je toch je code intern wilt hebben en niet zomaar op een publieke website plaatsen.

Ben wel benieuwd wat TFS2012 gaat brengen. Heb gelezen dat het read-only maken van bestanden dan uit kan worden gezet.
Overdag lekker de heerlijkheid van het TFS totaalpakket en 's avonds een lekker licht DVCS systeem dat gewoon goed is in versiebeheer.

[.oisyn]

Not Pingu schreef op donderdag 07 juni 2012 @ 07:53:
[...]


En de kans dat het je wachtwoord is, is ca. 1 op de 4,3 miljard.

Je hebt dus niets begrepen van mijn post. Je wiskunde klopt gewoon niet. Het aantal bits dat je weggooit is totaal niet van belang, het gaat om het aantal bits dat je overhoudt. De kans dat het niet je wachtwoord is is 1 op 2,1e30. Ergo, de kans dat het wel je wachtwoord is is 1 - 1/2,1e30 =~ 1.

En hoe kan de kans dat iets niet je wachtwoord is nou kleiner zijn dan 1 op het aantal wachtwoorden in de database

[ Voor 17% gewijzigd door .oisyn op 07-06-2012 09:12 ]

[Korben]

PrisonerOfPain schreef op woensdag 06 juni 2012 @ 22:50:
[...]
http://blogs.msdn.com/b/v...design-with-all-caps.aspx

Lol, comments op die post zijn vrij unaniem afkeuren van all-caps. Een medewerker van Microsoft vat de ironie mooi samen:

This is a post attempting to justify an all caps menu bar on a site which has a non-all caps menu bar.

[Rutix]

PrisonerOfPain schreef op woensdag 06 juni 2012 @ 22:50:
[...]


http://blogs.msdn.com/b/v...design-with-all-caps.aspx

Owjah die ALL CAPS ik heb dat uit staan dus ik heb daar geen last van. Ookal is die all caps lelijk zou ik nog steeds niet daarvoor naar een andere IDE switchen.

[Not Pingu]

.oisyn schreef op donderdag 07 juni 2012 @ 09:08:

En hoe kan de kans dat iets niet je wachtwoord is nou kleiner zijn dan 1 op het aantal wachtwoorden in de database

Dus volgens jou zijn er maar 6 miljoen globaal unieke wachtwoorden?

[OkkE]

Sinds welke versie van Photoshop is de "Selective JPG Compression" er eigenlijk uit?
Of: waar vind ik die in CS5 op de Mac?


Kleine icoontje naast Quality.

[ Voor 10% gewijzigd door OkkE op 07-06-2012 09:21 ]

[.oisyn]

Not Pingu schreef op donderdag 07 juni 2012 @ 09:18:
[...]


Dus volgens jou zijn er maar 6 miljoen globaal unieke wachtwoorden?

Volgens mij zijn er maximaal 161 miljoen unieke wachtwoorden in de LinkedIn database. De kans dat er een ander wachtwoord in staat die dezelfde onderste 128 bits als jouw wachtwoord heeft is astronomisch klein zoals ik liet zien in mijn berekening in mijn voorlaatste post. Jij beweert effectief dat SHA-1 waarvan je de bovenste 32 bits weggooit feitelijk veel en veel meer collisions heeft dan MD5, ookal is het resultaat van beide hashes 128 bits. Dat zou alleen het geval zijn als die bovenste bits meer significantie hebben, maar dat is voor het geval van goede cryptographic hash functions zoals SHA-1 en MD5 absoluut niet het geval.

[ Voor 54% gewijzigd door .oisyn op 07-06-2012 09:28 ]

[Korben]

Not Pingu schreef op donderdag 07 juni 2012 @ 09:18:
[...]
Dus volgens jou zijn er maar 6 miljoen globaal unieke wachtwoorden?

Er zijn globaal eindeloos veel unieke wachtwoorden en, afhankelijk van het gebruikte hash-algoritme, tussen de 2 ^ 128 en 2 ^ 512 globaal unieke wachtwoordhashes (als we MD5, SHA-1, SHA-2 als gebruikte hash-algo's beschouwen). Simple as that.

[ Voor 8% gewijzigd door Korben op 07-06-2012 09:25 ]

[YopY]

Krijg een boos mailtje van m'n collega om 1 uur 's nachts dat hij eindelijk een mislukkende test gevonden heeft. Quote hij even mijn commentaar:

code:

// note: test probably breaks if you execute it between midnight and 8.30. 
// What are you doing working at a time like this?

[Not Pingu]

.oisyn schreef op donderdag 07 juni 2012 @ 09:22:
[...]


Volgens mij zijn er maximaal 161 miljoen unieke wachtwoorden in de LinkedIn database.

Maar je zoekt niet naar wachtwoorden uit de set L van Linkedin wachtwoorden, je zoekt wachtwoorden uit de set G van globaal mogelijke wachtwoorden.
Als Pietje en Jantje hun wachtwoord gaan hashen en een string zoeken in dat Linkedin bestand waarvan de laatste 24 chars overeenkomen, is de kans dat ze een match vinden 2³² maal groter dat ze een match vinden dan wanneer ze op de hele 32-char word zoeken (die zeer waarschijnlijk geen match vindt).

8 chars = 32 bits. 2³² = 4.294.967.296, dat is het aantal hashes waarvan de laatste 24 chars/128 bits overeenkomen met de 24 chars van het wachtwoord van Pietje.


Overigens zou het me niks verbazen dat die 6 miljoen alle unieke wachtwoorden zijn. Als je ziet dat de Grote 3 uit de jaren '90 (sex, god en secret) alledrie matchen dan is het vrij waarschijnlijk dat Linkedin gebruikers gewoon niet zo origineel zijn met wachtwoorden.

[.oisyn]

Korben schreef op donderdag 07 juni 2012 @ 09:24:
[...]

Er zijn globaal eindeloos veel unieke wachtwoorden

In theorie. In de praktijk echter gebruikt men maar een gelimiteerd aantal karakters met een gelimiteerd aantal mogelijkheden - over het algemeen louter letters en cijfers. Met 10 tekens lang, wat gemiddeld gezien volgens mij best een lang wachtwoord is, krijg je slechts 8e17 combinaties. Het aantal mensen dat langere wachtwoorden en/of leestekens gebruikt is volgens mij verwaarloosbaar. Nogmaals, om de volledige 128 bit hash space te vullen moet je wachtwoorden gebruiken van 19 tekens van de volledige ASCII set, of 22 alphanumerieke tekens. Vrijwel niemand doet dat. De kans dat er een collision is bij 8e17 combinaties en een 128 bits hash space is 1 - (2¹²⁸! / ((2¹²⁸ - 8e17)! * (2¹²⁸)^8e17)). Benadering doe ik wel in een volgende post.

@Not Pingu:
Nogmaals: Jij beweert effectief dat SHA-1 waarvan je de bovenste 32 bits weggooit feitelijk veel en veel meer collisions heeft dan MD5, ookal is het resultaat van beide hashes 128 bits. Dat zou alleen het geval zijn als die bovenste bits meer significantie hebben, maar dat is voor het geval van goede cryptographic hash functions zoals SHA-1 en MD5 absoluut niet het geval.

De bits die je weggooit zijn compleet niet relevant voor de kansberekening. Volgens jouw logica is de kans dat iets je wachtwoord is slechts 1 op 2 als je 1 bit weggooit, of je nou een 16 of 1024 bits hash algoritme gebruikt.

Als Pietje en Jantje hun wachtwoord gaan hashen en een string zoeken in dat Linkedin bestand waarvan de laatste 24 chars overeenkomen, is de kans dat ze een match vinden 2³² maal groter dat ze een match vinden dan wanneer ze op de hele 32-char word zoeken (die zeer waarschijnlijk geen match vindt).

Dat klopt. Maar het feit dat die kans 2³² maal groter is betekent niet dat de kans ook 1 op 2³² is, want dat impliceert dat de kans op de volledige 32-char words 1 op 2⁶⁴ is. De kans bij 16 chars is ook 2³² maal groter dan bij 24 chars. Als jij stelt dat ook daar de kans 1 op 2³² is, dan is dat bij 24 chars ook 2⁶⁴. Maar wacht even, de kans bij 24 chars was toch al 1 op 2³²? Hoe kan het nou tegelijk 1 op 2⁶⁴ als 1 op 2³² zijn?

[ Voor 57% gewijzigd door .oisyn op 07-06-2012 10:10 ]

[Hydra]

D-Raven schreef op woensdag 06 juni 2012 @ 09:37:
Heb zelf nooit TFS gebruikt, maar de horror verhalen die ik op het internet lees doen me sterk terugdenken aan een microsoft versie beheer systeem wat ook zo 'goed' werkte....

SourceSafe! Ah, die goeie ouwe tijd van exclusive locks op belangrijke zooi van mensen die 3 weken op vakantie waren. VSS was DE reden dat we allemaal elkaars passwords wisten

Nostalgie!

[Not Pingu]

.oisyn schreef op donderdag 07 juni 2012 @ 09:34:

Dat klopt. Maar het feit dat die kans 2³² maal groter is betekent niet dat de kans ook 1 op 2³² is, want dat impliceert dat de kans op de volledige 32-char words 1 op 2⁶⁴ is. De kans bij 16 chars is ook 2³² maal groter dan bij 24 chars. Als jij stelt dat ook daar de kans 1 op 2³² is, dan is dat bij 24 chars ook 2⁶⁴. Maar wacht even, de kans bij 24 chars was toch al 1 op 2³²? Hoe kan het nou tegelijk 1 op 2⁶⁴ als 1 op 2³² zijn?

Ik redeneer vanuit de gedachte dat er 2³² hashes zitten in de subset van hashes die eindigen op de laatste 24 chars van hash H₃₂. Dus bij een match M_{8 t/m 32} op H_{8 t/m 24} is de kans dat de input van M₃₂ hetzelfde is als de input van H₃₂ 1 op 2³².

[.oisyn]

Tja, als je gewoon structureel niet leest wat ik zeg dan houdt deze discussie natuurlijk op

[azerty]

Straks examen statistiek, inclusief kansberekening... Ik volg .oisyn's redenering*


* graag verwijs ik naar onderstaande disclaimer in het geval ik mis zou zijn

[ Voor 5% gewijzigd door azerty op 07-06-2012 10:36 ]

[Alex)]

Hydra schreef op donderdag 07 juni 2012 @ 10:02:
[...]


SourceSafe! Ah, die goeie ouwe tijd van exclusive locks op belangrijke zooi van mensen die 3 weken op vakantie waren. VSS was DE reden dat we allemaal elkaars passwords wisten

Nostalgie!

Dat kan met TFS ook nog steeds hoor.

[Otherside1982]

Alex) schreef op donderdag 07 juni 2012 @ 10:31:
[...]

Dat kan met TFS ook nog steeds hoor.

Exclusive checkouts kunnen ook met SVN hoor. Uiteraard niet standaard, maar het kan wel nuttig zijn als je binaire bestanden hebt die niet gemerged kunnen worden.

[.oisyn]

.oisyn schreef op donderdag 07 juni 2012 @ 09:34:
De kans dat er een collision is bij 8e17 combinaties en een 128 bits hash space is 1 - (2¹²⁸! / ((2¹²⁸ - 8e17)! * (2¹²⁸)^8e17)). Benadering doe ik wel in een volgende post.

Ik reken voor het gemak maar even louter met machten van e
ln(2¹²⁸) =~ 88
ln(8e17) =~ 41

ln(n!) =~ n * ln(n) - n + .5*ln(2pi*n)

1 - (2¹²⁸! / ((2¹²⁸ - 8e17)! * (2¹²⁸)^8e17)) =>
1 - (e^3e40 / (e^3e40 * e^88*8e17)) =>
1 - (e^3e40 / (e^3e40 * e^7e19)) =>
1 - (e^3e40 / e^3e40) =>
1 - 1 =>
0

[ Voor 5% gewijzigd door .oisyn op 07-06-2012 10:40 ]

[Korben]

.oisyn schreef op donderdag 07 juni 2012 @ 09:34:
[...]
Het aantal mensen dat langere wachtwoorden en/of leestekens gebruikt is volgens mij verwaarloosbaar. Nogmaals, om de volledige 128 bit hash space te vullen moet je wachtwoorden gebruiken van 19 tekens van de volledige ASCII set, of 22 alphanumerieke tekens. Vrijwel niemand doet dat. De kans dat er een collision is bij 8e17 combinaties en een 128 bits hash space is 1 - (2¹²⁸! / ((2¹²⁸ - 8e17)! * (2¹²⁸)^8e17)). Benadering doe ik wel in een volgende post.

Gelukkig doe ik daar zelf wel aan. Met uitzondering van een aantal sites die belachelijke beperkingen leggen op wachtwoordlengte (waaronder Microsoft Live ) heb ik wachtwoorden van tussen de 16 en 30 tekens, met vaak alfanumerieke tekens en leestekens, wat me bij 30 tekens een wachtwoordsterkte geeft equivalent aan ruwweg 186 bits -- 73³⁰ = 7e55, 2¹⁸⁶ = 9e55.

[creator1988]

Ook hier een gelekt password, wat dus mooi kut met peren is. Gisteren persoonlijk eindelijk LastPass gaan gebruiken en voor belangrijke accounts random passwords gegenereerd. Tevens voor onze customer database alle wachtwoorden nu gehasht met pbkdf2 en 10.000 iterations, ipv sha1.

[azerty]

creator1988 schreef op donderdag 07 juni 2012 @ 10:35:
Ook hier een gelekt password, wat dus mooi kut met peren is. Gisteren persoonlijk eindelijk LastPass gaan gebruiken en voor belangrijke accounts random passwords gegenereerd. Tevens voor onze customer database alle wachtwoorden nu gehasht met pbkdf2 en 10.000 iterations, ipv sha1.

En hoe heb jij een gehashte versie van een wachtwoord opnieuw gehasht met een ander algoritme als ik dat vragen mag?

[Cloud]

wsitedesign schreef op donderdag 07 juni 2012 @ 10:37:
[...]

En hoe heb jij een gehashte versie van een wachtwoord opnieuw gehasht met een ander algoritme als ik dat vragen mag?

Als ik niet beter zou weten zou ik zeggen dat hij de hashes gehasht heeft. Wel vind ik het gek dat hij zegt 'ipv SHA1' wat inderdaad impliceert dat hij het ongehashte wachtwoord óók heeft.

[Korben]

creator1988 schreef op donderdag 07 juni 2012 @ 10:35:
Ook hier een gelekt password, wat dus mooi kut met peren is. Gisteren persoonlijk eindelijk LastPass gaan gebruiken en voor belangrijke accounts random passwords gegenereerd. Tevens voor onze customer database alle wachtwoorden nu gehasht met pbkdf2 en 10.000 iterations, ipv sha1.

Whut? PBKDF2 is geen hashfunctie, het is, zoals de naam al zegt, een key derivation function. Die hoor je niet te gebruiken voor wachtwoord-hashing.

[creator1988]

wsitedesign schreef op donderdag 07 juni 2012 @ 10:37:
[...]


En hoe heb jij een gehashte versie van een wachtwoord opnieuw gehasht met een ander algoritme als ik dat vragen mag?

Oude situatie, 2 velden: password | salt
Nieuwe situatie: 3 velden: password | salt | doSha1First

Migratie: hash alle passwords opnieuw, en zet doSha1First op true

Als iemand inlogt met dat veld op 'true', doe pbkdf2(sha1(pass, salt)), als dat matcht, dan vervang je password door pbkdf2(pass, salt) en zet het veld op false.

[creator1988]

Korben schreef op donderdag 07 juni 2012 @ 10:39:
[...]

Whut? PBKDF2 is geen hashfunctie, het is, zoals de naam al zegt, een key derivation function. Die hoor je niet te gebruiken voor wachtwoord-hashing.

Tweakers.net lijkt het niet met je eens te zijn plan: Development-round-up - iteratie #4, evenals StackExchange: http://blog.stackoverflow...d-provider/#comment-59112

En de NIST heeft het geapproved voor het hashen en storen van wachtwoorden http://csrc.nist.gov/publ...00-132/nist-sp800-132.pdf

NIST has issued Special Publication SP 800-132 on the subject of storing hashed passwords. Basically they recommend PBKDF2. This does not mean that they deem bcrypt insecure; they say nothing at all about bcrypt. It just means that NIST deems PBKDF2 "secure enough" (and it certainly is much better than a simple hash !). Also, NIST is an administrative organization, so they are bound to just love anything which builds on already "Approved" algorithms like SHA-256. On the other hand, bcrypt comes from Blowfish which has never received any kind of NIST blessing (or curse).

[ Voor 36% gewijzigd door creator1988 op 07-06-2012 10:47 ]

[Cloud]

creator1988 schreef op donderdag 07 juni 2012 @ 10:39:
[...]

Dat is inderdaad de correcte manier voor een wachtwoordhash migratie

Korben schreef op donderdag 07 juni 2012 @ 10:39:
[...]

Whut? PBKDF2 is geen hashfunctie, het is, zoals de naam al zegt, een key derivation function. Die hoor je niet te gebruiken voor wachtwoord-hashing.

Waarom zou dat niet zo horen? In het geval van een lek met hashed passwords maakt het de wachtwoordhashes vrijwel onmogelijk te brute forcen. Het enige belangrijke is de daadwerkelijke hash functie die pbkdf2 gebruikt lijkt me.

[jip_86]

Alex) schreef op woensdag 06 juni 2012 @ 23:33:
[...]


"That said, we will enable you to customize the casing, and we are exploring options for how to expose that choice. "

'nuff said. Zo heel erg overtuigd van "the direction of other Microsoft user experiences" is het Visual Studio-team dus eigenlijk niet.

Rare redenatie ook om een website aan te halen als voorbeeld waar het wel werkt. Als je kijkt naar bijvoorbeeld het Azure voorbeeld vind ik het daar opzich wel geslaagd. Maar daar is het een website zonder rijen icoontjes en een windodws taakbalk er om heen.

Aan de andere kant als ik het lowercase voorbeeld bekijk vind ik dat toch gevoelsmatig ook niet helemaal kloppen. Op de een of andere manier is er iets veranderd waardoor beide niet lekker lopen. Volgens mij is het onderscheid tussen de menubalken weg.

Het is wellicht vloeken in de kerk maar volgens mij is voor VS een goed uitgewerkte ribbon een betere toevoeging dan dit soort geneuzel als grijze kleurtjes en de casing van menus. Als je de belangrijkste acties voor het type bestand waar je in bezig bent bij de hand hebt lijkt me dat wel werken.

[azerty]

creator1988 schreef op donderdag 07 juni 2012 @ 10:39:
[...]

Oude situatie, 2 velden: password | salt
Nieuwe situatie: 3 velden: password | salt | doSha1First

Migratie: hash alle passwords opnieuw, en zet doSha1First op true

Als iemand inlogt met dat veld op 'true', doe pbkdf2(sha1(pass, salt)), als dat matcht, dan vervang je password door pbkdf2(pass, salt) en zet het veld op false.

Dat was ongeveer ik al verwacht had en ging het ook gelijkaardig doen deze zomer bij een migratie

Van mij zal het ook hoog tijd worden om het over te zetten, er zit zelfs geen hash op op dit moment *gaat zich in een hoekje gaan verstoppen*

[Korben]

creator1988 schreef op donderdag 07 juni 2012 @ 10:45:
[...]

Tweakers.net lijkt het niet met je eens te zijn plan: Development-round-up - iteratie #4, evenals StackExchange: http://blog.stackoverflow...d-provider/#comment-59112

Nee, Tweakers.net zegt dit over PBKDF2:

als standaard is voorgesteld voor diverse toepassingen waarbij een afgeleide sleutel van een wachtwoord langdurig opgeslagen moet worden.

Dat is iets anders dan simpelweg hashen van een wachtwoord. Stack Exchange zegt dat ze PBKDF2 gebruiken als hashing-algoritme, maar wie zegt dat zij het resultaat ook niet gebruiken om data mee te versleutelen?

En de NIST heeft het geapproved voor het hashen en storen van wachtwoorden http://csrc.nist.gov/publ...00-132/nist-sp800-132.pdf
[...]

Er staat volgens mij (wijs maar aan als dat niet zo is) alleen maar dat PBKDF2 is goedgekeurd als KDF-algoritme, niet als hashing-algoritme.

Cloud schreef op donderdag 07 juni 2012 @ 10:48:
[...]
Waarom zou dat niet zo horen? In het geval van een lek met hashed passwords maakt het de wachtwoordhashes vrijwel onmogelijk te brute forcen. Het enige belangrijke is de daadwerkelijke hash functie die pbkdf2 gebruikt lijkt me.

Een fatsoenlijk hash-algoritme is ook zo goed als onmogelijk te brute-forcen. PBKDF2 is ruwweg even makkelijk te brute-forcen als SHA2, omdat het makkelijk te implementeren is als hardware-oplossing.

[ValHallASW]

creator1988 schreef op donderdag 07 juni 2012 @ 10:39:
Oude situatie, 2 velden: password | salt
Nieuwe situatie: 3 velden: password | salt | doSha1First

Waarom niet gewoon een kolom 'algoritme' toevoegen? Dan heb je het meteen voor eventuele toekomstige wijzigingen ook netjes opgelost (hoewel het dan waarschijnlijk meer zal gaan om het aantal iteraties ipv een ander algoritme).

Zie bv. https://docs.djangoprojec...w-django-stores-passwords

[ Voor 9% gewijzigd door ValHallASW op 07-06-2012 11:07 ]

[jip_86]

Weet je dan niet gelijk welke manier je moet gebruiken om te brute-forcen?

[.oisyn]

Korben schreef op donderdag 07 juni 2012 @ 10:39:
[...]

Whut? PBKDF2 is geen hashfunctie, het is, zoals de naam al zegt, een key derivation function. Die hoor je niet te gebruiken voor wachtwoord-hashing.

Wikipedia spreekt je tegen:

Key derivation functions are also used in applications to derive keys from secret passwords or passphrases, which typically do not have the desired properties to be used directly as cryptographic keys

Daarnaast is dat hele argument natuurlijk bogus. Niet iets mogen gebruiken puur omdat het er niet voor bedoeld is is een non-argument, het gaat erom of het geschikt is. En dat het geschikt is lijkt me vrij logisch, als je aan de hand van een key makkelijk het wachtwoord kunt achterhalen dan is het ook niet meer geschikt als key derivation function.

[ Voor 23% gewijzigd door .oisyn op 07-06-2012 11:14 ]

[alienfruit]

Lekker is dat heb ik een SSL certificaat gekocht krijg ik nog steeds een waarschuwing op mijn telefoons dat de certificaat onbetrouwbaar is

[azerty]

Root CA die mist op je telefoon?

[.oisyn]

Nou dan had je net zo goed een gratis certificaat van StartSSL kunnen regelen . Wat is de authority van jouw cert?

[Korben]

.oisyn schreef op donderdag 07 juni 2012 @ 11:09:
[...]
Wikipedia spreekt je tegen:

[...]

Daarnaast is dat hele argument natuurlijk bogus. Niet iets mogen gebruiken puur omdat het er niet voor bedoeld is is een non-argument, het gaat erom of het geschikt is. En dat het geschikt is lijkt me vrij logisch, als je aan de hand van een key makkelijk het wachtwoord kunt achterhalen dan is het ook niet meer geschikt als key derivation function.

Je spreekt jezelf tegen. Een hash produceren van een wachtwoord is niet hetzelfde als het produceren van een 'veilige' symmetrische key en IV op basis van een wachtwoord. Als dat hetzelfde was, waarom dat niet gewoon 10.000 keer SHA-2 uitvoeren op een wachtwoord en aan de hand van die bytes een symmetrische key en IV genereren? Omdat SHA-2 een vaste outputgrootte heeft, wat PBKDF2 niet heeft.

Jouw argument over dat je iets niet moet gebruiken voor iets waar het niet voor bedoeld is net zo goed bogus; je gebruikt toch ook geen schroevendraaier om een spijker in een muur te slaan? Sure, het is er wel voor geschikt, maar het beste resultaat bereik je met een hamer.

[.oisyn]

Korben schreef op donderdag 07 juni 2012 @ 11:27:
Je spreekt jezelf tegen.

Waar precies? Ik heb volgens mij geen tegenstrijdige dingen gezegd.

Een hash produceren van een wachtwoord is niet hetzelfde als het produceren van een 'veilige' symmetrische key en IV op basis van een wachtwoord.

Heb ik ook niet beweerd. Een veilige symmetrische key heeft bijvoorbeeld wat strengere eisen dan een wachtwoord hash. Maar dat maakt het niet ineens ongeschikt voor het hashen van wachtwoorden. Als jij vindt dat je het er niet voor hoort te gebruiken, dan hoor ik graag argumenten waarom het volgens jou ongeschikt is, in plaats van "het is anders" of "het is er niet voor bedoeld".

waarom dat niet gewoon 10.000 keer SHA-2 uitvoeren op een wachtwoord en aan de hand van die bytes een symmetrische key en IV genereren? Omdat SHA-2 een vaste outputgrootte heeft, wat PBKDF2 niet heeft.

Gefeleciteerd, je hebt zojuist uitgelegd waarom het recursief hashen van een wachtwoord met SHA-2 niet geschikt is voor het genereren van een key. Maar dat was de discussie geloof ik niet, de discussie was of PBKDF2 geschikt was om een ww hash mee te genereren.

Jouw argument over dat je iets niet moet gebruiken voor iets waar het niet voor bedoeld is net zo goed bogus; je gebruikt toch ook geen schroevendraaier om een spijker in een muur te slaan? Sure, het is er wel voor geschikt

Nee, dat is het niet. Het houdt moeilijk vast, heeft weinig massa, en geen platte kop om mee te slaan.
Daarnaast zou je volgens jouw logica duct tape nergens voor mogen gebruiken behalve voor air ducts. En zo zijn er miljoenen voorbeelden van uitvindingen in de geschiedenis van de mensheid die heel geschikt blijken voor iets anders dan ze voor bedoeld zijn. Als we dingen alleen maar bleven gebruiken voor waarvoor ze bedoeld waren dan zaten we nog in het stenentijdperk

[ Voor 60% gewijzigd door .oisyn op 07-06-2012 11:45 ]

[Sardaukar]

Jan_V schreef op donderdag 07 juni 2012 @ 09:07:
[...]
Nadeel van de huidige DVCS'en is dat het volgens mij (nog) lastig is om ze binnen je organisatie te plaatsen. Zelf heb ik wel een server draaien met Mercurial er op, maar handig opzetten was het niet. Als organisatie kan ik me voorstellen dat je toch je code intern wilt hebben en niet zomaar op een publieke website plaatsen.

Er zijn genoeg mogelijkheden om een DVCS server intern in je organisatie te plaatsen. Zowel Github als Atlassian bieden hiervoor complete systemen aan.

Wat let je bovendien om je repo's op een interne server te zetten en zelf je access control te regelen? Ook zo gedaan.

[Caelorum]

creator1988 schreef op donderdag 07 juni 2012 @ 10:35:
Ook hier een gelekt password, wat dus mooi kut met peren is. Gisteren persoonlijk eindelijk LastPass gaan gebruiken [...]

Ah. Gewoon uit nieuwsgierigheid: Wat is eigenlijk echt het verschil tussen Lastpass en Keepass?

[.oisyn]

4 letters?

[alienfruit]

Ja, het is een RapidSSL certificate... Blijkbaar mist mijn Samsung telefoon inderdaad de root certificaat...

[.oisyn]

Dan kan ik die ook van het lijstje strepen mocht ik ooit een betaald cert aanschaffen. Ben benieuwd hoe PositiveSSL van Comodo het doet, die kost een tientje.

[alienfruit]

Ik denk dat ik gewoon zo'n verrekte dure GeoTrust had moet kopen

[Cloud]

Caelorum schreef op donderdag 07 juni 2012 @ 11:44:
[...]

Ah. Gewoon uit nieuwsgierigheid: Wat is eigenlijk echt het verschil tussen Lastpass en Keepass?

LastPass slaat alles online op, dus je moet wat meer vertrouwen hebben in hun. Daarnaast is de software van LastPass closed source (vziw) en Keepass open source. Ik maak zelf gebruik van Keepass i.c.m. Dropbox. Verder zijn er niet echt grote verschillen dacht ik; ze zijn beide prima.

Sinds ik overstapt ben op Keepass heb ik nu vrijwel overal verschillende wachtwoorden en van een redelijk aantal sites weet ik het wachtwoord niet eens (nooit gezien ook). Alleen van sites waar ik heel vaak opnieuw inlog ken ik het wachtwoord nog.

[azerty]

.oisyn schreef op donderdag 07 juni 2012 @ 11:46:
Dan kan ik die ook van het lijstje strepen mocht ik ooit een betaald cert aanschaffen. Ben benieuwd hoe PositiveSSL van Comodo het doet, die kost een tientje.

Surf eens naar de beveiligde versie van mijn site en je zult het weten

[Korben]

.oisyn schreef op donderdag 07 juni 2012 @ 11:46:
Dan kan ik die ook van het lijstje strepen mocht ik ooit een betaald cert aanschaffen. Ben benieuwd hoe PositiveSSL van Comodo het doet, die kost een tientje.

PositiveSSL gebruikt het USERTRUST certificaat als root-certificaat, volgens mij hebben veel telefoons dat wel gewoon.

[Phoenix1337]

Korben schreef op donderdag 07 juni 2012 @ 11:54:
[...]

PositiveSSL gebruikt het USERTRUST certificaat als root-certificaat, volgens mij hebben veel telefoons dat wel gewoon.

Wij gebruiken een MobileSSL certificaat van comodo en die wordt ook met The USERTRUST Network gesigned en werkt op mijn desire

[.oisyn]

wsitedesign schreef op donderdag 07 juni 2012 @ 11:51:
[...]


Surf eens naar de beveiligde versie van mijn site en je zult het weten

Doet het prima op mijn (Samsung) WP7 telefoon.

[azerty]

.oisyn schreef op donderdag 07 juni 2012 @ 11:57:
[...]


Doet het prima op mijn (Samsung) WP7 telefoon.

Dan is dat bij deze ook weer proefondervindelijk bewezen

Ter algemene info:

[alienfruit]

Op je site krijg inderdaad geen waarschuwing voor jouw domein alleen eentje voor Google Analytics

[Rutix]

wsitedesign schreef op donderdag 07 juni 2012 @ 11:51:
[...]


Surf eens naar de beveiligde versie van mijn site en je zult het weten

jou homepage voldoet nog niet aan de cookies wetgeving :P!

[Phoenix1337]

Rutix schreef op donderdag 07 juni 2012 @ 11:59:
[...]

jou homepage voldoet nog niet aan de cookies wetgeving :P!

Zolang de website van de opta zelf ook nog niet voldoet ga ik me er ook niet druk om maken.

[azerty]

alienfruit schreef op donderdag 07 juni 2012 @ 11:59:
Op je site krijg inderdaad geen waarschuwing voor jouw domein alleen eentje voor Google Analytics

Rutix schreef op donderdag 07 juni 2012 @ 11:59:
[...]

jou homepage voldoet nog niet aan de cookies wetgeving :P!

Tjah, dan moet ik hem maar aanpassen voor Nederlandse en Britse bezoekers zeker? België heeft die wetgeving (nog) niet.

En Google heb ik er ooit eens opgezet, maar was dat terug vergeten. Vliegt er bij de volgende update uit.
Vliegt er binnen een paar minuten uit.
is nu weg

[ Voor 5% gewijzigd door azerty op 07-06-2012 12:07 ]

[.Gertjan.]

Grrrr. Aan het stoeien met events in ASP.NET
Knopje in een repeater gehangen met daarbij een handler voor de OnCommand. Weigert .net het event op te pakken

Als ik een knop buiten de repeater zet met dezelfde code werkt het wel. Nog mooier is dat nadat ik op de knop buiten de repeater heb geklikt en daarna eentje binnen de repeater gebruik de knoppen binnen de repeater wel werken. Maar druk ik die knop buiten de repeater niet in dan blijven de knoppen in de repeater werken Op diverse plekker gebruik ik dezelfde constructie en werk het wel, maar hier werkt het ineens niet

Kunnen we weer lekker gaan uitzoeken wat er mis gaat Bagger....

[Alex)]

Dat klinkt als een probleempje met de ASP.NET Page Lifecycle. Wanneer je te vroeg of te laat controls toevoegt of databind krijg je dit geneuzel. Het databinden doe ik eigenlijk altijd in de OnPreRender.

Tevens gebruik ik geen Repeater meer, maar een ListView.

[.oisyn]

.oisyn schreef op donderdag 07 juni 2012 @ 10:34:
[...]


Ik reken voor het gemak maar even louter met machten van e
ln(2¹²⁸) =~ 88
ln(8e17) =~ 41

ln(n!) =~ n * ln(n) - n + .5*ln(2pi*n)

1 - (2¹²⁸! / ((2¹²⁸ - 8e17)! * (2¹²⁸)^8e17)) =>
1 - (e^3e40 / (e^3e40 * e^88*8e17)) =>
1 - (e^3e40 / (e^3e40 * e^7e19)) =>
1 - (e^3e40 / e^3e40) =>
1 - 1 =>
0

Dit ging natuurlijk nergens over. De originele vergelijking is wel goed, maar de nummers zijn zo groot waardoor alles tegen elkaar wegvalt. Dit is een betere benadering:

p(k,n) =~ 1-e^{-n^2/(2k)}
p(2¹²⁸, 8e17) =~ 0.00094

Dus bij 8e17 wachtwoorden heb je net iets minder dan een tiende procent kans op een collision. Bij de 161 miljoen wachtwoorden in de LinkedIn database is de kans op een collision p(2¹²⁸, 161e6) =~ 1 - e^-3e-23 =~ 0.

Ergo, de kans dat bij match van de onderste 128 bits het wachtwoord van jou is, is zo goed als 1. En dus niet 1 op 4,3 miljard zoals Not Pingu beweerde.

[ Voor 17% gewijzigd door .oisyn op 07-06-2012 12:58 ]

[Verwijderd]

.oisyn schreef op donderdag 07 juni 2012 @ 12:45:
[...]


Dit gaat natuurlijk nergens over. De originele vergelijking is wel goed, maar de nummers zijn zo groot waardoor alles tegen elkaar wegvalt. Dit is een betere benadering:

p(k,n) =~ 1-e^{-n^2/(2k)}
p(2¹²⁸, 8e17) =~ 0.00094

Dus bij 8e17 wachtwoorden heb je net iets minder dan een tiende procent kans op een collision.

Word ik gek, of ben je nu met je eigen aan het discuteren

[.oisyn]

Ik ben mezelf aan het verbeteren

Ik heb "gaat" maar vervangen door "ging", anders lijkt het idd net alsof ik iemand anders quote

[ Voor 61% gewijzigd door .oisyn op 07-06-2012 12:54 ]

[Verwijderd]

ha ok Ik dacht bijna de mannen met de witte jassen te bellen...

[Alex)]

Group Conversation
1 participant

Wait, whut?

[ Voor 4% gewijzigd door Alex) op 07-06-2012 13:02 ]

[OkkE]

Instant Bugfix nodig? Alstublieft: http://instantbugfix.com/

[TJHeuvel]

De source is ook leuk gecomment

[RobIII]

Cloud schreef op donderdag 07 juni 2012 @ 11:50:
LastPass slaat alles online op, dus je moet wat meer vertrouwen hebben in hun.

Waarbij de nuance wel ligt in 't feit dat je LastPass' systemen niet anders gebruikt dan een Dropbox; het "lastpass bestand" wordt namelijk altijd client-side encrypted; "ze" kunnen bij LastPass dus ook niets met je bestand.

[D-Raven]

.Gertjan. schreef op donderdag 07 juni 2012 @ 12:10:
Grrrr. Aan het stoeien met events in ASP.NET
Knopje in een repeater gehangen met daarbij een handler voor de OnCommand. Weigert .net het event op te pakken

Als ik een knop buiten de repeater zet met dezelfde code werkt het wel. Nog mooier is dat nadat ik op de knop buiten de repeater heb geklikt en daarna eentje binnen de repeater gebruik de knoppen binnen de repeater wel werken. Maar druk ik die knop buiten de repeater niet in dan blijven de knoppen in de repeater werken Op diverse plekker gebruik ik dezelfde constructie en werk het wel, maar hier werkt het ineens niet

Kunnen we weer lekker gaan uitzoeken wat er mis gaat Bagger....

Stel je wel CommandName e.d. op de knop in ?

[Korben]

Verwijderd schreef op donderdag 07 juni 2012 @ 12:55:
ha ok Ik dacht bijna de mannen met de witte jassen te bellen...

[Cloud]

RobIII schreef op donderdag 07 juni 2012 @ 13:12:
[...]

Waarbij de nuance wel ligt in 't feit dat je LastPass' systemen niet anders gebruikt dan een Dropbox; het "lastpass bestand" wordt namelijk altijd client-side encrypted; "ze" kunnen bij LastPass dus ook niets met je bestand.

Dat wist ik niet, maar hoopte ik wel inderdaad. Had wel zoiets verwacht, anders waren ze denk ik nooit zo groot geworden. Ik wil ook niet zeggen dat LastPass minder veilig is dat Keepass, alleen de belangrijke verschillen benoemen LastPass schijnt wel eenvoudiger in gebruik te zijn, zeker door de browser plugins. Al zijn die er misschien voor Keepass ook wel, weet ik eerlijk gezegd niet.

Voor mij was het feit dat het open source is (hoewel dat een vals gevoel van veiligheid kan zijn) en het feit dat het qua werking een lokale db is, de voorname reden voor Keepass. Dat ik het bestand zelf in Dropbox mik is mijn eigen keuze geweest, maar in principe hoeft het bestand mijn pc niet te verlaten.

[ThaNOD]

OkkE schreef op donderdag 07 juni 2012 @ 13:02:
Instant Bugfix nodig? Alstublieft: http://instantbugfix.com/

Nieuwe classname nodig? Alstublieft: http://classnamer.com

[Soultaker]

.oisyn schreef op donderdag 07 juni 2012 @ 12:45:
Dus bij 8e17 wachtwoorden heb je net iets minder dan een tiende procent kans op een collision. Bij de 161 miljoen wachtwoorden in de LinkedIn database is de kans op een collision p(2¹²⁸, 161e6) =~ 1 - e^-3e-23 =~ 0.

Ligt het aan mij of doe je sowieso veel te moeilijk?

Al die andere wachtwoorden zijn onafhankelijk; ze kunnen immers ook met elkaar colliden in plaats van met jou. Elke collision heeft kans 2^-96 (128 bits hash minus 8 hexdigits = 32 bits weggestreept, toch?). De kans dat één van N onafhankelijke gebeurtenissen met kans P optreedt is 1 - (1 - P)^N.

Voor 8e17 wachtwoorden kom ik dan op een kans van 1e-11 (veel minder dan 0.1%) en met 161e6 op 2e-21.

Als P ≪ 1/N is de kans ongeveer gelijk aan P×N trouwens, wat voor deze getallen ook heel aardig klopt.

[.Gertjan.]

D-Raven schreef op donderdag 07 juni 2012 @ 13:13:
[...]


Stel je wel CommandName e.d. op de knop in ?

Jep, sowieso moet het event gewoon optreden zelfs zonder de CommandName, maar de eventhandler wordt totaal niet geroepen.

Het komt inderdaad door wat Alex) al aangaf. Ik bind de data bij de render, daar breekt hij dus zijn nek over... Het punt was namelijk dat het control nog vrij laat door de pagina kan worden aangepast. Mijn reactie was dus: "binden op het laatste moment". Was alleen even vergeten dat binden in de render altijd voor problemen zorgt. PreRender is de juiste plek (hoewel ik me wel afvraag of ik het op zo'n manier moet oplossen omdat ik zo mogelijk te vaak de data ophaal)

Heb dit al eerder gehad, toen het kwartje viel besefte ik me dat ik dit al vaker heb meegemaakt...

[RobIII]

Cloud schreef op donderdag 07 juni 2012 @ 13:19:
LastPass schijnt wel eenvoudiger in gebruik te zijn, zeker door de browser plugins.

Voor elke (major) browser is er wel een. En voor een luttel bedrag ($12 p/jaar) kun je 't ook op je smartphone gebruiken. Nog leuker, wat ik vandaag pas ontdekte, is dat 't (waarschijnlijk sinds "kort") ook de Google Authenticator voor 2-factor authentication kan gebruiken. Scheelt weer $25 voor een yubikey

[Korben]

RobIII schreef op donderdag 07 juni 2012 @ 13:53:
[...]

Voor elke (major) browser is er wel een. En voor een luttel bedrag ($12 p/jaar) kun je 't ook op je smartphone gebruiken. Nog leuker, wat ik vandaag pas ontdekte, is dat 't (waarschijnlijk sinds "kort") ook de Google Authenticator voor 2-factor authentication kan gebruiken. Scheelt weer $25 voor een yubikey

Een yubikey? Hoe stel je die in voor 2-factor authentication voor Google dan?