The document discusses vulnerabilities in various cryptographic hashing algorithms such as MD5 and SHA1, highlighting their inadequacies in security. It introduces password hashing techniques like PBKDF2, bcrypt, and scrypt, emphasizing their advantages over conventional methods. Additionally, it touches upon the importance of using HMAC for secure messaging and the limitations of SSL in ensuring data privacy.

1. Web crypto
karl von randow

2. I felt sorry for this theme

4. What’s wrong with plain text?

5. What’s wrong with MD5?

6. It’s been
CRACKED
It has lots of vulnerabilities
since 1996.
Really bad since 2008.

7. What’s wrong with SHA1?

8. It’s been
CROAKED
Actually it’s just a bit
vulnerable maybe.

9. What about
salt?
Effective against
rainbow tables

11. So salt is
okay
But not against the other
collision attacks

12. PBKDF2
• Password-Based Key Derivation
Function 2
• Easy to remember acronym
• It’s a standard

13. • Salted - hurts rainbow tables
• Repeats a hash lots of times - key
stretching
• Adjustable difficulty

14. Can be implemented with a
small circuit and very little
RAM
Uh oh

17. bcrypt
• Everything PBKDF2 has (except it’s not
a standard)
• Aims to be slow
• Been around for ages and unbroken

18. • A bit of a pain when converting plain
text passwords in the database as it
takes a while

20. What about FPGAs?

22. Oh

23. What about scrypt?

25. scrypt
• Like bcrypt but uses more RAM
• Really new (2009)

27. Migrating from existing
• Plain text - batch convert
• PostgreSQL contrib package
• Hashed - convert on successful login

28. Hashes in APIs
Signature algorithms

29. 2009
• MD5 length extension hack
demonstrated on Flickr API
(and others)

31. • Hashes are not good for signing

32. Use the right tool for the job

33. HMAC
• Hash-based message authentication code
• HMAC-SHA1
• Uses a secret key

34. • Substantially less affected by collisions
• No known extension attacks

35. What about SSL?

36. SSL
• Privacy in between
• Only secure when both parties have a
vested interest in security

40. • If you control the client
• Tell system to trust a new CA
• Man-in-the-middle

42. • Doesn’t protect your API from being
tinkered with or disclosed

43. Only $50

44. i have seen that yours is
the shittest software ever
#@%! your mothers

45. “CWP was pivotal in helping me crack an
https encrypted API for an iPhone
application. Thankfully, that was their only
method of securing the data, because it
lead to me bringing online stats for a cult-
classic video game called SSX... So, I just
wanted to say thanks!”

46. “... after seeing the URLs were GET
requests with username and passwords, I
figured this was going to be VERY EASY. I
actually did it all during the 30 minute trial
of the program. (that reminds me, I should
buy a license because it was so awesome).”
Justin J.N.

47. Thanks
Sir JBall
for the sweet vector
illustrations. They really
cleared things up.

48. What about validating the
certificate?

49. bcrypt &
HMAC-SHA1
SSL for privacy