lascon 2013 talk: user auth for winners, how to get it right the first time!

User Authentication for Winners!

Speaker:

Password:

Karthik Gaekwad

LASCON 2013

Remember this stuff when you code

@iteration1 #UserAuth101Friday, October 25, 13

Karthik Gaekwad

************

Remember this stuff when you code

Well played security guru; well played!

User Authentication for Winners!

Speaker:

Password:

@iteration1 #UserAuth101Friday, October 25, 13

Howdy!• I’m Karthik Gaekwad

• Senior Web Engineer

• Mentor Graphics Embedded

#UserAuth101@iteration1 LASCON 2013

• From Austin, TX

• Spent the last 3 years writing/refining cloud based user auth systems

Friday, October 25, 13


Audience Survey


My agenda• Developers and DevOps

• Build better auth systems

• Security Pro’s

• Give you developer insight, new ideas to attack auth systems

• Management

• Give this ppt to your dev teams.

#UserAuth101@iteration1 LASCON 2013Friday, October 25, 13

Authentication Mechanisms

• Write your own

• OpenID

• OAuth



Common Perception

“Building a User Authentication system is easy.

It’s just a username and password, stored somewhere”


API (PaaS)

Workflows

User Interface(s)

+

+


Reality


Designing Auth Systems

• Login/Logout

• Session Management (Remember Me etc)

• User Creation

• Password Reset


API: How your system is used



• Account Creation

• Password Reset

• Account Recovery


Workflows: Rules for how the system works



• Where users can create account

• Login screens

• My Profile Page

• End applications using the API’s


User Interface: What end user will actually see


High Level Design


Data store(s)

Email Web Services

API Web Services(Login/Logout)

App 1

App 2

User Portal

App 3...


Quick look @data

• email

• username

• first name

• last name

• password

• {id}


Quick look @dataKeep your auth data separate

• You don’t want to clutter your auth data with ecommerce/address/whatever other data

• Not rocket science.

• It’s called normalization


Breaking it down




Login Web Services


Keep user credentials as safe as possible in transit


The Goal:


Login Web Services


API Web Services(Login/Logout)App 1

POST /login

encodedusername:password

Request

Response

Session tokenSession Id expirationFirst name, Last name

HTTP 200/201


Login Web Services


API Web Services(Login/Logout)App 1

GET /login/(session token)

Request

ResponseHTTP 200/201 (success)

HTTP 401 (failures)

Session tokenSession Id expirationFirst name, Last name


Login Web Services

• Minimize sending username, passwords over the wire.

• Harder to sniff if it’s rarely there

• Don’t put this in the URL (server logs)

• Session tokens: Set an expiration time.

• Client can re-login if necessary


Login Web Services


HTTP?


“That’s great, but I can brute force the endpoint”

--JoeHacker


Rate Limiting• “Only x number of calls per minute to the

endpoint”

• Recommended for all login and session token endpoints.

• Can be complicated to implement, but worth it and reusable.

• http://www.client9.com/2012/05/01/rate-limiting-at-scale/ Thanks @NGalbreath!


http://www.client9.com/2012/05/01/rate-limiting-at-scale/




Note on Session Tokens


Use something cryptographically secure

Keep them 128bit or greater

How I really feel...

about rand() and guid() functions

Yuck


Login Hack #1

• Often, the end (web)application will store the username and session token in a cookie.

• Hack: Create 2 accounts, and login with both and store the cookies. Trade the session token of one account with the other, and see if you can see other account data...


Login Hack #1

• Developers have good intentions but....


Login Hack #2


• Verify that session tokens actually expire!

• Try using the same session token even after you’ve hit “log out” in the application.

• cookies.clear() is easier than actually calling the /logout endpoint to invalidate tokens.


Let’s move on..


Account CreationPassword Reset



"We try to solve very complicated problems without letting people know how complicated the problem was. That's the appropriate thing."



--Usability Jack and Jill



“Remembering passwords is a pain. Let’s make our system have a minimum 4 letter passwords because it’s more usable.”

--Usability Jack and Jill


Security + Usability

• The days of the 4 character password is over.

• UX team interactions:

