Lets say there are some factors which require user setup, eg totp or duo. And there are other factors which don't require user intervention like iprange.

Now lets say they login, on a secure network, so they come through fine. But if they were not on a secure network they would be locked out completely. So they need to be alerted to setup the factors to allow them to login from outside the network, but in a generic way regardles of the factors involved.

So lets say there are 4 factors enabled, each with 50 points, and 2 require setup. So we have 100 points of 'no setup' factors and 100 points of 'setup required' factors.

So when you are logged in, regardless of how you logged in, check how factors they have setup, and if the total of those is less than 100 then warn them and punt them off to the user prefs page.

The most typical setup for this would be iprange = 100 + totp = 100

Now when it does actually warn you, it should build up the warning text based on the non-setup factors, eg if the first factor is iprange, then it should say 'If you are not on a trusted network' then you won't be allowed to login without additional factors setup. This will depend on lot of the weightings and the ordering of factors, so we can side step a lot of the complexity with careful language, eg 'you need additional factors' rather than 'you need 2 more factors' - because we don't know which combinations are enough yet, so you just prompt them to add one, and then re-check, and then maybe add more.

This might share some code with a 'recent devices' factor:

#15

Broadly we'd record some sort of fingerprint for a device, maybe a long lived cookie, + the user agent, and possible also combined with a ip address, and allow people to trust it.

The admins might be able to say things like only allow people to trust devices on a certain network.

After clicking on Cancel button $form->is_cancelled() returns false and $form->is_submitted() returns true.
This makes Cancel button unworkable.

If you have been logged in on this device before then that counts for something rather than being on a completely unknown device.

This could work by storing and comparing moodle old session id's or previous ip addresses or some combination.

We probably need a after_login method for factors as we only want to store things when we know we've gotten all the way through MFA. And in this method for this factor we'd store the new ip or session cookie value ourselves in user prefs and manage it directly.

There will be 2 settings in the MFA setup: a grace mode, and a grace duration

These are all what affects what happens when you attempt to login, but do not have any factors setup.

Grade mode:

• optional, it's just on your preferences page but no prompts

MFA is totally optional, if you choose to set it up, and only if you have set it up, will you account then be required to use MFA to login.

This is almost the same as just being off. This needs some thought around how to handle and detect when you've cancelled a totp input request for example.

• suggested, when you login add a notification

When you login, a notification will be added to your session. So when you end up at your wants url you'll get an info box saying 'please add mfa' with a link

• enforced, when you login you redirect to the setup page won't do

If you attempt to go to any other page you MUST be either served a redirect back to the setup page OR you will be served an error page for situations where you'd end up in a redirect loop.

• graceful, same as above but can be dismissed, but only for a certain period eg 2 weeks. Nice workaround so if you must login for say an exam you can get the job done and come back to it

• each plugin needs a method to say whether an instance can be added. For some plugins like iprange this will always return false
• for this plugin it will change depending on how many active devices you have and this new setting

• Make a new account preferences page:

https://github.com/catalyst/moodle-tool_securityquestions/blob/master/lib.php#L34

• have ability to revoke each factor, which just disabled it so we have an audit trail

• Each setup should have details of the ip it was created from, the time, and a name. It should also show the last time it was used.

Make sure this work with a wants url set from the login process so don't overwrite it

A test scenario:

• deep link to a course

• login, and purposefully get the password wrong once or twice then login

• test in grace mode, should go to preferences page, do some stuff, then at the end you should see a 'go to URL' link at the bottom of your settings

• Rinse and repeat, but in login mode when you have mfa setup, test it with say 2 factors requiring input, or test it and get the verification wrong a couple times and then right

• has_setup() = false
• is_ready() = do they have an email, and validate_email() + over_bounce_threshold()
• login flow, sends as email with a code, you copy the code into the login form.
• the email also ha the ip address and UA and anything else handy that might help identify the malicious user
• would usually be very low priority, eg last in the list
• the email should also have a 'This wasn't me' link. The one upside of this approach is that even if your email was compromised you might still see the email. If you do then you can click on the link and it will:
  • work even if you yourself are not logged in (ie you were just doing something else and saw it, it's obviously not you, you need to mitigate it ASAP, and your moodle account may be compromised so you can't actually log in anyway)
  • invalidate the code so the malicious person can't use it
  • even if they had used that code and logged in, when you click that link it will log them out remotely.
  • log an event with details of the ip address, browser UA and anything else
  • perhaps suspend your account until you can look into it more (needs an option for this)

This still isn't perfect as the person checking your email could also delete the email.

To cleanly do this, a factor can also return a state of 'hard fail' in addition to either a 'yes' (ie yes I'm in the ip range), a no (I'm not in the ip range but thats ok). If any factor returns a fail then the login flow is instantly over.

• render a big chunky form which has just the 6 digit codes nice and big
• auto focus the form
• if you have entered 6 digits then immediately fire off an ajax request to test it, if it is good then redirect right away. If not mark it as red

I noticed a GA app bug/feature.
It silently overwrites existing account if you feed it by a new one with the same name.

