Implimenting Privacy: OAuth and Token Madness
•Download as ZIP, PDF•
30 likes•18,904 views
Ever cringe when you're asked to enter your email address and password to a third party service? This talk will cover how to build and consume services which protect users privacy with OAuth and other techniques. Ever cringe when you’re asked to enter your email address and password to a third party service? Even worse when we build systems which collect people’s credentials. It’s the password anti-pattern. Privacy and security are important, but when it comes to real running apps, it works wins over it’s secure. This has two main themes. * How to use tokens and other tricks to protect the privacy of your users. * While examples will be from a ruby on rails application, this talk is more on general web development practices for privacy. There is no totally secure or private system out there, especially when we build social web applications. But there are many things which can be done to improve privacy. For each application you have to look at what the threat model is for leaking personal information. Everything from how your user passwords are stored to what happens if a hacker gets a full dump of your database. * What happens when a user’s email is compromised by a third party service? * How to provide simple sharing with casual privacy. * What is ‘good enough’ crypto. * Understanding the difference between Authorization and Authentication. This talk is based on experience designing and architecting Yahoo! Fire Eagle, a location sharing service which was the first implementation of both OAuth and Ruby on Rails at yahoo.
Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
More from Rabble .
More from Rabble . (15)
Recently uploaded
Recently uploaded (20)
Implimenting Privacy: OAuth and Token Madness
- 2. Privacy
- 4. The Privacy to Disappear
- 6. Privacy and the State
- 7. Privacy and the Law
- 8. Can you say? source: http://www.crestpublishing.co.za/killthepresident.html
- 9. Kill the Cuban president? source: http://flic.kr/p/RfwD
- 12. Email & Logins
- 13. One email per person
- 15. We use email for everything!
- 16. Hackers want your email
- 18. Dear God Why?!?!
- 19. Fail
- 20. Salvation?
- 22. Delegated Token Authorization FlickrAuth, Google AuthSub, Yahoo’s BBAuth, Facebook Auth, Amazon AWS, AOL OpenAuth, etc...
- 23. Tokens
- 24. Like Coins?
- 25. Symbols
- 26. username password token secret
- 27. timoreilly password token secret
- 28. timoreilly alphag33ks token secreto
- 29. timoreilly alphag33ks SLx39nv4 secreto
- 30. timoreilly alphag33ks SLx39nv4 L9vQlviq2x
- 32. Cryptographic Signatures consumer = Auth::Consumer.new( 'dpf43f3p2l4k3l03', 'kd94hf93k423kf44' ) token = Auth::Token.new( 'nnch734d00sl2jdk', 'pfkkdhi9sl3r4s00' ) signature = Auth::Signature.sign(request, { :consumer => consumer, :token => token, :uri => 'http://photos.example.net/photos' } ) assert_equal 'tR3+Ty81lMeYAr/Fid0kMTYa/WM=', signature
- 33. Cryptographic WHAT? TOKEN HASH KEY SECRET
- 34. Cryptographic WHAT? TOKEN HASH KEY SECRET signature
- 35. Cryptographic WHAT? TOKEN HASH KEY SECRET signature
- 36. Cryptographic WHAT? TOKEN HASH KEY SECRET signature sig=aslkdjfalskd
- 37. Cryptographic WHAT? TOKEN HASH KEY SECRET signature token=vkzljxc&sig=aslkdjfalskd
- 38. Delegated Token Authorization FlickrAuth, Google AuthSub, Yahoo’s BBAuth, Facebook Auth, Amazon AWS, AOL OpenAuth, etc...
- 41. Authentication Authorization OpenID OAuth
- 42. Authentication Authorization OpenID OAuth Users Applications
- 43. Very Simple
- 44. Love Triangle end user consumer service application provider
- 45. Three Legs end user consumer service application provider
- 46. Two Legs consumer service application provider
- 53. Buenos Aires, Argentina San Jose, California
- 54. Token Dance consumer provider
- 55. Token Dance consumer provider requesting the request token
- 56. Token Dance consumer provider requesting the request token creates and returns a new request token
- 57. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url
- 58. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url user selects preferences and approves auth
- 59. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token
- 60. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token consumer wants to trade request token for access
- 61. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token consumer wants to trade request token for access provisional request token traded for access token
- 62. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token consumer wants to trade request token for access provisional request token consumer saves the traded for access token access token for the user
- 63. Token Dance web applications desktop applications out of band applications like mobile and embedded
- 68. OAuth Params oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tRMTYa%2FWM%3D"
- 69. Forms of OAuth HTTP GET params HTTP POST params HTTP Headers XMPP - Jabber
- 71. HTTP HEADERS params GET /photos?size=original&file=vacation.jpg HTTP/1.1 Host: photos.example.net:80 Authorization: OAuth realm="http://photos.example.net/ photos" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa %2FWM%3D"
- 72. HTTP POST params POST /photos?size=original&file=vacation.jpg HTTP/1.1 Host: photos.example.net:80 oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa %2FWM%3D"
- 73. Ignore the details source: http://flic.kr/p/5NRADb
- 74. Libraries
- 75. Gems sudo gem install oauth github.com/mojodna/oauth
- 76. Plugins
- 78. OAuth on Rails rails osconrails -m rails-base-template.text cd osconrails ./script/plugin install git://github.com/pelle/oauth-plugin.git
- 79. Add the oauth-plugin ./script/generate oauth-plugin exists app/models/ create app/views/oauth create app/views/oauth_clients create app/models/client_application.rb create app/models/oauth_token.rb create app/models/request_token.rb create app/models/access_token.rb create app/models/oauth_nonce.rb create app/controllers/oauth_controller.rb create app/helpers/oauth_helper.rb create app/controllers/oauth_clients_controller.rb create app/helpers/oauth_clients_helper.rb create spec/models/client_application_spec.rb create spec/models/oauth_token_spec.rb create spec/models/oauth_nonce_spec.rb create spec/fixtures/client_applications.yml create spec/fixtures/oauth_tokens.yml create spec/fixtures/oauth_nonces.yml create spec/controllers/oauth_controller_spec_helper.rb create spec/controllers/oauth_controller_spec.rb create spec/controllers/oauth_clients_controller_spec.rb create app/views/oauth_clients/_form.html.erb create app/views/oauth_clients/new.html.erb create app/views/oauth_clients/index.html.erb create app/views/oauth_clients/show.html.erb
- 80. Update your routes ./config/routes.rb map.resources :oauth_clients map.authorize '/oauth/authorize',:controller=>'oauth',:action=>'authorize' map.request_token '/oauth/request_token',:controller=>'oauth',:action=>'request_token' map.access_token '/oauth/access_token',:controller=>'oauth',:action=>'access_token' map.test_request '/oauth/test_request',:controller=>'oauth',:action=>'test_request'
- 81. Filters for access control class ApiController < ApplicationController before_filter :login_or_oauth_required, :except => [:oauth_only_action] before_filter :oauth_required, :only => [:oauth_only_action]
- 82. That’s it!
- 83. Desert
- 84. Careful: nonce & timestamp
- 85. Careful: nonce & timestamp source: http://flic.kr/p/QtskX
- 86. Use separate DB’s source: http://flic.kr/p/6xtHZp
- 88. Without Login
- 89. Privacy Wall
- 90. Privacy Wall
- 91. Privacy and the Law
- 92. Expire Tokens
- 93. CSRF & XSS - Careful!
- 94. Don’t Log Everything source: http://flic.kr/p/5VcQWT
- 95. Selective Logging source: http://flic.kr/p/5Zkwex
- 96. dev.riseup.net/privacy/ source: http://dev.riseup.net/privacy/
- 97. Except Telephony source: http://flic.kr/p/4DzMNu
- 98. Privacy is Freedom source: http://flic.kr/p/5anoq
Editor's Notes
- Privacy. It&#x2019;s a tricky idea. It&#x2019;s really to try and protect the interests and information of our users. As they want.
- Or sometimes what we do is provide the perception of privacy. This is what a privacy policy is, Nobody reads it, so what it really does is provide the perception that there is privacy.
- Many users don&#x2019;t want to appear in public at all, or they want to be able to delete their users and associated information. Perhaps they don&#x2019;t want everybody to know they&#x2019;re in the furries flickr group.
- Some people value privacy over all else. They might wear a burka or use tor.
- People use the internet for many things. What ever application you&#x2019;re building, could unwittingly become a space for free speech. What happens if the government asks for your database? What if it&#x2019;s legal in your country, but illegal in another?
- For example, it&#x2019;s illegal to insult or mock the Pope in Italy. If you can publish photos on your website, then the Italian government could demand to know the identity of the poster. If they posted this image from italy they&#x2019;d be committing a crime.
- Another example, in Argentina, their national hero is Diego Maradona a soccer star. It&#x2019;s illegal to publish real or photoshoped porn with Maradona in it. Protected speech in one country is illegal speech in others.
- Here in the US for example there&#x2019;s a great tradition of free speech with some rather odd limitations. For example you can&#x2019;t say, i want to shoot the president....
- Unless you&#x2019;re talking about somebody else&#x2019;s president. No problem wanting to kill the cuban or iranian president.
- Show a picture of the mouse. The most common example of free speech limits in the US are mostly commercial limits.
- Beyond problems with corporations and governments, you&#x2019;ve got the hacker problem. They really want to get at our users and systems. In all of our work we&#x2019;ve got to think about what kinds of attacks we might face in production.
- Right now we use email as the primary way of logging in to systems. It&#x2019;s the core of the identity system online right now.
- The majority of people use a single email account for everything. The protection of this email is very important.
- When somebody has access to your email, they&#x2019;ve got access to everything.
- With email accounts we can reclaim passwords for online banking systems. With this access we can eventually take money out of a users bank accounts. A users email account is the real key to paypal and online banking.
- One of the reasons there are so many problems with spam, and phishing sites is that hackers really want to get at users email accounts.
- We use email for all of our internal documents which used to be on a desktop. Now they are in the cloud, and email is guarding them.
- So with email being so important, so essential to a user&#x2019;s life online, to their bank accounts and internal company documents. WHY do we build things like this. We teach users to share their passwords!
- Fail, really, we as web developers, as a community, are failing out users.
- But there is salvation, a way out. We don&#x2019;t have to persist with this nightmare.
- In reality, there are a ton of authorization systems which don&#x2019;t use email addresses and passwords.
- Each one does more or less the same thing in slightly different ways.
- What are these token things we talk about? There&#x2019;re little things we use to represent access, kind of like a subway token.
- Well kind of like coins, but each token is unique
- More like symbols, which can be used to represent something without it being the thing.
- The trick with all the delegated token authorization systems is that they DON&#x2019;T pass the password with teach request. They use a token, and a secret. The secret is used in the signature but not passed over the wire.
- It&#x2019;s more this kind of signature. Crypto. HMAC or RSA SHA1.
- So what does this look like, well we use the token and the hash key secret.
- We use the combination of the token and then the secret as the has key to sign the token, well not just the token, but the whole request.
- Then that signature is created as a param which can be passed in the requests.
- So you end up something like this. The token, and the signature is passed over the wire. The secret is kept on both ends to verify the signature.
- So this delegated token authorization. There are 20 different types. Each one is sufficiently different that you have to build up the libraries from scratch. Each auth system needs a library in every language.
- There is now one delegated token auth system to rule them all. Based on all the best practices of the past.
- The original idea of OAuth would be that it&#x2019;s super simple, clear, everybody could read the standard and understand. It was nice and clear. Little by little in the standards process the standards people from IETF and W3C got involved. Now the spec is full of diagrams like this!
- All this is to say that OAuth is like a love triangle. That is to say that the relationship between he provider, end user, and consumer is a love triangle. Each part communicates with both of the other parts.
- Normally oauth has three legs, the user, the provider, and the consumer. But it&#x2019;s possible to use oauth to remove the user from the equation. Creating 2 legged oauth.
- In 2 legged oauth there is the same libraries and toke signing between the consumer and the provider. Yahoo for example uses this model to control access to web services which are accessed on application&#x2019;s own behalf. There doesn&#x2019;t have to be a user. OAuth&#x2019;s standardized signing / anti replay attacks are useful for many APIS.
- Great, but what&#x2019;s it like for the user? Very simple. Here we&#x2019;re going to walk through a MovableType client application getting the user to authorize Fire Eagle to share the user&#x2019;s location.
- So when we click the connect link, we&#x2019;re taking to fire eagle, which asks us to login.
- Then once we&#x2019;re logged in we get a confirmation page.
- The request is made with a provisional request token, which tells us among other things what application is being authorized. The user then can see that application that they are going to authorize.
- It&#x2019;s possible at this stage for the provider to ask for preferences to constrain the permissions of the application. For example, can publish but not delete. This is very important because it&#x2019;s something you couldn&#x2019;t do if you handed over the user name and password to the client application. It&#x2019;d be full control or nothing.
- And after preferences, the user can choose to approve or deny the authorization of the application to their protected resources.
- After a user hits confirm, they&#x2019;re redirected back to the consumer based on the callback url assigned, and as far as the user is concerned the association is setup.
- For the user the whole process is 4 clicks. Behind these simple 4 clicks is a token dance between the consumer, provider, and end user.
- the application asks for a request token
- the application asks for a request token la aplicaci&#xF3;n inicia el intercambio del request token
- the application asks for a request token la aplicaci&#xF3;n inicia el intercambio del request token
- the application asks for a request token la aplicaci&#xF3;n inicia el intercambio del request token
- the application asks for a request token la aplicaci&#xF3;n inicia el intercambio del request token
- the application asks for a request token la aplicaci&#xF3;n inicia el intercambio del request token
- the application asks for a request token la aplicaci&#xF3;n inicia el intercambio del request token
- the application asks for a request token
- That was the token dance for web applications. There is a similar but slightly different process for desktop and out of band applications like browserless mobile phones and embedded systems like an arduino.
- All of the oauth params start with the oauth_* prefix.
- As we saw before, there are keys (tokens) and secrets. The consumer application or library itself has a token secret part, in addition to a user&#x2019;s access token and secret. The key is passed with each request, and the consumer secret is used for signing every request.
- The tokens are just random strings which should be unique.
- Then we require that each request have a timestamp and nonce. The timestamp is an integer which needs to increment. The nonce is a unique number/string which can&#x2019;t be reused with the same timestamp. The combination of these, and the signing prevents replay attacks.
- The last couple define the signing method, this could be public key, but usually it&#x2019;s HMAC-SHA1. Then the version of oauth, which despite the current standard being 1.0a the standard says you should still say 1.0. Then the actual signature of the request.
- OAuth signing and authorization can go over
- Hay mucho formas de hacer una request de OAuth.
- Hay mucho formas de hacer una request de OAuth.
- Hay mucho formas de hacer una request de OAuth.
- tambi&#xE9;n puede poner todo los params en el HTTP POST.
- por que tenemos liberias para hacer todo los detalles en todo los lenguajes. El primero implementaci&#xF3;n de OAuth fue en Ruby para aplicaciones de rails. Ahora todo los plataformas tiene apoyo para OAuth.
- por que tenemos liberias para hacer todo los detalles en todo los lenguajes. El primero implementaci&#xF3;n de OAuth fue en Ruby para aplicaciones de rails. Ahora todo los plataformas tiene apoyo para OAuth.
- En nuestra caso, tenemos un muy buen gems para OAuth.
- So you simply add the plugin to your rails app.
- It adds a ton of files to your system to handle all the oauth process. You&#x2019;re going to want to customize the templates.
- Add the routes to make all the oauth requests make sense. These urls are set, there is a discovery process by which you can use alternate oauth urls but it&#x2019;s best if you can to just keep them standard.
- The last thing you need to do is add before filters requiring authorization for the the actions and resources you need to protect.
- In terms of OAuth, that&#x2019;s it. It&#x2019;s simple to create a basic provider and consumer.
- So that&#x2019;s enough to get over to using oauth in your apis. Getting to oauth is important, but it&#x2019;s not the end of building systems which respect privacy.
- Remember how i was talking about the nonce and timestamp? Well Nonce in British slang is a pedophile, but it&#x2019;s got another meaning. It&#x2019;s a one time number. The OAuth spec says you have to provide a nonce and timestamp, but they don&#x2019;t require that you check them.
- what you want to do is make sure that the timestamp always the same or higher by some amount, and that the nonce for that timestamp & consumer hasn&#x2019;t been used before. You don&#x2019;t have to store all past nonces.
- Don&#x2019;t even store your auth credentials in the same databases as you&#x2019;re using for the rest of your application. Use metal, or a proxy to authorize the requests, then pass that through to your apis. This is kind of similar to what google and yahoo do where the authentication and authorization systems are divided off from the production application itself.
- While it&#x2019;s recommended to use HMAC-SHA1, it&#x2019;s possible to use other forms of signing. Google for example uses RSA public / private keys for it&#x2019;s oauth. If a provider passes everything over ssl it&#x2019;s possible to use the unsigned PLAINTEXT signing method. :)
- Sometimes you need the data for a single use. Don&#x2019;t do a login at at all, just store the keys in the cookie, once the user leaves and the tokens disappear.
- One thing you can do is use the authorization and tokens to make a wall between your user profiles and their associated data. That way you can only get foreign key when a user or authorized application is actively using the service. Wesabe and Fire Eagle both use this style system.