• 8+ characters is accepted now

• Show by example

• Use “sentences” versus “words” for passwords


Security and Usability: Designing Secure Systems That People Can UseLorrie Faith Cranor


http://www.amazon.com/s/ref=ntt_athr_dp_sr_1?_encoding=UTF8&field-author=Lorrie%20Faith%20Cranor&search-alias=books&sort=relevancerank

http://www.amazon.com/s/ref=ntt_athr_dp_sr_1?_encoding=UTF8&field-author=Lorrie%20Faith%20Cranor&search-alias=books&sort=relevancerank

Account Creation

• Typically : accept user data, provision account...


Account Creation

• Sanitize inputs for XSS.

• If you are asking for user email, validate email actually belongs to the user.

• May have multiple data stores in play here.


Account Creation

• Case Sensitivity...

• Hack: Register with [email protected] and [email protected]. You may be able to register as both if the case sensitivity check isn’t turned on.

• Hack: Use foreign characters to sniff if the datastore is older (LDAP v2)


mailto:[email protected]




Passwords



“I'm gonna pop some tagsOnly got clear text passwords in my dbI - I - I'm hunting, looking for a reason

to get f*** fired.”

Storing Passwords

-The Macklemore stance



Storing Passwords

Please don’t go “thrift shop” your password storage


Storing Passwords

• Store only hashed passwords

• Use a unique, per user salt.

• use bcrypt/scrypt to generate your hash


“That’s great, but I’ll just figure out your

Cloud DB credentials”--JoeHacker


Storing Passwords• A technique that I like..

• Break up your data into different storesStore the password hash in data store #1

• Store the salt used to compute the hash in data store #2

• Store the # of hash iterations in data store #3 (application config?)

• Have the value stored in #1 not be the password hash itself, but a MAC (Message Authentication Code, aka 'keyed hash') using an application-private MAC key.

• http://www.stormpath.com/blog/strong-password-hashing-part-2 Thanks @Stormpath


http://www.stormpath.com/blog/strong-password-hashing-part-2




Storing Passwords• http://www.codinghorror.com/blog/2007/09/

youre-probably-storing-passwords-incorrectly.html

• http://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database

• http://www.stormpath.com/blog/strong-password-hashing-apache-shiro

• https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Authentication


http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html






http://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database




http://www.stormpath.com/blog/strong-password-hashing-apache-shiro




https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Authentication




Reset or Restore?

• I prefer Password Reset.

• “Personal challenge questions” aren’t so personal anymore with Facebook and Twitter.

• Make sure Password Reset tokens are one use only and expire “super fast”


Account Creation Workflow


Get User Credentials Validate Email

Create Password

Get User Credentials

and PasswordValidate Email Allow Login

OR


Account Creation Workflow

• Winner!

• Data to support that more users convert to creating accounts this way.

• http://www.stormpath.com/blog/how-we-increased-new-user-registration-27 Thanks @chunsaker


Get User Credentials

and PasswordValidate Email Allow Login


http://www.stormpath.com/blog/how-we-increased-new-user-registration-27




Final Thoughts

• AKA I have to present in a few hours, but I have no time to worry about flow.. #FreeStyling


Final Thoughts

• If you have many apps with login screens/ create account screens- keep these consistent.

• Users lose trust if login screens are different across apps by same company


Final Thoughts

• If you’re a Java shop, check out Apache Shiro Framework- it’s made for the authentication usecase.

• SaaS version: Stormpath


Final Thoughts

• 2 factor auth

• Definitely strengthens the security.

• Usability verdict is still out.

• Challenging to implement, but a good idea.


Final Thoughts

• Login Dashboards in “My Profile” with last login information, geo location, timestamp is more popular.

• You have all this data anyways, so why not show it?


PSA on OAuth


“Why does this random website need read and write OAuth access to my twitter / facebook account?”


Thank You for your time!

@iteration1

Lunch?

LASCON 2013 #UserAuth101Friday, October 25, 13

lascon 2013 talk: user auth for winners, how to get it right the first time!

Technology

login hack

user auth systems

login withboth

account data

auth systems api

account login screens

end user

auth systems user interface