The Yin-Yang of Web Authentication

Codebits 2012The Yin-Yang of Web Authentication

16/11/12

SAPO Websecurity Team

Goal

2

I want to allow people to comment on my posts


Summary

3

Timeline

Blog

Blogs v2:add user comments

needs auth

create account

• passwd storage• choosing pwd• captcha• bruteforce

login

• hDps• bruteforce• guidelines

Session Mgmt

• hDps• bruteforce• session fixaHon• guidelines

Pwd recovery

• token storage• validaHon•bruteforce


Account Creation

4

Account Crea:on

• Account create form• Store users in database


Account Creation > Motivation

5


Account Creation

6

Building Blocks


Account Creation > Building Blocks

7

Message Digests (Hashes)

• Generate a fixed-‐length hash based on arbitrary length input• Examples: MD5, SHA-‐1, SHA-‐256, SHA-‐512, SHA-‐3

SAPO Websecurity Team 8

HMAC (Hash func-on)

• Hash-‐based Message AuthenHcaHon Code uses a shared secret to authenHcate the message

• Provides AuthenHcity and Integrity

HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m))opad = 0x5c5c5c..5cipad = 0x363636..36

(to have a large hamming distance)

Account Creation > Building Blocks


Account Creation

9

How to Store Passwords?


What’s wrong here?

• Repeated hashes = same password was used

• trivial to crack common passwords

Account Creation > How to Store Passwords


Most Popular Recommenda:on

... but is it enough?

No!



• You should not store passwords, but a cryptographic hash (HMAC) of the password.• Use a 4-‐byte salt to make rainbow table a<acks more difficult

Local Accounts:

• If the service you’re trying to connect to doesn’t provide OAuth you should encrypt the credenHals before storing them (using AES)

Side Note -‐ for remote accounts:


• By using an HMAC your users will be safer in case there’s a password leak, because the a<acker first needs to crack the HMAC secret key.


Choosing Passwords

comprehensive8: at least 8 chars, 1 upper, 1 lower, 1 digit, 1 symbol and not belong to a dicHonary word

basic16: at least 16 chars, no other rules

Account Creation > Choosing Passwords

* Kelley, Patrick Gage, et al. "Guess again (and again and again): Measuring password strength by simulating password-cracking algorithms." Security and Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012.


Choosing Passwords

* Komanduri, Saranga, et al. "Of passwords and people: measuring the effect of password-composition policies." Proceedings of the 2011 annual conference on Human factors in computing systems. ACM, 2011.

comprehensive8: at least 8 chars, 1 upper, 1 lower, 1 digit, 1 symbol and not belong to a dicHonary word

basic16: at least 16 chars, no other rules



Passwords MetersAccount Creation > Choosing Passwords

Conclusion: At the end users have stronger passwords. The type of password meter you choose makes liDle difference.

* Ur, Blase, et al. "How does your password measure up? The effect of strength meters on password creation." Proc. USENIX Security. 2012.


• Password Sharing: 73% of users share passwords that are used for online banking with at least one non-‐financial website.• Username / Password Sharing: 42% of users share both their username and password with at least one non-‐financial website

in Reusing Login Creden.als, Security Advisor, February 2010, Trusteer Inc.Study on 4M PCs



• If you don’t follow these guidelines you are contribu-ng to users’ insecurity.

• Most users reuse username & password across different sites: leak one, compromisse all

• Huge poten-al a<ack: larger leaks, larger problems

• Access to personal informa-on that may be helpful in other sites. Remember the Apple/Amazon/Google/Twi<er dude hack.

Account leaks



CAPTCHA:

Completely Automated Public Turing tests to tell Computers and Humans Apart

CAPTCHAs have limitaHons and can be bypassed:• using OCR (OpHcal Character RecogniHon)• paying someone to solve the CAPTCHA

Account Creation > Preventing Abuse


Rate-‐limi:ng:Used to control the rate of specific requests accepted by a service. It’s also called throDling.

Use rate-‐limiHng to limit the:

