Search

Implimenting Privacy: OAuth and Token Madness

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Privacy. It’s a tricky idea. It’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’t want to appear in public at all, or they want to be able to delete their users and associated information. Perhaps they don’t want everybody to know they’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’re building, could unwittingly become a space for free speech. What happens if the government asks for your database? What if it’s legal in your country, but illegal in another?

    For example, it’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’d be committing a crime.

    Another example, in Argentina, their national hero is Diego Maradona a soccer star. It’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’s a great tradition of free speech with some rather odd limitations. For example you can’t say, i want to shoot the president....

    Unless you’re talking about somebody else’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’ve got the hacker problem. They really want to get at our users and systems. In all of our work we’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’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’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’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’t have to persist with this nightmare.

    In reality, there are a ton of authorization systems which don’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’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’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’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’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’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’s own behalf. There doesn’t have to be a user. OAuth’s standardized signing / anti replay attacks are useful for many APIS.

    Great, but what’s it like for the user? Very simple. Here we’re going to walk through a MovableType client application getting the user to authorize Fire Eagle to share the user’s location.

    So when we click the connect link, we’re taking to fire eagle, which asks us to login.

    Then once we’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’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’s something you couldn’t do if you handed over the user name and password to the client application. It’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’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ón inicia el
    intercambio del
    request token

    the application asks for a request token
    la aplicación inicia el
    intercambio del
    request token

    the application asks for a request token
    la aplicación inicia el
    intercambio del
    request token

    the application asks for a request token
    la aplicación inicia el
    intercambio del
    request token

    the application asks for a request token
    la aplicación inicia el
    intercambio del
    request token

    the application asks for a request token
    la aplicació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’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’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’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é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ó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ó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’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’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’s it. It’s simple to create a basic provider and consumer.

    So that’s enough to get over to using oauth in your apis. Getting to oauth is important, but it’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’s got another meaning. It’s a one time number. The OAuth spec says you have to provide a nonce and timestamp, but they don’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’t been used before. You don’t have to store all past nonces.

    Don’t even store your auth credentials in the same databases as you’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’s recommended to use HMAC-SHA1, it’s possible to use other forms of signing. Google for example uses RSA public / private keys for it’s oauth. If a provider passes everything over ssl it’s possible to use the unsigned PLAINTEXT signing method. :)

    Sometimes you need the data for a single use. Don’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.

    11 Favorites & 1 Group

    Implimenting Privacy: OAuth and Token Madness - Presentation Transcript

    1. Implementing Privacy OAuth & Token Madness evan@protest.net
    2. Privacy
    3. Perception of Privacy
    4. The Privacy to Disappear
    5. Extreme Privacy
    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
    10. Speech as Property
    11. Privacy & Hackers
    12. Email & Logins
    13. One email per person
    14. Email for Everything
    15. We use email for everything!
    16. Hackers want your email
    17. The Twitter Files
    18. Dear God Why?!?!
    19. Fail
    20. Salvation?
    21. Delegated Token Authorization
    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
    31. Cryptographic Signatures
    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...
    39. Authentication Authorization
    40. Authentication Authorization OpenID OAuth
    41. Authentication Authorization OpenID OAuth Users Applications
    42. Very Simple
    43. Love Triangle end user consumer service application provider
    44. Three Legs end user consumer service application provider
    45. Two Legs consumer service application provider
    46. Buenos Aires, Argentina San Jose, California
    47. Token Dance consumer provider
    48. Token Dance consumer provider requesting the request token
    49. Token Dance consumer provider requesting the request token creates and returns a new request token
    50. Token Dance consumer provider requesting the request token creates and returns a new request token redirect user to provider with token in url
    51. 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
    52. 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
    53. 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
    54. 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
    55. 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
    56. Token Dance web applications desktop applications out of band applications like mobile and embedded
    57. OAuth Params oauth_*
    58. OAuth Params oauth_consumer_key oauth_consumer_secret
    59. OAuth Params oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk"
    60. OAuth Params oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096"
    61. OAuth Params oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tRMTYa%2FWM%3D"
    62. Forms of OAuth HTTP GET params HTTP POST params HTTP Headers XMPP - Jabber
    63. HTTP GET params GET&http%3A%2F%2Fphotos.example.net %2Fphotos&file%3Dvacation.jpg %26oauth_consumer_key %3Ddpf43f3p2l4k3l03%26oauth_nonce %3Dkllo9940pd9333jh%26oauth_signature_method %3DHMAC-SHA1%26oauth_timestamp %3D1191242096%26oauth_token%3Dnnch734d00sl2jdk %26oauth_version%3D1.0%26size%3Doriginal
    64. 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"
    65. 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"
    66. Ignore the details source: http://flic.kr/p/5NRADb
    67. Libraries
    68. Gems sudo gem install oauth github.com/mojodna/oauth
    69. Plugins
    70. Plugins ./script/plugin install git:// github.com/pelle/oauth-plugin.git github.com/pelle/oauth-plugin
    71. OAuth on Rails rails osconrails -m rails-base-template.text cd osconrails ./script/plugin install git://github.com/pelle/oauth-plugin.git
    72. 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
    73. 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'
    74. 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]
    75. That’s it!
    76. Desert
    77. Careful: nonce & timestamp
    78. Careful: nonce & timestamp source: http://flic.kr/p/QtskX
    79. Use separate DB’s source: http://flic.kr/p/6xtHZp
    80. Signing with keys
    81. Without Login
    82. Privacy Wall
    83. Privacy Wall
    84. Privacy and the Law
    85. Expire Tokens
    86. CSRF & XSS - Careful!
    87. Don’t Log Everything source: http://flic.kr/p/5VcQWT
    88. Selective Logging source: http://flic.kr/p/5Zkwex
    89. dev.riseup.net/privacy/ source: http://dev.riseup.net/privacy/
    90. Except Telephony source: http://flic.kr/p/4DzMNu
    91. Privacy is Freedom source: http://flic.kr/p/5anoq
    92. Implementing Privacy OAuth & Token Madness evan@protest.net
    93. Creative Commons Photos http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice http://www.flickr.com/photos/stevenh/360015104/ http://www.flickr.com/photos/cdevers/2785041073/ http://www.flickr.com/photos/myklroventine/3355106480/ http://www.flickr.com/photos/itsallaboutmich/498340461/ http://www.flickr.com/photos/charlesfred/100392094/ http://www.flickr.com/photos/purplemattfish/3126383038/ http://www.flickr.com/photos/exlibris/1579580258/ http://www.flickr.com/photos/57231735@N00/212544472/ http://www.flickr.com/photos/maniya/541287799/ http://www.flickr.com/photos/santos/1704875109/ http://www.flickr.com/photos/alphadesigner/354044811/ http://www.flickr.com/photos/roby72/553640207/ http://www.flickr.com/photos/smb_flickr/392254853/ http://www.flickr.com/photos/eatingchips/3345052094 http://www.flickr.com/photos/koluso/2808523989/ http://www.flickr.com/photos/lwr/60496147/ http://www.flickr.com/photos/razowsky/2630970947/ http://www.flickr.com/photos/crazyneighborlady/355232758/ http://www.flickr.com/photos/mwichary/2648035941/ http://www.flickr.com/photos/zanotti/304312092/

    + Rabble .Rabble ., 4 months ago

    custom

    1271 views, 11 favs, 0 embeds more stats

    Ever cringe when you're asked to enter your email a more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 1271
      • 1271 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 11
    • Downloads 38
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    more

    Groups / Events

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved