Identity toolkit
•Download as PPTX, PDF•
0 likes•111 views
Slides for talk given at the Identity Toolkit session hosted by the GDG Ibadan
Recommended
Recommended
More Related Content
Similar to Identity toolkit
Similar to Identity toolkit (20)
More from Gbolahan Alli
Recently uploaded
Recently uploaded (20)
Identity toolkit
- 1. Google Identity Toolkit Gbolahan Alli @purple_heart_me Google Developer Group, Ibadan September 7, 2015
- 2. Developers shouldn’t need to be security experts.
- 3. The hack that makes Internet Identity possible
- 4. The Hack Logging into a website using your email address. Proving you were the owner of that email address by having the site send you an SMTP message with a hyperlink back to the site which contained a long code.
- 5. Email have downsides as identifiers. ❏Users change email address over time ❏The same email address is sometimes assigned to different people at different time periods
- 6. Solution ? Almost every website still maintains its own “local ID” system just as user accounts did before the 90s.
- 7. A plus ? The local IDs are then mapped to and from a user’s email address.
- 8. Remember !!! We are still talking identity here
- 9. Which face are you presenting to the world?
- 10. Which face are you presenting to the world? Some websites such as government websites for taxes and social services try to get closer to mapping to an actual person, .
- 11. Which face are you presenting to the world? Human -> Emails -> Local IDs -> Passwords
- 12. Which face are you presenting to the world? In short : The security of the Internet as a whole is now equivalent to the security level of websites with the worst security
- 13. Which face are you presenting to the world? In short : ● The security of the Internet as a whole is now equivalent to the security level of websites with the worst security ● Unless you work for a firm with hundreds of dedicated security personnel, there generally is no reason for your site to require that users are authenticated with passwords.
- 15. The year 2008?
- 16. A Solution ?
- 17. We need to understand that : ● Each person tends to access the Internet with multiple devices, and about the only thing in common is that they have a browser, and not necessarily a fancy modern browser, especially on mobile devices. ● Each device may be used by multiple people, who have multiple emails. ● People need a (mostly) consistent experience for logging into a website, no matter what device they are using ● You can’t show a different initial login experience on your site to different people, because before they login, you don’t know who they are. This also means you can’t do % experiments for that initial experience ● People are lazy
- 18. People are lazy but they are willing to invest in a longer task one-time to make their lives easier in the future.
- 19. Who are Identity Providers ?
- 22. The Identity Toolkit A set of Libraries that integrate with the Google Identity Toolkit API. Available for : ● For Web ● For Android ● For iOS Pre-built widgets for Android, iOS, and JavaScript
- 23. The benefits
- 24. The Approach
- 25. The Approach ( cont’d )
- 26. The Approach ( cont’d ) Image courtsey : Adam Dawes, Google https://goo.gl/TPLOeD
- 27. Benefits ●Device flows ●Streamlined federations flows ●Risk challenges ●Simplified UX for users
- 28. The Identity Toolkit ●Google, Facebook, Yahoo, AOL, Microsoft and Paypal ●Just verify a JWT and issue a session cookie ●Same process for all IDPs, same format JWT for all IDPs { "iss" : "https://identitytoolkit.google.com", "user_id" : 123, "aud" : "6332423432073.apps.googleusercontent.com", "provider_id" : "facebook.com", "exp" : 1407089191, "iat" : 1405879591, "email" : "jsmith@gmail.com" }
- 31. Hacks!!! Hacks!! cat ~/.ssh/id_rsa.pub ssh-keygen -t rsa -b 4096 -C "your_email@example.com" eval $(ssh-agent -s) ssh-add ~/.ssh/id_rsa
- 32. Fetch the GDG Ibadan identity toolkit client repo -> http://bitbucket.org/gdgibadan Merge with your local repo Go to https://console.developers.google.com Documentation here https://developers.google.com/identity/toolkit/ Next Steps
Editor's Notes
- The most common computer science requirement of a User Account system is to provide a unique numeric ID for an account. In a “simple” computer science world, there would be one global user account system, similar to DNS, where every person was assigned a single unique numerical ID at birth, and each person also had a perfect way to prove who they were. Every website could then use those user IDs to store information associated with the person. Obviously that does not exist, and for decades every user account system issued its own IDs (and sometimes usernames) to users. Such systems were “simple” to write, but painful for users.
- Email addresses turn out to be an amazingly good way for users to create a virtual identify that maps to each compartment in their life. In a large % of cases, users try to avoid linking these different identities. One common technique is to use different webmail providers for different email address, because they are so visually different that it reduces the chances that the user might accidentally perform an action in the wrong account. So most websites don’t map user accounts to humans, they map them to email addresses, and only the actual human person knows all of their different compartments, along with the email address used to identify each of those compartments in the virtual world.
- Email addresses turn out to be an amazingly good way for users to create a virtual identify that maps to each compartment in their life. In a large % of cases, users try to avoid linking these different identities. One common technique is to use different webmail providers for different email address, because they are so visually different that it reduces the chances that the user might accidentally perform an action in the wrong account. So most websites don’t map user accounts to humans, they map them to email addresses, and only the actual human person knows all of their different compartments, along with the email address used to identify each of those compartments in the virtual world.
- So humans have a map of the emails they use, and websites map an email to a local ID. Website’s user account systems also have a critical role of authenticating the owner of that email address. Note we did not say authenticate the human, but rather that owner of the email address. The difference is important, as well as powerful, but it also adds complexity. The simplest way to authenticate the owner of the email address is to use the “hack” of sending them a URL with a code every time they want to login. However when that “hack” first became popular, email services had significant downtime, so websites did not want to be reliant on them. So instead we relied on a scheme that had been used for user account systems that issued their own user IDs instead of relying on email address, and that scheme was passwords. Combining the “hack” with passwords seemed great. The best part was that if the user forgot their password, the website could just use the “hack” again to verify the owner of that email address and let them pick a new password.
- Criminals realized that they could make more money by taking over a real user’s email account, and use it to send SPAM. The main cost to the criminals was the cost of hijacking a user’s email account. That had mostly been done through techniques like phishing, malware, and dictionary attacks that were targeted at the user’s main email provider. What the hackers then realized is they could apply those same techniques against any website that let users login with an email address. Since most people reused passwords across sites, the hackers just needed to collect a list of the passwords associated with an email address on other websites, and then try those passwords to login to the user’s main email account. In many cases hackers could also partially break into a website and gain control of the web page that showed its login form. Then whenever users typed their email address and password on the form, it was logged by the hackers. In a lot of cases the hackers broke completely into the website and stole their entire user account system, including the list of email addresses and passwords. Even if the passwords were encrypted, there are special techniques that let the hackers reverse engineer those password lists
- The sad response of much of the computer science and security community was to put the burden of solving this problem back on the user. User’s were told to use different passwords on each site, or at least their “most important” sites.
- In a “simple” computer science world, every device would be used by at most one ID. However the reality is that many devices are used to access multiple IDs, such as a person’s personal accounts and work accounts. Or the person might have multiple jobs or additional personal ”compartments.” In some cases, the device will even be shared with other people. Computer scientists frequently try to force back the “one ID” simplification by using other tricks like having different operating system level accounts, or browser accounts. However they fall into the category of “solutions designed by computer scientists that could only be used by other computer scientists.” On mobile phones in particular they completely fail.
- If your site does not ask the user for their password, then you need to get some other website needs to do that job. Those other websites are traditionally called “identity providers.” Those sites frequently have very large security teams, and they use sophisticated schemes to protect accounts. They generally do not rely on passwords alone to authenticate users. They may even have been audited against certification checklists to evaluate their security.
- First time users to your website see this screen. Asking for who they want to authenticate with.
- Returning users with multiple identities are presented with this screen. They’ve been authenticate just one time. Simpler, Sweeter, Cleaner. No headaches too.
- Google Identity Toolkit enables app and website makers to easily support multiple authentication options for their end users.
- On the front end, native mobile libraries as well as javascript that power a full user sign in & registration flows, informed by the latest in Google UX research. On the backend, convenient libraries in the top server languages, which help you properly validate credentials or perform simple user management. And, of course, underlying all of this is the Cloud service that securely stores and verifies user credentials. You don’t want to be in the business of developing a secure login system, so you might as well let all the hackers take a crack at Google’s security. With this structure of front-end SDKs, backend libraries, and a cloud service, we can offload as much authentication effort as possible while keeping your accounts secure.
- Previously you had to work with each of this IDP’s and build your login structure on top of them.
- Google Identity Toolkit lowers the bar. Handles multiple protocols .