• number of accounts created by IP in a given Hme period• number of accounts created by IPs from Russia in a given Hme period• number of blog comments by IP in a given Hme period

When implemenHng your own rate-‐limiHng follow these guidelines:

• Define the rate-‐limiHng rules (e.g. 3 new accounts every 30 min by IP)• Keep track of relevant events (e.g. counter of number of accounts by IP)• Before authorizing the operaHon, check if the rule was violated

Account Creation > Preventing Abuse


Authentication

20

Authen:ca:on

• Login form• Validate user and pass


Authentication > Best Practices

21

1. All password fields must not echo the user’s password when it is entered

2. All authen-ca-on controls must be enforced on the server side

3. It should use HTTPS and HSTS

4. AXer a maximum number of authen-ca-on a<empts is exceeded, the account should be locked for a period long enough to deter brute force a<acks

5. Re-‐authen-ca-on should be required before any applica-on-‐specific sensi-ve opera-ons are permi<ed, such as for changing the password

6. All authen-ca-on decisions must be logged

7. Authen-ca-on process, par-cularly login failures, should provide no specific informa-on as to if an account exists or password is wrong. A single error message for the end user covering both scenarios is more than adequate

8. Applica-ons may have the facility to no-fy the user of their last logged in -me and loca-on, and subsequently report a fraudulent login if they disagree


Authentication > Best Practices

22

Strict-Transport-Security: max-age=60000; includeSubDomains

HTTPS

Problem?1st request when you don’t specify the protocol

Solu:on?HSTS -‐ HTTP Strict Transport Security


Authentication > Protections

23

Consider 2-‐factor authen:ca:on


• VerHcal -‐ fixed username, different password

• Horizontal -‐ fixed password, different username

• Diagonal -‐ different username & password

• Three dimensional -‐ V/H/D & different IP

• Four dimensional -‐ 3D & spaced requests

• CredenHal (cookie) -‐ username & password independent

• Timing -‐ based on response Hme

Types of Brute Force



• After X failed authentication attempts show CAPTCHA• After Y failed authentication attempts block authentication for 2N-‐2 seconds and show CAPTCHA• N is reset after T hours or after a successful login for the pair IP/username

• After a successful authentication, the service should send a cookie (token) to the user.

• The state should be stored server-‐side and should indicate pairs of IP/Accounts that should be whitelisted for the rules above. This cookie should expire after 1 month.

An example of Authen:ca:on brute-‐force preven:on



Session Management

26

Session Management

• Create user’s session


Building Blocks

Session Management


I need to generate a Random Number

© 2005-09 Miguel Correia. All rights reserved. Reproduction only by permission.

9 Randomness and Cryptography

Secure Software SystemsMiguel Correia

Universidade de Lisboa / Carnegie Mellon UniversityMSc in Information Technology - Information Security

© 2005-09 Miguel Correia. All rights reserved. Reproduction only by permission.

Motivation

Session Management > Generate a Random Number



29

• When you need to use a random number for security purposes, it is important to use a cryptographically strong PRNG (Pseudo-‐Random Number Generator)

• Why? Because you need the generated random number to be unpredictable

• Usual PRNG implementaHons are based on linear congruenHal generators (LCG) (e.g. Xn+1=[aXn+b]mod c ), which do not provide unpredictable values.

Unix’s rand():sta.c unsigned long int next = 1;int rand(void) // RAND_MAX assumed to be 32767}

next = next * 1103515245 + 12345;return (unsigned int)(next/65536) % 32768;