ie when you generate qrcode using first secret code with a uri like this:
'otpauth://totp/mike:[email protected]?secret=FIRSTSECRETCODE&issuer=Moodle'
GA app creates an account with name "Moodle (mike:[email protected])". Then we store factor with FIRSTSECRETCODE in db.

When you decide to add one more factor you click Add totp factor we draw a new qr code with new secret code with uri like this:
'otpauth://totp/mike:[email protected]?secret=SECONDSECRETCODE&issuer=Moodle'

If you scan this qr code with a new device - GA app will just create an account "Moodle (mike:[email protected])" as usual.

However, if you (intentionally or unintentionally) scan it with you first device that already has this account,
GA app will silently overwrites the first one.

So, finally, you will have only one "Moodle (mike:[email protected])" account on your device. Second one.
And the first one will be permanently lost.

Pobably it's not critical, but we will have active orphaned totp factor in user profile that is never used again.

Most admin settings should be logged for free, just check for all calls to set_config which don't do through the admin UI

https://medium.com/crypto-punks/why-you-shouldnt-scan-two-factor-authentication-qr-codes-e2a44876a524

tl;dr: If your phone is compromised a hacker now knows your username, and the domain, and the totp key and only lacks the password. By removing the domain, username, or both from the qr code it's less info on the device. I think this is relatively low because if your device is both lost AND compromised, then they'll likely have your email password and various other things too. If you lose your device you just want to revoke the totp codes asap.

$subplugins = (array) json_decode(file_get_contents("{$modulepath}/db/subplugins.json"))->plugintypes

this avoids the debugging calls

• Disabling is the same as revoking, so we don't need both.
• Revoking should not delete anything so we have a full audit history of what factors where in play

• usual up and down arrows that other plugin types have like auth

eg you can only set a new TOPT on the cat network the first time you set it up.

• have admin setting , there is an ip range

address_in_subnet(getremoteaddr()

remoteip_in_list()

• unknown, we have not tested it yet (which may require doing something like sending an email, and may alsy require checking something like veryfiny a token)
• pass - verified
• neutral - not verified - generally a no result is not negative, you simply may not have your phone
• bad - positive information that something bad is going on. eg you got an email saying please confirm this code, when it wasn't you. You can click a link saying 'nope it wasn't me!' see #12
• need a set_state() too

Touch points:

https://github.com/catalyst/moodle-tool_mfa/blob/master/lib.php#L165-L166

https://github.com/catalyst/moodle-tool_mfa/blob/master/auth.php#L72-L77

Comparison to googles and githubs setup

• when this is loaded or saved show a summary table which lists the conditions based on the scores and priority.
• have help text which says you probably want the factors with the highest score listed first.

eg if you require a score of 100 and you have:

auth,saml => 100
iprange => 100
totp => 100

The it will show:

You must be:
* logged in via saml
OR
* on a secure network
OR
* use TOTP

If you then change the 3 scores to 50 then it would say:

You must be:
* logged in via saml AND on a secure network
OR
* logged in via saml AND use TOTP
OR
* on a secure network AND use TOTP

ie if you are an admin logged in as someone else then you should be able to do some things, like revoke a key, but you should not be able to setup a new key. Needs some thought here

• first you can't actually login at all if they have totp setup (it's kinda doing it's job!). Business decision around bypassing this?? Another setting?

Possibly related to being in an upgrade cycle loop

• refactor all the factors to use the same db table
• maybe swap from a db record to an object, but I think the db is actually the bigger win here and paves the way for the reporting in #2

This is the reverse case of: #54

Lets say we have a hard line policy of iprange OR totp and no grace. So you must login on a secure network, setup totp, to enable use in the wild.

Lets say a user doesn't do that, they are outside, they will just be denied access. Now we could just have a generic 'you don't have enough factors' message, but it's not that great. We could allow it to be overridden, and thats ok but it's extra work.

Instead we should generate a 'possibly way to login' if one exists. ie lets assume they have 0 points of 'needs setup' factors, but there is 100 points of 'no setup' factors. Then it should say 'if you want to login, you need to be on a secure network, and then you can setup MFA'

Maybe we can structure it so we can use the same chunks of language for both use cases (but might get awkward quickly)

https://github.com/catalyst/moodle-tool_mfa/blob/master/classes/local/form/preferences_form.php#L95-L98

The last modified date probably has little value in it's own right as most factors don't really have a meaningful 'edit' concept'. So I'd just reuse this field and update the record every time it is validated.

When editing a totp record for the purposes of renaming a device, it probably makes sense to enforce them reconfirming the code for that specific device too, so the last mod field is serving double duty without needing two fields.

Possibly way down the track, and probably lowish value, but the api's have a lot in common and we could potentially leverage any existing availability condition / plugin

https://docs.moodle.org/dev/Availability_conditions

https://moodle.org/plugins/browse.php?list=category&id=57

For example leverage whether you are in the Moodle app or not:

https://moodle.org/plugins/availability_mobileapp

Of the various push notification based services out there this seems like one with a lot of traction and an easy api

https://duo.com/product/trusted-users/two-factor-authentication/authentication-methods/duo-push

also free for 10 users which makes it easy to develop, and even use in prod if limited to say just a small group of admins

https://duo.com/pricing

https://github.com/duosecurity/duo_api_php

• Admin: configure and validate via https://duo.com/docs/authapi#/check
• User setup: https://duo.com/docs/authapi#/enroll
• User login flow check: https://duo.com/docs/authapi#/auth

• the form should be in the order you do this so:

1. Enter the name of your device eg 'Brendan's work iPhone' <-- update the lang strings for this

2. Enter the security code OR scan the qr code, move this up into the form

3. then enter the code

• the crumb trail is missing from this page, should have a node for the MFA page and for the add factor page

• factors have a priority / order. I'm thinking for simplicity this is declared by the plugin and cannot be changed. Some factors which have no login flow like ip would be ordered at first.
• factors have a score. This could default to 1, but we able to override this
• you will have a global 'must have X score' in order to login
• each factor should have a method needs_setup()
• have a admin setting which renders a table to manage all the plugins, when each is enabled, the score, the priority.
• have an auto loaded form:

class /factor/plugin/classes/forms/login.php - for login flow (eg enter your qr code)
class /factor/plugin/classes/forms/setup.php - for setup flow (eg generate a code)

When you turn it on you can say 'you need at least X made up of other factors to login', ie an ip factor is 1, and totp with worth 1, and you need 1 to login.

• when you login lets say via an ip network, we need to know that you must now also setup other factors. The 'ip' one has not setup. But the totp on does, so you need to be ask to set it up so that you can come back later when not on the corporate ip network.

This might seem weird, but it would make it very easy to have policies like 'if you are are admin then your factor points need to be higher'. We achieve this by having a negative points for this factor. This also means that this factor needs to be evaluate first. The simplest is to run all negative point factors first, or if we really need it then add an explicit priority / order column to the factors.

• admin boolean setting
• When this is on, it simply shows in the header on every page the list of factors in order, and which ones you have passed, neutral
• show the current total score
• see also #56

https://en.wikipedia.org/wiki/WebAuthn

https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API

Testing demo site:
https://webauthn.io/

Internal WR: https://wrms.catalyst.net.nz/wr.php?request_id=325417

• list all the auth types. Have a checkbox and if they logged in via that type then they get the score for this factor

• Make sure you can't subvert this with a url inside a param
• test for when moodle is installed into a subdirectory

Summary report:

• matrix of auth plugins vs factors, showing a count for who has it setup

• eg support 'recent_login':

https://tracker.moodle.org/browse/MDL-66172

https://github.com/catalyst/moodle-tool_mfa/blob/master/classes/local/form/preferences_form.php#L95-L98

ie if you add the totp, you get a qr code, then enter the wrong code, the form redisplays and you get a different qr code which is a different secret. The secret needs to be fully retained across the forms multiple pages.

Some factors, such as auth_type or ip-range do not require input from the user to be a pass or fail. These should have a way to just query the success or failure from the class.

Inside the object_factor_base class and interface, implement new methods to query whether the factor requires user input for verification, and the result of factor:

• has_input()
• get_state() #56

This can then be checked during login flow:

• if has_input() -> display form else get_state -> pass/fail factor

• on a new login, after login redirect them to a topt setup page, store the wants url
• render a qr code, they scan it. There is a QR code library inside code

require_once($CFG->libdir.'/tcpdf/tcpdf_barcodes_2d.php');
$barcode = new TCPDF2DBarcode($qrcodeurl, 'QRCODE');
$image = $barcode->getBarcodePngData(15, 15);
echo html_writer::img('data:image/png;base64,' . base64_encode($image),''));

• there needs to be the ability to have multiple topt per account. Each will have a name

• then they type in the topt to prove that they scanned it and then they get logged in. Log an event for this.

• if they try to go elsewhere then they get redirected back (possibly with a grade period we can add later)

• on subsequent logins they get the topt prompt, and enter it and that is stored in the session

• after either code setup, or code entering, redirect to the wants url

For that reason it can also be helpful to have string keys which are 'object''actions', eg 'factorrevoke' 'factorenable' and then they are all grouped nicely. I'll make another card that that

Has a soft dynamic dependency on the https://github.com/catalyst/moodle-tool_securityquestions

Not sure how to handle the login flow form. Perhaps have a second method which declares a url to go to instead of an auto loaded form. Actually make it a method with a base class which does the auto loading an then you can override it to make it go somewhere else.

• first determine resolve all of the no-input factors such as iprange
• now if we still don't have enough points work down the list of factors in turn
• trigger each factors once, this will send an email, or send a test etc. TOTP doesn't need this.
• then render the factors login flow form eg /topt/classes/forms/login
• each factor is responsible for managing its state and mutating and resolving it's state. ie if the user submits the form, and the code is correct then change the state to 'Yes'. If they didn't receive the code and want to skip this factor then it resolves to 'No'
• now control passes back to the main plugin, and it moves to the next plugin down the line.
• if we have enough points then we mark this in the session and the user goes on their way
• if we run out of factors then we send an error message and log them out
• if we time out then we log them out
• if at any time any single factor resolves to fail then we log them out

$PAGE->set_cacheable(false);