1. Passwords suck Nico Smit November 2014

2. “The million passwords dilemma:”  Just like having a million keys suck, so also having a million usernames and passwords suck

3. “The million passwords dilemma:”  We are developers, we make life better and more efficient  If something is a drag, a developer finds a way to optimize it

4. “The million passwords dilemma:”  We are supposed to come up with better solutions/alternatives to the million passwords dilemma

5. Some possible solutions to consider

6. Option 1: Globally recognized “proxy” login accounts

7. Option 1:  Log in with Google  Log in with Facebook  Log in with Twitter  Etc.

8. Option 1:  Pros  Everyone has one of these accounts, so setup is complete  APIs and functionality already exists

9. Option 1:  Cons  Granting access to a website through these accounts, also opens up your personal information to the website you log in to.

10. Option 1:  We as developers should be pushing universal logins on websites we develop as far as possible, when it makes sense

11. Option 2: Assume someone's email address and inbox is secure

12. Option 2:  Its 2014, emails and mailboxes should be secure, hidden behind a username and password, encrypted connections etc.

13. Option 2:  So assuming that the email inbox is secure, we can send any sensitive information to the email inbox we want. (usernames, passwords, urls etc.)

14. Option 2:  So assuming that the email inbox is secure, we can send any sensitive information to the email inbox we want. (usernames, passwords, urls etc.)

15. “The encrypted url auto login”

16. The encrypted url auto login :  (1) Build a JSON object containing username, password, action to commit, page to redirect afterwards etc.

17. The encrypted url auto login :  (2) Encrypt the JSON object (string) with two way encryption

18. The encrypted url auto login :  (3) Build a receiver for the encrypted string on the website  Catch as variable from url  Decrypt  Do the awesomeness

19. The encrypted url auto login :  (4) End result:  Example.com?auto=df7gwgh7gfpsh

20. Option 2:  Pros  Never log in again, forget your password  Perform any action on website from the url click

21. Option 2:  Cons  People can hack into your email account… (and everything else… so what?)  Must have your email open on your device

22. Option 3: Assume someone’s PC desktop is secure

23. Option 3:  Build an actual “key” to actually unlock websites

24. “Website keys”

25. Option 3:  Actual xml file on your computer dashboard  The xml file contains username, password, address, name, surname etc.

26. Option 3:  Drag the “key” into the login area on website to log in  Option to allow registration with key as well

27. Option 3:  After registering on a website, have the option to “download your key for xxxxx”

28. Option 3:  A universal standard will have to be implemented for “website keys”

29. Option 3:  Stack ‘em up. Have a folder on your dashboard full of keys  Or password protect the folder…

30. Option 3:  Pros  Drag and drop  Your mother could understand it

31. Option 3:  Cons  Do you really want all your passwords lying on your PC dashboard?

32. Option 4: Create an online “password vault” for everything

33. Option 4:  Implement accessible API

34. Option 4:  Pure in-browser example:  At login, button that says “Get details from password vault” - click

35. Option 4:  Pure in-browser example:  Opens in new tab, Redirects to password vault with current domain name attached (?site=randomsite.com)

36. Option 4:  Pure in-browser example:  Email and password login to password vault  Immediately shows username and password for site

37. Option 4:  Mobile phone example:  At login, show QR code to scan: “Get details from password vault”

38. Option 4:  Mobile phone example:  Phone goes to password vault with current domain name attached (?site=randomsite.com)

39. Option 4:  Mobile phone example:  Email and password login to password vault

40. Option 4:  Mobile phone example:  Immediately shows username and password for site

41. Option 4:  One time pin solution:  Instead of password vault showing username and password, let it generate a one time pin, valid for one minute

42. Option 4:  One time pin solution:  Website where user is trying to log in, has a textbox to fill in one time pin. “Log in with password vault one time pin”

43. Option 4:  One time pin solution:  Submit does API call to password vault, if success, logs user in

44. Option 4:  Pros  Everything in browser  Device independent

45. Option 4:  Cons  Getting the whole world to buy into the idea of “one password vault”

46. Questions? Criticisms? Rotten tomatoes??