{


1. Generates evenly distributed numbers (uniform distribuHon)2. Values are unpredictable3. Has a long and complete cycle

A good PRNG has three properHes:

A cryptographically strong PRNG is one that besides saHsfying the three properHes menHoned above uses a mixing funcHon to remove bias (e.g. SHA-‐1 )

Examples: Windows’ CryptGenRandom and Java’s SecureRandom() feed entropy to the generator



• fine-‐grained Hmings between key presses• fine-‐grained Hmings and posiHons of mouse movements• fine-‐grained Hmings between interrupts and related events (e.g.

packets arriving to a network card, data arriving from a disk controller)• fine-‐grained Hmings at which successive threads are scheduled on to

the processor• CPU/system temperature monitor readings• Ticks since boot• low-‐order bits of the amount of free memory• details on files that are liable to change frequently• noise from a microphone input• (... long list)

Common sources of entropy in computers:



I need to Create a Token

Session Management > Create a Random Token


• they need to be unique• they need to be unpredictable• they need to be secret to third parHes (e.g. using HTTPS for comm.)

You need to create a token to idenHfy the users on your site, i.e., to create a session for the user

What are the main properHes that these tokens need to provide?

You can create unique and unpredictable tokens by using a cryptographic hash funcHon, such as SHA-‐256, using a good source of entropy, such as a cryptographically strong PRNG.



Bad Example:

Is this a good Token for Session Management? No. Why?

$session_token = hash(“sha256”, .me() . $_SERVER[“REMOTE_ADDR”]);

• SHA-‐256 returns 256 bits of output. That’s 2^256 combina:ons!• But the input is based on a unix :mestamp and an IP address• current Hmestamp needs 31 bits• IP address = 32 bits• 31 bits + 32 bits = 63 bits < 256 bits• But to hijack a session that is happening now, you can limit the Hmestamp

to a range of 10 minutes, i.e., 600 possible combina:ons• If you want to hijack a targeted session, such as from someone that is

using a company’s network, you know that usually there are only 1 or 2 possible public IP addresses (those of proxy servers)

• So the total number of combinaHons you need to try is 600*2 = 1200



Session Management > Best Practices

35

1. The session id must never be disclosed other than in cookie header

2. The session cookie should have the domain and path set to a restric-ve value

3. The session cookie should be set as secure and h'ponly

4. Use the prog. language na-ve session management func-ons. If not, you must ensure that session ids are sufficiently long (>160bits) unique and unpredictable

5. The session id must change on login

6. The session id must change on re-‐authen-ca-on

7. The session id should change or clear on logout

8. Sessions should -meout aXer a specified period of inac-vity

9. Sessions must -meout aXer an absolute -meout

10.Sessions (content) must be invalidated when the user logs out

If you need user sessions in your applicaHon you should use the programming language’s naHve session management module, which typically deals with most of the security concerns. However, there are certain rules that you should follow:


Session Management > Preventing Session Fixation

36

5. The session id must change on login

6. The session id must change on re-‐authen-ca-on

sends hDp://www.example.com/?Sessionid=123456789Alice Bob

opens site and authenHcates

Welcome to example.comBob

Welcome to example.comBob

win

1

2

3

Session Fixa:on A_ack


Password Recovery

Password Recovery

• Recovery Pass form• Email token to user


Password Recovery > Best Practices

38

1. You can use an out of bound channel, such as an SMS with a validaHon code sent to the user’s mobile, which number was entered during the registraHon process

2. An email with a token sent to the user’s email address, entered at registraHon Hme

Users will eventually forget their passwords, so your applicaHon needs a safe password recovery method:

You can mix both methods for services that are more (e.g. an email with a link is sent to the user and when the user clicks the link he/she gets a page with a field to enter the validaHon code that was sent to his/her mobile phone). You can also require both methods if the user has successfully logged-‐in in the past 24h and require only one if he/she hasn’t.


Password Recovery > Best Practices

39

• When valida-ng the user’s email address or mobile phone number during the registra-on process make sure the user is authen-cated

• Never store the valida:on code or token in clear. Use the same method you used to store passwords

• Use rate-‐limi-ng to prevent abuse

• While a token is valid resend it if the user requests another recovery token

(...)


The End

40

Ques:ons?

Nuno Loureiro <[email protected]> João Poupino <[email protected]>

The Yin-Yang of Web Authentication

Technology

Transcript of The Yin-Yang of Web Authentication