Helping Developers building more secure web applications in regard to authentication

1. Codebits 2012
The Yin-Yang of Web Authentication
16/11/12

2. Goal
I
want
to
allow
people
to
comment
on
my
posts
SAPO
Websecurity
Team 2

3. Summary
Blog create
account login Session
Mgmt Pwd
recovery
Timeline
Blogs
v2:
• passwd
storage • hDps • hDps • token
storage
add
user
• choosing
pwd • bruteforce • bruteforce • validaHon
comments
• captcha • guidelines • session
fixaHon • bruteforce
• bruteforce • guidelines
needs
auth
SAPO
Websecurity
Team 3

4. Account Creation
Account
Crea:on
• Account create form
• Store users in database
SAPO
Websecurity
Team 4

5. Account Creation > Motivation
SAPO
Websecurity
Team 5

6. Account Creation
Building
Blocks
SAPO
Websecurity
Team 6

7. Account Creation > Building Blocks
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 7

8. Account Creation > Building Blocks
HMAC
(Hash
func-on)
HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m))
opad
=
0x5c5c5c..5c
ipad
=
0x363636..36
(to
have
a
large
hamming
distance)
• Hash-­‐based
Message
AuthenHcaHon
Code
uses
a
shared
secret
to
authenHcate
the
message
• Provides
AuthenHcity
and
Integrity
SAPO
Websecurity
Team 8

9. Account Creation
How
to
Store
Passwords?
SAPO
Websecurity
Team 9

10. Account Creation > How to Store Passwords
What’s
wrong
here?
•
Repeated
hashes
=
same
password
was
used
•
trivial
to
crack
common
passwords
SAPO
Websecurity
Team 10

11. Account Creation > How to Store Passwords
Most
Popular
Recommenda:on
...
but
is
it
enough?
No!
SAPO
Websecurity
Team 11

12. Account Creation > How to Store Passwords
Local
Accounts:
• 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
• 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.
Side
Note
-­‐
for
remote
accounts:
• If
the
service
you’re
trying
to
connect
to
doesn’t
provide
OAuth
you
should
encrypt
the
credenHals
before
storing
them
(using
AES)
SAPO
Websecurity
Team 12

13. Account Creation > Choosing Passwords
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
* 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.
SAPO
Websecurity
Team 13

14. Account Creation > Choosing Passwords
Choosing
Passwords
comprehensive8:
at
least
8
basic16:
at
least
16
chars,
no
chars,
1
upper,
1
lower,
1
digit,
other
rules
1
symbol
and
not
belong
to
a
dicHonary
word
* 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.
SAPO
Websecurity
Team 14

15. Account Creation > Choosing Passwords
Passwords
Meters
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.
SAPO
Websecurity
Team 15

16. Account Creation > Choosing Passwords
•
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
Study
on
4M
PCs in
Reusing
Login
Creden.als,
Security
Advisor,
February
2010,
Trusteer
Inc.
SAPO
Websecurity
Team 16

17. Account Creation > Choosing Passwords
Account
leaks
• 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.
SAPO
Websecurity
Team 17

18. Account Creation > Preventing Abuse
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
SAPO
Websecurity
Team 18

19. 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
SAPO
Websecurity
Team 19

20. Authentication
Authen:ca:on
• Login form
• Validate user and pass
SAPO
Websecurity
Team 20

21. Authentication > Best Practices
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
SAPO
Websecurity
Team 21

22. Authentication > Best Practices
HTTPS
Problem?
1st
request
when
you
don’t
specify
the
protocol
Solu:on?
HSTS
-­‐
HTTP
Strict
Transport
Strict-Transport-Security: max-age=60000; includeSubDomains
Security
SAPO
Websecurity
Team 22

23. Authentication > Protections
Consider
2-­‐factor
authen:ca:on
SAPO
Websecurity
Team 23

24. Authentication > Protections
Types
of
Brute
Force
• 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
SAPO
Websecurity
Team 24

25. Authentication > Protections
An
example
of
Authen:ca:on
brute-­‐force
preven:on
•
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.
SAPO
Websecurity
Team 25

26. Session Management
Session
Management
• Create user’s session
SAPO
Websecurity
Team 26

27. Session Management
Building
Blocks
SAPO
Websecurity
Team 27

28. Session Management > Generate a Random Number
Motivation
I
need
to
generate
a
Random
Number
SAPO
Websecurity
Team 28

29. Session Management > Generate a Random Number
• 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;
{
SAPO
Websecurity
Team 29

30. Session Management > Generate a Random Number
A
good
PRNG
has
three
properHes:
1. Generates
evenly
distributed
numbers
(uniform
distribuHon)
2. Values
are
unpredictable
3. Has
a
long
and
complete
cycle
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
SAPO
Websecurity
Team 30

31. Session Management > Generate a Random Number
Common
sources
of
entropy
in
computers:
• 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)
SAPO
Websecurity
Team 31

32. Session Management > Create a Random Token
I
need
to
Create
a
Token
SAPO
Websecurity
Team 32

33. Session Management > Create a Random Token
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?
• 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
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.
SAPO
Websecurity
Team 33

34. Session Management > Create a Random Token
Bad
Example:
$session_token
=
hash(“sha256”,
.me()
.
$_SERVER[“REMOTE_ADDR”]);
Is
this
a
good
Token
for
Session
Management?
No.
Why?
• 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
SAPO
Websecurity
Team 34

35. Session Management > Best Practices
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:
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
SAPO
Websecurity
Team 35

36. Session Management > Preventing Session Fixation
5. The
session
id
must
change
on
login
6. The
session
id
must
change
on
re-­‐authen-ca-on
1 sends
hDp://www.example.com/?Sessionid=123456789
Alice Bob
opens
site
and
2 authenHcates
Session
Fixa:on
A_ack Welcome
to
example.com
3 win
Bob
Welcome
to
example.com
Bob
SAPO
Websecurity
Team 36

37. Password Recovery
Password
Recovery
• Recovery Pass form
• Email token to user
SAPO
Websecurity
Team 37

38. Password Recovery > Best Practices
Users
will
eventually
forget
their
passwords,
so
your
applicaHon
needs
a
safe
password
recovery
method:
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
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.
SAPO
Websecurity
Team 38

39. Password Recovery > Best Practices
(...)
• 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
SAPO
Websecurity
Team 39

40. The End
Ques:ons?
Nuno
Loureiro
<nuno@co.sapo.pt> João
Poupino
<joao.poupino@co.sapo.pt>
SAPO
Websecurity
Team 40