Authentication refactoring and MFA capabilities: TOTP + Lookup Secrets

[aeneasr]

This is an umbrella issue for all things related to single and second factor authentication, the different factors, passwordless authentication, and more.

• [x] TOTP
• [x] Recovery Codes
• [x] WebAuthn
• [ ] Documentation
• [x] UI examples

Implementation of these features by the ORY Kratos maintainers has officially started: https://github.com/ory/kratos/issues/26#issuecomment-745464249

[aeneasr]

The 2FA hook should require 2FA by redirecting to the 2FA endpoint. It should be configurable to cover use cases:

• All users with 2FA enabled should be required to use 2FA
• Support acr value from OpenID Connect
• Allow for more complex rules like: Administrators must always authenticate with 2FA

If 2FA is not enabled but required, should users be required to set it up after login or should they be locked out of their accounts?

Enforcement policy:

• Allow grace period before enforcement kicks in
• Allow grace period after sign up to set up 2fa

Configuration MVP

enable: true/false
policy:
  enforce: true/false
  grace_signup:
  enforce_from: 1.1.2015

[asaf]

@aeneasr some thoughts about the implementation of this:

• Add a new strategy per 2FA method (e.g., TOTP)
• Flow object should contain other Method(s) for 2FA, this is mandatory for UI to render relevant forms such as OTP input field (maybe the method could contain a hint that this is a stage 2 so UI can render the correct method per stage)
• a login strategy invokes PostLoginHook at the end of the flow (if it's not too late), such 2FA login hook could intercept the request, identify that the user requires 2FA and invoke UpdateLoginFlowMethod accordingly. (I wonder if flow needs to be aware of its stage (1FA/2FA) or not, otherwise how UI will know which stage to render?) and redirect back to self-service UI login page
• the UI at this point should render the 2FA methods
• UI submits form where flow.methods.totp.config.action should be the URI of the 2FA strategy
• strategy performs authentication and completes the flow (If 2FA is interpreted by PostLoginHooks, then it will be invoked twice (once after 1FA, then after 2FA), this time the 2FA hook should be aware of the flow stage in order to avoid an infinite loop and complete it)

[aeneasr]

Thank you for these thoughts! Extending on your comment:

1. I think 2fa should be a first class citizen of the login, registration, recovery and settings flow
2. We implement a 2fa flow method (e.g. TOTP) which implements the two required interfaces
3. We either require the login UI to render the 2fa input box, or we add an additional UI URL

If we make 2fa a first-class citizen of the existing flows, I think it will be easier to integrate!

[sycured]

Have you an ETA? It's a mandatory requirement on a project with EHR (Electronic Health Records).

[aeneasr]

We don't give out ETAs but if you have a critical dependency you could:

1. Discuss options for contributing 2FA flows (warning: it is going to be a lot of work if you are new to the project)
2. Talk to Jared about ideas for funding and prioritizing this feature

[asaf]

@aeneasr yea, hooking 2FA into other flows but login makes sense, it could be nice to create some generic mechanism to 'suspend' the various flows if 2FA is enabled without repeating this tedious effort.

[mrosales]

Just pitching in with some ideas here – I'm not an active user of Kratos (yet!), but I've been following the development and MFA support would be one of the things that helps make the case for migrating much easier.

Including all of these would be way beyond the scope for any kind of initial MFA support, but some ideas that I have that might be helpful for the architecture design are:

1. Ideally MFA allows more than two factors in a single auth flow. An example of the value here could be considering CAPTCHA (which was another tracked ticket) as a requirement of an auth flow in addition to the standard login + second factor. Also in this category of nice to haves would be the ability to replace a password with multiple additional factors. For example email/SMS could be used for step-up 2FA with an identity based on WebAuthn. This would be more of an MFA-first type approach where a password would be considered as just another possible factor in a login rather than an essential part.
2. Different kinds of MFA challenges could likely be grouped into multiple buckets. a. Some, like TOTP can be provided in channel at any point during the flow. b. Others, like SMS or an email containing a code might have an out of channel delivery, but in-channel submission (code returned by entering the code or clicking on a redirect link that adds the code to the current session). c. Others like a Push Notification (like the Duo or Authy App) would be even more complicated and would require out of channel delivery and status checking. This is the most complicated one because the client logging in won't necessarily know if the request has been satisfied and when it can continue.
3. Ideally the architecture (even if the initial implementation doesn't) would support dynamically defining rules to configure the expected or desired challenges. For example, logging in from a whitelisted IP range could skip MFA for known clients. Some examples of this would be the Auth0 Rules API or the AWS Cognito "Define Auth Challenge" hook.
4. Another nice future feature could be implementing SRP to do a secure password exchange, and that would likely benefit from the same kind of challenge-response auth flow features that would be required for some of the points in 1-3. While I find the API pretty clunky, AWS Cognito kind of supports this: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html#Using-SRP-password-verification-in-custom-authentication-flow
5. The story for adding/removing MFA devices is pretty complicated. What kind of authentication is required to replace an MFA device? In a 2fa system, maybe the password is enough to change the phone number, but ideally the the account reset or security authorization factor isn't one of the primary factors used for authorization. For a generic MFA interface, I think that this means that its always best to have at least three factors, any two of which can be used to initiate a session and the third can be used to provide an additional factor for performing a reset on either of the other two.

[znerol]

... MFA support would be one of the things that helps make the case for migrating much easier.

Agree.

This would be more of an MFA-first type approach where a password would be considered as just another possible factor in a login rather than an essential part.

That is imho a very important observation. In order to bring this issue forward I propose to start defining actionable steps. Starting with key data structures and interfaces:

1. The Session member AuthenticatedAt needs to be replaced with a set of authentications. Each authentication record represents a successful authentication attempt at a specific time with a certain authenticator. An authenticator represents a reference to the authentication method (credential type) together with a reference to the credentials used (credential id).
2. NewActiveSession needs to be extended to take one authentication record (instead of an authenticatedAt param).
3. A new method needs to be added to the Session to StepUp a session using an additional authenticator. The StepUp method takes an authentication record and returns a copy of the session with the authentication record added to the existing authentications and a regenerated session id.
4. Similar to the existing refresh mechanism (which forces a user to reauthenticate in order to access privileged settings), let's implement a stepup mechanism (which forces a user to authenticate with an additional authenticator).

[aeneasr]

Thank you for your ideas!

Ideally MFA allows more than two factors in a single auth flow. An example of the value here could be considering CAPTCHA (which was another tracked ticket) as a requirement of an auth flow in addition to the standard login + second factor. Also in this category of nice to haves would be the ability to replace a password with multiple additional factors. For example email/SMS could be used for step-up 2FA with an identity based on WebAuthn. This would be more of an MFA-first type approach where a password would be considered as just another possible factor in a login rather than an essential part.

I generally agree with this sentiment. It's not very common to have more than one factor but it could be desireable in very specific scenarios. We generally plan to support more than 2FA.

a. Some, like TOTP can be provided in channel at any point during the flow.

Yup, I think TOTP is the most straight forward to implement.

b. Others, like SMS or an email containing a code might have an out of channel delivery, but in-channel submission (code returned by entering the code or clicking on a redirect link that adds the code to the current session).

SMS or email auth is what we call "passwordless". I think we need to differentiate between a second factor and the primary authentication mechanism for an identity. It could re-use some code, but I would weight them as conceptually different.

In general, SMS-based authentication is considered a very, very weak mechanism as it is supsectible to so, so many attacks. It is only useful to prevent broad abuse of a system but it is very bad at preventing spear-fishing or other forms of targeted attacks.

c. Others like a Push Notification (like the Duo or Authy App) would be even more complicated and would require out of channel delivery and status checking. This is the most complicated one because the client logging in won't necessarily know if the request has been satisfied and when it can continue.

The complexity here is probably the user interface as this is what people have to implement themselves. Adding a check here could be a bit cumbersome during implementation but I fear there's no real way around that.

Ideally the architecture (even if the initial implementation doesn't) would support dynamically defining rules to configure the expected or desired challenges. For example, logging in from a whitelisted IP range could skip MFA for known clients. Some examples of this would be the Auth0 Rules API or the AWS Cognito "Define Auth Challenge" hook.

I think this is a nice extension but I would not consider this as part of the first implementation. In general, I believe this could be implemented using our hooks and some custom logic. It would be very similar to Auth0 rules but it could work in different parts of the pipeline as well, not just immediately after authentication as is the case with Auth0.

Another nice future feature could be implementing SRP to do a secure password exchange

Never heard of SRP - could you go into a bit of details?

The story for adding/removing MFA devices is pretty complicated. What kind of authentication is required to replace an MFA device? In a 2fa system, maybe the password is enough to change the phone number, but ideally the the account reset or security authorization factor isn't one of the primary factors used for authorization. For a generic MFA interface, I think that this means that its always best to have at least three factors, any two of which can be used to initiate a session and the third can be used to provide an additional factor for performing a reset on either of the other two.

So how this typically works is that you associate a session with an authentication method (in OIDC this is called ACR). The level of authentication represents the factors you completed. Let's say level 0 for username + password, level 1 for username + password + totp.

When changing TOTP device you would expect the session to have at least level 1 and you could require the user to reconfirm that they are who they are by requesting another level 0 authentication. That's how it is usually done!

You could however also request another level 1 authentication which would mean username + password + existing TOTP.

The Session member AuthenticatedAt needs to be replaced with a set of authentications. Each authentication record represents a successful authentication attempt at a specific time with a certain authenticator. An authenticator represents a reference to the authentication method (credential type) together with a reference to the credentials used (credential id).

Cool ideas! Another possibility would be to associate a ACR ("Authentication Context Class Reference") level alongside the session which would make it a bit easier to manage. I would actually encourage some reading of the NIST Digital Identity Guideliens before determining terminology and processes as they go very deep into details wrt MFA.

[znerol]

Another possibility would be to associate a ACR ("Authentication Context Class Reference") level alongside the session which would make it a bit easier to manage.

Yes, for most use cases that would probably be enough. The periodic reauthentication scenario, however, might be difficult to implement unless authentication timestamps are recorded separately for each credential/authenticator pair.

Also linking sessions to credentials in a many-to-many relationship allows to easily kill sessions when credentials are changed (no matter whether those credentials are passwords, fido keys or your fingerprints).

[zepatrik]

Another MFA idea we could quite easily implement:

My bank requires

1. password
2. a partial PIN

This partial PIN is a 6 digit PIN, but I only have to input two out of six digits on every login. These two digits are not typed through the keyboard but instead the web page displays a soft keyboard you have to use. I believe the goal is to prevent key loggers and shoulder surfing, as you would have to observe the victim at least a view times to figure out all the digits and their position. Also you have to monitor two channels (keyboard and screen). Quite simple but still effective.

[aeneasr]

Also linking sessions to credentials in a many-to-many relationship allows to easily kill sessions when credentials are changed (no matter whether those credentials are passwords, fido keys or your fingerprints).

I think that makes a lot of sense. However, we probably don't need linkage. We just kill all sessions with auth_time before the change?

Yes, for most use cases that would probably be enough. The periodic reauthentication scenario, however, might be difficult to implement unless authentication timestamps are recorded separately for each credential/authenticator pair.

Right, I mean it makes sense to add that context to the session!

[vincentserpoul]

webauthn can also be used for passwordless, as it can include (depending of the config) 2 factors (what you know and what you have).

[aeneasr]

@vincentserpoul but that means that you have one key in the browser probably (software key) and one hardware key, right?

[znerol]

@aeneasr exactly. The crucial thing is that you need to check whether a given webauthn device is actually a platform authenticator.

[vincentserpoul]

actually, there is no browser key. If you use a platform authenticator, as @znerol mentioned, it will leverage a hardware key (the first factor) and to unlock this key, you will need to put a password (something you know) or a biometric (something you are) which is the second factor.

[aeneasr]

Oh, I see - so we would actually need two variants - one for a regular login method, and one for a 2fa method?

[vincentserpoul]

I think it would make sense! maybe actually all login method could be eligible for 2fa?

[aeneasr]

Yes, all login methods should be eligible for 2fa! Once exception is oidc where the oidc provider has 2fa built into their platform (using ACR).

[vincentserpoul]

taking a bit of a step back on this, as I was looking into it. I think MFA would be a better way to think about this functionality. When I read 2fa, I think second factor whereas it is actually two factor. Looking at the wikipedia definition: https://en.wikipedia.org/wiki/Multi-factor_authentication the different factors are: knowledge, possession, inherent, location.

So in the end, the different methods should validate/prove/check (not sure which verb would fit best) one or more of these 4 boxes (password is only knowledge, webauthn can be knowledge/possession/location depending on the user device and the config). two factor would mean: the combination of all methods required to login/register/... should validate at least 2 factors.

Let me know what you think, maybe I'm going to far :).

[aeneasr]

You're right with this. I have started working on this today but it is very difficult from a flow perspective. There are several moving parts:

1. We will have multiple authentication methods:
   1. TOTP (this is Google Authenticator)
   2. WebAuthN
   3. SMS
2. For all authentication methods there will be the need to have recovery or backup codes which can be used when the TOTP device, the SMS device, or the device carrying the WebAuthN private key are lost.

Some providers like Coinbase have an elaborate 3FA process where the first step is username + password, the second is SMS or TOTP code, and the third is a link sent to your email confirming the login.

Other providers use adaptive 2FA where 2FA is only required for certain actions or in certain scenarios (e.g. login from unknown device).

It is also possible that there is a combination of several factors (TOTP + WebAuthN) although I have not really seen that in the wild yet.

One primary problem is definitely the onboarding process as it is quite UI heavy. Taken from the TOTP project:

1. Provide the user with "recovery codes".
2. Generate new TOTP Key for a User. key,_ := totp.Generate(...).
3. Display the Key's Secret and QR-Code for the User. key.Secret() and key.Image(...).
4. Test that the user can successfully use their TOTP. totp.Validate(...).
5. Store TOTP Secret for the User in your backend. key.Secret()

So there is a multi-step process to "linking" a TOTP device. A similar thing is probably required for SMS and maybe WebAuthN although the last part could be a bit easier.

Another issue is "forced 2FA" or "forced 2FA with enrolment grace period" where users MUST have 2FA set up in order to log in. The problem here is that this would enforce 2FA set up during registration, which is tricky, because the question comes to mind if a user can even register without setting up 2FA or if 2FA is simply disabled and required to set up after successful login.

There are more use cases and flows along these lines I can think of and I think it will be difficult to cover those in a easy to use plug-and-play way as we do currently for login.

This will need some more thinking on my end - we probably have to define the MFA login, recovery, set up flows first and then start looking at the actual implementations of those flows.

[xlanor]

For SMS, perhaps I can chime in a little here as we are building our addon microservice to fufill the requirements needed by our business team.

What we've implemented is basically also using TOTP to generate an OTP which is then sent on to the mobile phone number as a text message. When the user enters the OTP, we then consider that as a validated secret and save the secret for future usage.

In the event that the user loses access to the mobile number, there's several ways that this can be worked around - for example, in a similar fashion to downloading generated secrets from aws, the first time that the user logs in after validating the TOTP secret, the keys secret will be available to him for download for the next five minutes.

[vincentserpoul]

to clarify things, I think we should make sure what we mean by factor and auth method. Is factor what wikipedia refers to: knowledge, possession, inherent, location? Or is factor an authentication method?

I'd lean towards number one, what do you think @aeneasr ?

@xlanor : does it actually make TOTP less secure by sending it through SMS?

[xlanor]

@vincentserpoul Yep, I feel that it does, but those were the requirements given to me when I had to implement it due to initial market research suggesting that our user base may not be savvy enough to utilise authenticator tools.

Regarding the factor mentioned above, I would agree that factor should be defined as the 4 mentioned in your first.

[aeneasr]

Everything below is an excerpt from the NIST Digital Identity Guidelines. While some of those recommendations are for Goverment Agencies only and might be too strict for a freemium mobile game, it does make sense to take their terminology and findings into consideration.

Authentication and Factors

The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:

• Something you know (e.g., a password).
• Something you have (e.g., an ID badge or a cryptographic key).
• Something you are (e.g., a fingerprint or other biometric data).

MFA refers to the use of more than one of the above factors. The strength of authentication systems is largely determined by the number of factors incorporated by the system — the more factors employed, the more robust the authentication system. For the purposes of these guidelines, using two factors is adequate to meet the highest security requirements. As discussed in Section 5.1, other types of information, such as location data or device identity, may be used by an RP or verifier to evaluate the risk in a claimed identity, but they are not considered authentication factors.

Source: https://pages.nist.gov/800-63-3/sp800-63-3.html#43-authentication-and-lifecycle-management

Identity Assurance Levels (IAL) / Authenticator Assurance Level (AAL)

In OpenID Connect, the AAL is used in the ACR (Authentication Context Class Reference). Basically, OpenID ACR could be e.g. phr for phishing-resistant and phrh for Phishing-Resistant Hardware-Protected (Source)

Given the graphic above, we currently support AAL1 using a Memorized secret and out-of-band (OIDC). We could support OTP (TOTP, SMS) and Crypto (WebAuth) for AAL1 also. So basically adding a new login and registration method called TOTP and WebAuth (I guess this is FIDO2?).

Out of Band Devices

An out-of-band authenticator is a physical device that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. The device is possessed and controlled by the claimant and supports private communication over this secondary channel, separate from the primary channel for e-authentication. An out-of-band authenticator is something you have.

OTP Devices

• A single-factor OTP device generates OTPs. This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones. These devices have an embedded secret that is used as the seed for generation of OTPs and does not require activation through a second factor. The OTP is displayed on the device and manually input for transmission to the verifier, thereby proving possession and control of the device. An OTP device may, for example, display 6 characters at a time. A single-factor OTP device is something you have.Single-factor OTP devices are similar to look-up secret authenticators with the exception that the secrets are cryptographically and independently generated by the authenticator and verifier and compared by the verifier. The secret is computed based on a nonce that may be time-based or from a counter on the authenticator and verifier.
• A multi-factor OTP device generates OTPs for use in authentication after activation through an additional authentication factor. This includes hardware devices and software-based OTP generators installed on devices such as mobile phones. The second factor of authentication may be achieved through some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). The OTP is displayed on the device and manually input for transmission to the verifier. For example, an OTP device may display 6 characters at a time, thereby proving possession and control of the device. The multi-factor OTP device is something you have, and it SHALL be activated by either something you know or something you are.

Google Authenticator

The Google Authenticator is a single-factor OTP device. It is not a multi-factor OTP device because:

Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators (see Section 5.1.4.1), except that they require the entry of either a memorized secret or the use of a biometric to obtain the OTP from the authenticator. Each use of the authenticator SHALL require the input of the additional factor.

WebAuth

I have not looked into WebAuth too much but I think we can have both single and multi-factor OTP using WebAuth.

SMS

Yes SMS is not as secure as the TOTP spec but it is more secure than no second factor and makes broad attacks very hard to pull of. To protect against targeted attacks, TOTP or WebAuth are better suited (e.g. high value targets, goverment agencies, ...).

In the Digital Identity Guidelines, SMS is listed as an out of band authenticator with the limitation that it can only be used in RESTRICTED contexts - I assume RESTRICTED refers to the classification level.

Email

[Authentication] methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.

https://pages.nist.gov/800-63-FAQ/#q-b11

Cryptographic Devices

• A single-factor software cryptographic authenticator is a cryptographic key stored on disk or some other "soft" media. Authentication is accomplished by proving possession and control of the key. The authenticator output is highly dependent on the specific cryptographic protocol, but it is generally some type of signed message. The single-factor software cryptographic authenticator is something you have.
• A single-factor cryptographic device is a hardware device that performs cryptographic operations using protected cryptographic key(s) and provides the authenticator output via direct connection to the user endpoint. The device uses embedded symmetric or asymmetric cryptographic keys, and does not require activation through a second factor of authentication. Authentication is accomplished by proving possession of the device via the authentication protocol. The authenticator output is provided by direct connection to the user endpoint and is highly dependent on the specific cryptographic device and protocol, but it is typically some type of signed message. A single-factor cryptographic device is something you have.
• A multi-factor software cryptographic authenticator is a cryptographic key stored on disk or some other "soft" media that requires activation through a second factor of authentication. Authentication is accomplished by proving possession and control of the key. The authenticator output is highly dependent on the specific cryptographic protocol, but it is generally some type of signed message. The multi-factor software cryptographic authenticator is something you have, and it SHALL be activated by either something you know or something you are.
• A multi-factor cryptographic device is a hardware device that performs cryptographic operations using one or more protected cryptographic keys and requires activation through a second authentication factor. Authentication is accomplished by proving possession of the device and control of the key. The authenticator output is provided by direct connection to the user endpoint and is highly dependent on the specific cryptographic device and protocol, but it is typically some type of signed message. The multi-factor cryptographic device is something you have, and it SHALL be activated by either something you know or something you are.

All of these can be implemented using WebAuth iirc.

Biometrics

NIST SP 800-63B supports the use of biometrics as an authentication factor with some limitations. Biometrics may be used only as part of multi-factor authentication in conjunction with a specific physical authenticator (something you have). If biometrics are used in multi-factor authentication the following requirements apply:

An authenticated protected channel between sensor and the verifier must be established, or the sensor must be integrated with the endpoint in a manner that resists sensor replacement The sensor or endpoint must be authenticated prior to capturing the biometric sample from the claimant The biometric system must operate with a False Match Rate (FMR) of 1 in 1000 or better [see ISO/IEC 2382-37]. This FMR applies under conditions of a conformant attack (i.e., zero-effort impostor attempt) as defined in ISO/IEC 30107-1 The biometric system must limit consecutive failed authentication attempts The verifier must make a determination of sensor and endpoint performance, integrity, and authenticity based on the requirements presented above. The unlocking of a device through biometric match may not be considered to meet these requirements since it is generally not possible for the verifier to obtain any information on how, or whether, the device was unlocked.

NIST recommends that the biometric system implement Presentation Attack Detection (PAD). NIST is considering PAD implementation as a requirement in the future.

Please see SP 800-63B Section 5.2.3 for additional implementation guidance for the use of biometrics as an authentication factor.

Most authenticators using biometrics will function as multi-factor authenticators where the biometric unlocks a secret stored in the authenticator. A memorized secret (often a PIN) can also be used to unlock the same secret, as is common in many mobile devices.

[aeneasr]

So I looked a bit into federation and MFA. As far as I can tell, none of the big platforms support any sort of ACR - meaning that you can not ask to "Sign in with Google (and enforce 2fa)". The "(enforce 2fa)" portion is probably linked to your account settings and can apparently not be modified from a 3rd party. Additionally, the ID Token does not provide any information about the factors used.

It is the same story for GitHub and probably a lot of other platforms as well. It seems like ACR is something targeted at bespoke solutions.

For us this means that MFA needs to be enforced in ORY Kratos. Even if a user signs in with Google and presents a valid second factor to Google, we would still need to request the second factor for that user in ORY Kratos, because we have no way to tell if the login used 2fa or not.

This finding is not terrible, because it makes the flow easier to model, as every flow starts with identifying the user (e.g. username+password, google ID token) and then proceeds to the MFA processing.

[aeneasr]

I looked more into WebAuthN (FIDO2) and am pretty disappointed. There are several hard obstacles when using WebAuthN without a FIDO2 hardware key (e.g. YubiKey). So these limitations apply to the TPM authenticator type (FaceID, TouchID, ...).

First, it is not possible to port the private key performing the proof authentication across browsers nor devices using the WebAuthN standard (https://github.com/w3c/webauthn/issues/151 https://github.com/w3c/webauthn/issues/865). Trying to register in Safari and then logging in on Chrome on the same laptop using WebAuthN will result in a failure.

Apparently, it is not wished for this to be possible either - because of attestation:

The position Yubico has taken for our Security Key and YubiKey authenticators is that private keys can never leave the authenticator. One reason for this is the issue of attestation: the attestation statement sent in a registration request attests that the private key is created and owned by the authenticator, and has never been exposed to any other party. If it were possible to import a private key from outside the authenticator, we would not be able to attest this. - Source

Unfortunately, this means that it is not possible to use the same private key on multiple platforms. Further, this implies that using WebAuthN as the only authentication method is unfeasable because device loss leads to a complete lock out. Without account recovery mechanisms such as security codes, it is not possible to link other browsers.

In total, what this means, is that WebAuthN in TPM mode can not be used as a first party authentication mechanism for web applications because it is bound to exactly one device. Forcing the user to go through several account recovery processes in order to link additional devices or browsers (private keys) is a user experience nightmare. One possibility could be to use the linked TPM hardware to authenticate a login request from another device, but this already sounds very difficult to implement and explain to users - what happens if you first sign up on a laptop?

If one or more YubiKeys are used, you can plug the key into the device. This means that you could theoretically authenticate in multiple browsers, by having the YubiKey in your USB slot. However, almost noone has a YubiKey for personal use - the average consumer owns a smartphone and a laptop or tablet.

All of this makes FIDO2/WebAuthN much less attractive for broad implementation. However, allowing hardware keys in MFA flows does have it's appeal to high-security environments. But having WebAuthN enabled MFA does not remove the need for a back up mechanism (like security codes) which help recover access to an account.

[vincentserpoul]

I'm pretty familiar with webauthn. I totally agree that registering with only webauthn is not possible, for the inconveniences you mentioned.

That said, it does not forbid you to sign in/auth with webauthn. The most user friendly flow I 've seen:

• register/recovery with magic link in email
• After first registration, associate device (TPM) with account
• next logins: either use a magic link again (if no device avail), or simply use webauthn.

I think it's really a nice experience for the customer, it makes things really easy.

[aeneasr]

Thank you for this use case - I think it makes sense if WebAuthN is seen as an ease-of-use utility versus an actual, strong authentication mechanism. It does make sense to have this capabilities to just make it easier for people to sign in. But it would probably not pass any type of FIPS or HIPAA certification because the weakest link is the magic email link, leaving the door open to e.g. phishing attacks (on the mail address).

[aeneasr]

Interesting Hacker News thread on sign in links: https://news.ycombinator.com/item?id=25628729

[znerol]

Interesting doc linked in the HN comments: https://www.w3.org/TR/capability-urls/

I am using one site which does sign-in by email. I think this only works well for low privilege accounts on sites with very long living sessions (months or even years).

[vincentserpoul]

just to make it clearer, the email register mentioned is not part of webauthn. webauthn itself has multiple config, some being more secure than others, but overall, it's quite secure.

[docelic]

Could you please clarify - Kratos' description includes "...with ORY-hardened authentication, MFA, FIDO2...". Does this mean that some of the topics discussed in this thread (for example, TOTP) are implemented, or everything is still work in progress?

[sycured]

@docelic actually, I think that it's stale/work in progress: https://github.com/ory/kratos/issues/26#issuecomment-711169742 This answer to my comment for ETA proves that the team is more looking for another thing than implementing everything that we need globally in this style of tool.

For me, the description is just like commercial fraud: we sell something (in the description) that doesn't do the job.

[aeneasr]

For me, the description is just like commercial fraud: we sell something (in the description) that doesn't do the job.

An open source project that is doing commercial fraud? Are you serious?

If you take a look at the current work in several branches and the commit history, instead of making allegations, the question would have been answered already: We are dedicating every day since end of december 2020 on this topic. Maybe have a bit of patience instead of making baseless accusations, or, ask how you can help out. You are free to use a proprietary technology that charges $1 per user per month any time. By the way, if you want to support open source, you can sponsor our work so that we can develop features faster.

In the future, please follow our community guidelines.

[nerrixde]

@aeneasr fully agree with you there. I was looking forward to contribute, I asked some questions in #kratos in slack for where to get started, an answer there would be much appreciated :heart:

[aeneasr]

Thank you @nerrixDE ! It has been quite busy as we have been moving offices (we posted some pictures in the general chat :) ). I am currently refactoring the flows and also the form fields to accustom things such as: QR codes, security back up codes, javascript, and so forth. Unfortunately, that makes it a bit hard to contribute as there are constant changes in the code base!

However, what I think would be helpful, is to better understand how we could implement WebAuth! I played around with it and also bought a YubiKey, but have not yet figured out how to integrate that in the Login UI - given that we need to execute some JavaScript to make it work. Any knowledge you might have there would be helpful!

[aeneasr]

By the way - you can follow the progress here: https://github.com/ory/kratos/pull/1012 - I expect the whole effort to take around 2 more months (no guarantees) as we have to rework a lot of the internals to support multi-step flows. We also want to solve password less login with e.g. YubiKeys from the get go, which means that we have to rework a lot of stuff. Because we have so many tests, this takes a ton of time!

[nerrixde]

I really enjoy how @nextcloud implemented WebAuthn. Backend is in PHP but the concept should work for kratos as well.

[vincentserpoul]

@aeneasr once you have something stable, let me know, I'm sure I can help quite a bit on the webauthn side

[Jonas-Sander]

Kind of random, still just gonna throw this in: If you enroll into the Google Advanced Secruity Program where hardware keys are enforced for authentication you need at least 2 keys so that you have one key as a backup.
So you don't have any backup codes there.

EDIT:

To add to that: As the default setting you still have the option to generate a secruity key with another signed-in device under g.co/sc as a second factor instead of using the security key. This can be disabled by an admin in the google admin console so that a security key or verification by Google support is the only way.
(The description shows another use case: for devices not supporting security keys)

[aeneasr]

Ah nice, that makes sense, thank you for the use case!

[ghost]

@aeneasr U2F in Go https://github.com/duo-labs/webauthn. The most secure implementation realistically is password + U2F (with yubikey, titankey, solo https://solokeys.com/), but i would argue that PIN + U2F should be enough. Another U2F can be the backup (when you buy titankeys from Google you get the bluetooth + USB FIDO2). I think recovery keys make sense as well, if Kratos aims to be useful to big organizations as well. I am not a fan of adaptive MFA (it often confuses large scale company users and during real pentests i enjoyed using the user's browser to bypass adpative MFA when they weren't there or use directly their cookies/access tokens when they were present). I would recommend PIN + U2F on 15 mins logout without user actions on browser and using refresh tokens with local reauthentication mobile to unlock keystore. I absolutely abhor it but i was surprised by the number of authentication scenarios in South America, Africa and Asia outside China only using phone identity to authenticate and also by telecom providers in North America upgrading it with Android U2F with ACR would be great. Authentication methods (no adaptive) :

• WebAuthn (most recent Android support and planned iOS)
• Email
• SMS
• TOTP/HOTP
• password with ACR.

[aeneasr]

Thank you @ashley-3r for the insights! I think that all makes a lot of sense. Adaptive MFA is also hard to abstract I think as everyone will probably want different rules?

WebAuthn is by the way already supported in iOS! Our plan was to have WebAuthn and TOTP as the first supported authentication factors and also suitable for MFA.

[nerrixde]

yeah but I think it makes sense to have the priority (if prioritizable) to TOTP

[robertlagrant]

I don't know if it helps, but I spotted arengu.com on HN, which is a login flow builder. I wonder if ideas from how they structure things might help your thinking in this complex area.

(I have no affiliation with them.)

[aeneasr]

That's a nice looking product! Thank you for the tip!

[dduzgun-security]

An interesting idea for the MFA flow would be to offer 2 options.

• Classic flow : identifier->password->MFA
• Protected flow : identifier->MFA->password

The protected flow would reduce the attack surface of a malicious actor since MFA would be required before entering a password.

[aeneasr]

Why would it reduce the attack surface?

[dduzgun-security]

Pros Asking for the MFA (that changes over time) before asking for a password would reduce the possibilities of brute force attacks to guess a user's passwords. Knowing that many people tend to reuse passwords, this may be useful.

Cons However, it would mostly work with TOTP because other methods (Notifications, Email, SMS, ..) could be used to spam users. Also, it would lead to an enumeration of users that doesn't have the MFA activated.

This method could potentially reduce password brute force attacks for users with TOTP MFA. The more I think about it, I realize that the classical flow with a proper rate-limiting mechanism would make more sense.