The Yin-Yang of Web Authentication


Published on

Helping Developers building more secure web applications in regard to authentication

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Yin-Yang of Web Authentication

  1. 1. Codebits 2012The Yin-Yang of Web Authentication 16/11/12
  2. 2. Goal I  want  to  allow  people  to  comment  on  my  postsSAPO  Websecurity  Team 2
  3. 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  authSAPO  Websecurity  Team 3
  4. 4. Account Creation Account  Crea:on • Account create form • Store users in databaseSAPO  Websecurity  Team 4
  5. 5. Account Creation > MotivationSAPO  Websecurity  Team 5
  6. 6. Account Creation Building  BlocksSAPO  Websecurity  Team 6
  7. 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-­‐3SAPO  Websecurity  Team 7
  8. 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  IntegritySAPO  Websecurity  Team 8
  9. 9. Account Creation How  to  Store  Passwords?SAPO  Websecurity  Team 9
  10. 10. Account Creation > How to Store Passwords What’s  wrong  here? •  Repeated  hashes  =                      same  password  was  used •  trivial  to  crack  common  passwordsSAPO  Websecurity  Team 10
  11. 11. Account Creation > How to Store Passwords Most  Popular  Recommenda:on ...  but  is  it  enough? No!SAPO  Websecurity  Team 11
  12. 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. 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. 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. 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. 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. 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. 18. Account Creation > Preventing AbuseCAPTCHA: 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  CAPTCHASAPO  Websecurity  Team 18
  19. 19. Account Creation > Preventing AbuseRate-­‐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  violatedSAPO  Websecurity  Team 19
  20. 20. Authentication Authen:ca:on • Login form • Validate user and passSAPO  Websecurity  Team 20
  21. 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  disagreeSAPO  Websecurity  Team 21
  22. 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 SecuritySAPO  Websecurity  Team 22
  23. 23. Authentication > Protections Consider  2-­‐factor  authen:ca:onSAPO  Websecurity  Team 23
  24. 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  HmeSAPO  Websecurity  Team 24
  25. 25. Authentication > ProtectionsAn  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. 26. Session Management Session  Management • Create user’s sessionSAPO  Websecurity  Team 26
  27. 27. Session Management Building  BlocksSAPO  Websecurity  Team 27
  28. 28. Session Management > Generate a Random Number Motivation I  need  to  generate  a  Random  NumberSAPO  Websecurity  Team 28
  29. 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. 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  generatorSAPO  Websecurity  Team 30
  31. 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. 32. Session Management > Create a Random Token I  need  to  Create  a  TokenSAPO  Websecurity  Team 32
  33. 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. 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  =  1200SAPO  Websecurity  Team 34
  35. 35. Session Management > Best PracticesIf  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  hponly 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  outSAPO  Websecurity  Team 35
  36. 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:// Alice Bob opens  site  and   2 authenHcates Session  Fixa:on  A_ack Welcome  to 3 win Bob Welcome  to BobSAPO  Websecurity  Team 36
  37. 37. Password Recovery Password  Recovery • Recovery Pass form • Email token to userSAPO  Websecurity  Team 37
  38. 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. 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  tokenSAPO  Websecurity  Team 39
  40. 40. The End Ques:ons? Nuno  Loureiro  <> João  Poupino  <>SAPO  Websecurity  Team 40