From Fedora Project Wiki

< FAD Infrastructure Security 2012

Revision as of 23:34, 1 November 2012 by Toshio (talk | contribs) (import from etherpad)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Primary FAD Deliverable:

  • Be able to require two-factor auth for sudo on fedora infrastructure boxes
    • on the box, sudo uses pam_url (or pam_otp or similar)
    • pam module takes in user input for both factors
    • pam module formats and sends to fas
    • fas processes information and sends back code for success/failure
    • pam module allows or denies sudo
  • FAS needs to do the following to auth:
    • URL that accepts username, password, token, "auth method" (or guess this from the token)
    • URL's controller compares username and password to db as normal login
    • URL's controller checks validity of username + token => need to look at how yubikey is integrated
    • If both of those are correct, URL's controller returns success
    • If either is incorrect, URL's controller returns failure
    • If there are errors (no 2nd factor, error contacting db, etc): return either an error or failure (what the protocol supports)
  • FAS needs to do the following for setup:
    • self enrollment page for the second factor (see how yubikey is implemented)
  • Meta FAS needs
  • Optional
    • Backup codes, change of factors:
      • Proposal: See Two Factor Authentication Policy
    • FAS requires 2 factor
    • Add totp/googleauth support
      • Need the following for auth
        • Setup totp-cgi on fas servers [[1]]
        • use the postgresql backend so that it can run on all of the fas* servers
        • have fas format the data and pass it to the totp-cgi backend to verify
      • Need the following for setup
        • self enrollment page (see how yubikey is implemented)

Two Factor Authentication Policy We have several ways we can authenticate you:

  • Something you know
    • password
    • access to email (password for the email account)
    • Security questions/answers
      • Could be possibly guessable
      • Could be stored in a place someone could copy them off
  • Something you have with caveats
    • ssh key
      • Usually lives on a computer but can be copied
      • Some may be a hw token, thus truly something you have
      • Hopefully protected by a password
    • gpg key
      • Usually lives on a computer but can be copied
      • Some may be a hw token, thus truly something you have
      • Hopefully protected by a password
    • googleauth key
      • Usually lives on a handheld device (phone/tablet) but can be copied
      • rooted phones can be accessed over the network like any other computer (?)
      • Keys themselves are not encrypted
  • Something you have
    • yubikey
    • openpgp card as a separate factor (Note: we don't have plans to support this yet but it may be the same as supporting googleauth)
      • If it is the same as googleauth, that also means we don't have a server-side method of telling the difference

For the purposes of Fedora Infrastructure, we decided that stealing a device or gaining root access on a device for the purposes of compromising your Fedora account were beyond the scope of what we were trying to prevent. We were


  • initial enroll:
    • self enrollment? [MUST]
    • give backup codes? [OPTIONAL]
  • day to day:
    • does fas require 2 factor when enabled? (I'd say yes if possible)
    • does group can require 2 factor?
  • lost token:
    • give codes? [DECISION]
    • require security question/manual intervention to reset? [DECISION][POLICY]
  • backends:
    • yubikey [MUST]
    • googleauth [OPTIONAL]
  • webapps:
    • can webapps do two factor? [OPTIONAL]
    • can hosted/trac do two factor? [OPTIONAL]
    • can nagios/direct pgsql stuff do two factor? [OPTIONAL]
  • requires on groups? [OPTIONAL][POLICY][DECISION]
    • can we have groups require 2 factor before you join?
    • what happens to people already in those if not 2 factored?
    • can users not in those groups enable 2 factor?
    • Note: currently removing a person from a group when that group is needed as a prerequisite for other things does no additional checking. This is arguably a bug
  • interface questions
    • can we scan in a qrcode for googleauth? [OPTIONAL]
    • do we need to change the yubikey burn script any?
    • do we want a seperate pin vs password. [DECISION][POLICY]

Enabling 2 factor for ssh

  • Could allow use for packagers/hosted groups
  • Would be painfull day to day potientially.
  • Would protect vs owned laptop issues.