mboost-dp1
Apropos hashes - 2
(opfølgning på http://newz.dk/forum/tagwall/apropos-hashes-123638...
Han har postet en opfølgende artikel omkring ændringer i implementation i ASP.NET:
http://www.troyhunt.com/2012/07/stronger-password-...
Artiklen er igen rodet i konklusionen. IDE har naturligvis ikke noget med de grundliggende muligheder at gøre.
Men stadig interessant.
Pointen at N iterationer vil øge crack tiden med en faktor N men øge normal brug tiden med en faktor betydeligt mindre er naturligvis interessant.
Han har postet en opfølgende artikel omkring ændringer i implementation i ASP.NET:
http://www.troyhunt.com/2012/07/stronger-password-...
Artiklen er igen rodet i konklusionen. IDE har naturligvis ikke noget med de grundliggende muligheder at gøre.
Men stadig interessant.
Pointen at N iterationer vil øge crack tiden med en faktor N men øge normal brug tiden med en faktor betydeligt mindre er naturligvis interessant.
Et hurtigt overslag på tallene i artiklen gav mig et resultat der siger at overheadet til alt det andet der foregår ved login svarer til ca. 30 iterationer af hashfunktionen.
Artiklen argumenterer for at derfor gør det ikke noget at man skal bruge lidt CPU tid på at iterere sin hashfunktion. Et stykke hen af vejen vil jeg give ham ret i det. Dog vil jeg lige påpege at når antallet af iterationer øges til 1000 så får han en reduktion i hastigheden med en faktor 34. En faktor 34 har en betydning hvis serveren kommer under angreb.
En forøgelse fra 1 til 10 iterationer gør password brute forcing 10 gange langsommere men øger omkostningerne ved legitim brug med mindre end 50%. Det ser ud som en klar fordel.
En forøgelse fra 10 til 100 iterationer gør password brute forcing 10 gange langsommere, men øger omkostningerne ved legitim brug med over 200%. Det er lidt mindre klart om det er en fordel.
En forøgelse fra 100 til 1000 iterationer gør password brute forcing 10 gange langsommere, men øger omkostningerne ved legitim brug ca. 8 gange. Det ville jeg ikke gøre uden først at lave en grund undersøgelse af trusselsscenariet.
Artiklen argumenterer for at derfor gør det ikke noget at man skal bruge lidt CPU tid på at iterere sin hashfunktion. Et stykke hen af vejen vil jeg give ham ret i det. Dog vil jeg lige påpege at når antallet af iterationer øges til 1000 så får han en reduktion i hastigheden med en faktor 34. En faktor 34 har en betydning hvis serveren kommer under angreb.
En forøgelse fra 1 til 10 iterationer gør password brute forcing 10 gange langsommere men øger omkostningerne ved legitim brug med mindre end 50%. Det ser ud som en klar fordel.
En forøgelse fra 10 til 100 iterationer gør password brute forcing 10 gange langsommere, men øger omkostningerne ved legitim brug med over 200%. Det er lidt mindre klart om det er en fordel.
En forøgelse fra 100 til 1000 iterationer gør password brute forcing 10 gange langsommere, men øger omkostningerne ved legitim brug ca. 8 gange. Det ville jeg ikke gøre uden først at lave en grund undersøgelse af trusselsscenariet.
Det er en interressant idé, på systemer som ikke har mulighed for bedre alternativer, især fordi man kan gemme antallet af iterationer, og skrue op på det løbende.
Men jeg ville nu hellere bare bruge en hash-funktion som BCrypt hvor du selv kan skrue på paramatrene for at gøre den sløvere.
Men jeg ville nu hellere bare bruge en hash-funktion som BCrypt hvor du selv kan skrue på paramatrene for at gøre den sløvere.
Hvad er fordelene ved at implementere det sådan her, istedet for at bruge BCrypt?
Han skriver følgende:
Men er ikke rigtigt inde i deres MS toolchain. Men kan det virkelig passe at man ikke kan hive et library eller andet ind og benytte sig af det? (det er det jeg tror han mener er problemet)
Han skriver følgende:
I liked the ease of pulling it from NuGet but lamented the fact that it required GAC installation and machine.config modification which ruled it out of running on modern PaaS style implementations like I’m using at AppHarbor or you’ll find in Azure.
Men er ikke rigtigt inde i deres MS toolchain. Men kan det virkelig passe at man ikke kan hive et library eller andet ind og benytte sig af det? (det er det jeg tror han mener er problemet)
KaW (5) skrev:Men er ikke rigtigt inde i deres MS toolchain. Men kan det virkelig passe at man ikke kan hive et library eller andet ind og benytte sig af det? (det er det jeg tror han mener er problemet)
Det han skriver er at deres lib skal installeres på systemet og derfor ikke kan bruges i diverse cloud løsninger.
Men han fortsætter:
Fortunately the folks over at Zetetic have managed to bundle all that machine-level dependency up into a pretty quick fix;
PBKDF2 har været gennem mere review end Bcrypt, så sandsynligvis er PBKDF2 mere sikker. PBKDF2 kan baseres på en vilkårlig hash, så du kan vælge en hash som har været udsat for passende review.KaW (5) skrev:Hvad er fordelene ved at implementere det sådan her, istedet for at bruge BCrypt?
Det største problem med PBKDF2 i det perspektiv er at den "kun" specificerer hvordan man laver en (symmetrisk) nøgle ud af et password. Den specificerer ikke hvordan man validerer et password med metoden. Men den detalje er relativt nemt i sammenligning med resten.
Spændende læsning om BCrypt vs PBKDF2
TL;DR: BCrypt passer ikke så godt ned på en GPU (god ting), det gør PBKDF2 tilgengæld (dårlig ting).
BCrypt passer tilgengæld pænt ned på en FPGA (skidt ting)
TL;DR: BCrypt passer ikke så godt ned på en GPU (god ting), det gør PBKDF2 tilgengæld (dårlig ting).
BCrypt passer tilgengæld pænt ned på en FPGA (skidt ting)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund