Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Auth*: Dispelling the Myths

Auth*: Dispelling the Myths

There's a lot of bad practices and myths floating around about authentication and authorization these days. Using passwords just isn't good enough anymore. Come with me as I explore and dispel some of these common misconceptions and myths about these two important and often misunderstood topics. I'll talk about some of the most common techniques and look forward to tools and options that can help make your applications even more secure.

@ SkiPHP 2013

Chris Cornutt

January 18, 2014
Tweet

More Decks by Chris Cornutt

Other Decks in Technology

Transcript

  1. ...the act of confirming the truth of an attribute of

    a datum or entity [and] often involves verifying the validity of at least one form of identification. AUTHENTICATION source: wikipedia 4 Saturday, January 18, 2014
  2. Confirming identity A satisfactory “yes” or “no” Impossible...in theory What

    about anonymous? no, not *that* Anonymous... AND... 5 Saturday, January 18, 2014
  3. ...is the function of specifying access rights to resources, which

    is related to information security and computer security in general and access control in particular. AUTHORIZATION source: wikipedia 8 Saturday, January 18, 2014
  4. Principle of Least Privilege Coarse vs fine-grained Think “rule” not

    “role” AND... 9 Saturday, January 18, 2014
  5. TYPES Access control lists (ACL) Role-based access control (RBAC) Attribute-based

    control Policy enforcement Discretionary controls Mandatory controls 10 Saturday, January 18, 2014
  6. SILVER BULLETS Not a “cure all” Yet another hoop Different

    implementations Hardware versus Software 12 Saturday, January 18, 2014
  7. IT’S GOOD AT... Being a backup method, not a replacement

    Increasing confidence in users Helps with compliance 13 Saturday, January 18, 2014
  8. IT’S NOT GOOD AT... Being the only method Preventing out-of-band

    attacks Stopping other attacks (ex. SQLi on login) Preventing provider (IdP) issues 14 Saturday, January 18, 2014
  9. PASSWORD BALL & CHAIN Ancient origins Just feels ancient today

    New app? Use a password? Password policies 16 Saturday, January 18, 2014
  10. WHY PASSWORDS SUCK Shared across services Restrictive policies Too much

    work on “getting it right” Users are no good at them Cracking hardware is cheap 17 Saturday, January 18, 2014
  11. PASSWORD CRACKING Offline attack Dictionary/guessing Brute force Key casting Cloud

    services ....and password policies 19 Saturday, January 18, 2014
  12. PASSWORD POLICIES Number/Lower/Upper/Special Reduce repeated characters Length > Complexity Use

    slow algorithm Salt and hash (at the least) 22 Saturday, January 18, 2014
  13. INTERNAL More control More traditional options Easier to customize Hardware

    costs/infrastructure Too many tools Less stringent on encryption 27 Saturday, January 18, 2014
  14. EXTERNAL Standardized auth methods Agility & flexibility Cost savings High

    encryption/protection Less “control” Limited to provider options 28 Saturday, January 18, 2014
  15. OWASP Top 10 A2: Broken Auth/Session Management A4: Insecure Object

    References A6: Sensitive Data Exposure http://bit.ly/owasptop10-2013 32 Saturday, January 18, 2014
  16. Bad Practices Sending plain-text passwords Sensitive data in the URL

    Informative error messages No throttling on resets or registrations or password failures 33 Saturday, January 18, 2014
  17. Audit of current components Gather usage data Plan, plan then

    plan some more Easier in hindsight REALIGNMENT 40 Saturday, January 18, 2014
  18. Think “Subject” not “User” Narrowing the options Pick the right

    fit, not the shiny one Plan for delegation LOOK AHEAD 41 Saturday, January 18, 2014
  19. More than one level? What to protect? Is it the

    same everywhere? Policies/procedures Reduce the overhead IN DEPTH 42 Saturday, January 18, 2014