User:Puiterwijk/2factor policy proposal

From FedoraProject

< User:Puiterwijk(Difference between revisions)
Jump to: navigation, search
(Added level 0)
Line 23: Line 23:
  
 
: 0. User identified by using a password that is transmitted over a non-secure line
 
: 0. User identified by using a password that is transmitted over a non-secure line
: 1. User identified by using a password encrypted through a challenge-response and is transmitted over a non-secure line
+
: 1. User identified by using a password that is encrypted(*) client-side and is transmitted over a non-secure line
 
: 2. User identified by using a password that is transmitted over a secure line
 
: 2. User identified by using a password that is transmitted over a secure line
 
: 3. User identified by using a password that is transmitted over a secure line and a One Time Password generated by either a software or hardware token
 
: 3. User identified by using a password that is transmitted over a secure line and a One Time Password generated by either a software or hardware token
 
: 4. User identified by using a password that is transmitted over a secure line and a One Time Password generated by a hardware token that is FIPS 140-2 Level 2 compliant
 
: 4. User identified by using a password that is transmitted over a secure line and a One Time Password generated by a hardware token that is FIPS 140-2 Level 2 compliant
 +
 +
(*) Encryption is done with a challenge-response system
  
 
==Current status==
 
==Current status==

Revision as of 14:27, 24 January 2013

Contents

Purpose

In a recent IRC conversation with Toshio (abadger1999 on IRC), it was agreed that we need some policy for the usage of two-factor authentication in FAS (yubikey, google OTP, ...).

Current status

At this moment, users are able to setup a yubikey, and use that for a password in many services, or just enter their current password. FAS just checks if the password is the user's password, and if it's not, if it's a valid OTP generated by the user's yubikey. There is no special box for yubikey or any special handling of it other then explained above.

Reason this should change

At this moment, we have a second factor authentication token, but we do not use it as a second factor: it could be used as a replacement for the user's password for a lot of services, but not as a second factor to increase the trust level we have in the authenticity of the user, you may now login with either something you know OR something you have.

This might even lower the security level, as the "something you have" could easily be stolen, and there's no protection built into a yubikey to preven other people from using it.

Suggested changes

The change I suggest is to make FAS no longer accept a yubikey OTP as the user's password, but using a different field for that. I will go into policy in a later section.

Recent developments that might impact this

A new OpenID provider implementation is currently being written (FAS-OpenID) which is an OpenID 1.0/1.1/2.0 compliant provider which authenticates users with FAS.

FAS-OpenID provides the simple "Provider Authentication Policy Extension" (PAPE). With the PAPE, an OpenID Consumer is able to request the level of trust the OpenID provider has in the identity of the user, with the available levels and their requirements being:

0. User identified by using a password that is transmitted over a non-secure line
1. User identified by using a password that is encrypted(*) client-side and is transmitted over a non-secure line
2. User identified by using a password that is transmitted over a secure line
3. User identified by using a password that is transmitted over a secure line and a One Time Password generated by either a software or hardware token
4. User identified by using a password that is transmitted over a secure line and a One Time Password generated by a hardware token that is FIPS 140-2 Level 2 compliant

(*) Encryption is done with a challenge-response system

Current status

At this moment, FAS-OpenID is able to provide level 2 of trust, because we use either a password or an One Time Password generated by a token, but not both, which is the requirement of level 3 and 4. Level 4 will not yet be possible for us to assert, as YubiKey is not (yet) FIPS 140-2 compliant (source: http://www.yubico.com/products/security/).

Future ideas

At this moment, all Fedora web applications authenticate the users directly against the Fedora Account System. An idea that was suggested was to make all applications use OpenID through FAS-OpenID to authenticate users, so they won't need direct communication to the FAS database anymore, and we only have one point to change things like login process. At that moment, we could also assign a required security level to specific applications, which FAS-OpenID will assert.

Suggested changes (continued)

As I mentioned, I suggest to make FAS disallow a yubikey OTP as password. I would also suggest adding a new checkbox in FAS after adding a yubikey, by which the user can indicate that he wants to require usage of the yubikey before being able to use the Fedora Account System for account modifications. This checkbox would only be available once the user has completed the following two steps:

  • Add and verify a yubikey (we might make the box only respond if the user provides a valid yubikey OTP at the same time so we know that it works)
  • Add a secret question and answer to his user account, to make sure that he is able to prove he is the account owner in the case something goes wrong with his yubikey

If the user would enable this checkbox, the next times he logs in to FAS with his username/password, there will be an intermediate step which requests him to use his yubikey to verify his identity. Also, after I suggest to add another checkbox where the user can require his yubikey to be used always with his Fedora account, so also when logging in to other applications or using the OpenID provider. Applications would be able to override this in the sense that they can require this level of authentication, regardless if the user has enabled this globally. In case the user is required to enter a yubikey OTP, he will be asked to do so after he has logged in to FAS-OpenID with his username/password, by adding a new intermediate screen which requests for the yubikey OTP.

Author

The author of this proposal is Patrick Uiterwijk (puiterwijk)

Discussion

For discussion, you can come to #fedora-admin, or use the Talk page in this wiki.