Password-less login

[digitalpoint]

So I've been looking at ways to support password-less logins with my add-on without making the sign up process confusing. While this thread is more a general request for it to be in XenForo core, what I've been running around might be useful info in regards to that request...

So first some background about how/where WebAuthn credentials are stored. They can be either stored on the authenticator device or they can be stored on the server performing the authentication. In the case of the server storing the credentials, they are stored encrypted where the authenticator is the only way they can be decrypted. Most implementations (including my addon) stores the credentials on the server because there's a finite number of slots an authenticator has for storing credentials on the authenticator (for example, YubiKeys are limited to 25 on-board "resident keys", see FAQ).

For non-resident keys (ones stored encrypted on the server), the authenticator can support an unlimited number of keys (in that case it's simply a decryption device, rather than storing records for each site).

For password-less logins, you need to perform FIDO2/WebAuthn where the credentials are stored on the authenticator device (with password-less authentication, you are asking the authenticator what it knows about the site so it needs the credentials stored on the device itself, where doing it the other way around for things like two-step authentication is different [having a known user, you are able to present the encrypted credentials to the authenticator to see if it can perform decryption]).

Ignoring the on-boarding flow being different for users with and without password-less authentication, these are the current issues I see:

• Android and Windows simply do not do not support Passkeys with resident keys yet (see this page).
• Being limited to only 25 resident keys for things like YubiKey can be problematic in the future if a lot of sites move to password-less authentication.

TL;DR
Password-less authentication takes 1 slot per site and authentication devices have a small number of slots.

 

[⭐ Alex ⭐]

Shouldn't this replace session tokens / cookies, since cookies can be swiped by XSS?

 

[digitalpoint]

Shouldn't this replace session tokens / cookies, since cookies can be swiped by XSS?

Do you have an example where a XenForo cookie can be compromised with XSS?

But to answer your question no... unless you want to re-authenticate yourself upon every page view/HTTP request, this would be a terrible replacement for sessions/tokens/cookies.

 

[PaulB]

Shouldn't this replace session tokens / cookies, since cookies can be swiped by XSS?

No. Cookies can’t be replaced.

 

[⭐ Alex ⭐]

Do you have an example where a XenForo cookie can be compromised with XSS?

But to answer your question no... unless you want to re-authenticate yourself upon every page view/HTTP request, this would be a terrible replacement for sessions/tokens/cookies.

Yes, if my site has an exploit (for example I didnt apply patch 2.2.11 in time) that allows for someone to inject js into a page and I happen to visit it, they can access my session cookie and send it off somewhere.
And yes, that would be the idea. Perhaps WebAuth in this manner would be tied into TLS so that two handshakes arent necessary per request.

 

[digitalpoint]

Yes, if my site has an exploit that allows for someone to inject js into a page and I happen to visit it, they can access my session cookie and send it off somewhere.
And yes, that would be the idea. Perhaps WebAuth in this manner would be tied into TLS so that two handshakes arent necessary per request.

Right, if a site allows exploits to be installed, then yes. However, stealing cookies with XSS is the least of that site's concern. If someone can install server-side files, you could also just extract the database and user credentials for all registered users. At which point replacing cookies or sessions isn't going to help you.

 

[Forsaken]

Yes, if my site has an exploit that allows for someone to inject js into a page and I happen to visit it, they can access my session cookie and send it off somewhere.
And yes, that would be the idea. Perhaps WebAuth in this manner would be tied into TLS so that two handshakes arent necessary per request.

If your site has already been compromised, you already have bigger problems .

 

[⭐ Alex ⭐]

Nevermind, I thought this can generate a key-pair and store it on the device for example in the TPM on windows.

 

[PaulB]

Nevermind, I thought this can generate a key-pair and store it on the device for example in the TPM on windows.

It can—and that still won’t mitigate XSS in any meaningful way. You won’t be able to eliminate cookies, and even if you could, a successful XSS attack would still be able to utilize any credentials accessible to the end user.

Edit: Note that this is entirely theoretical. XenForo’s code base is mature, and although no application is perfect, it has quite good protection against XSS. Third-party code is always a concern, but there’s little you can do to avoid that issue besides carefully vetting any add-ons you install.

 

[digitalpoint]

If your own site is exploited, it’s also not XSS (cross-site being the key there).

 

[PaulB]

If your own site is exploited, it’s also not XSS (cross-site being the key there).

That’s also not true. Most JavaScript injection vulnerabilities are classified as XSS. If you Google OWASP JavaScript injection, you’ll land on OWASP’s XSS page.

This is purely a matter of definition rather than anything meaningful, though. Ultimately, @Pawn Studios is referring to a situation in which an attacker is able to inject arbitrary client-side JavaScript on a XenForo page—whatever you might call that type of vulnerability. The technical term would be XSS, but I’ve always found that to be overly-broad and confusing when communicating.

WebAuthn, for all its strengths, does not help with that scenario.

 

[digitalpoint]

This is purely a matter of definition rather than anything meaningful, though.

Semantics I guess, but my point still stands that if you are having third-party code being installed on your site, having cookies stolen is the least of your worries.

And ya, WebAuthn couldn't get rid of cookies in a realistic way (I certainly wouldn't want to re-authenticate continuously with every http request).

 

[Kirby]

Yes, if my site has an exploit that allows for someone to inject js into a page and I happen to visit it, they can access my session cookie and send it off somewhere

Unless I am missing smth. I think this is incorrect:
xf_session is HttpOnly, so unless there is a serious browser security issue (or an ancient browser is used by the victim) no JavaScript can access the value of this cookie to send it somewhere else.

 

[digitalpoint]

Unless I am missing smth. I think this is incorrect:
xf_session is HttpOnly, so unless there is a serious browser security issue (or an ancient browser is used by the victim) no JavaScript can access this cookie.

An excellent point, which I forgot about. But yes... both xf_session and xf_user cookies are not accessible to JavaScript.

Those XenForo devs... it's like they know what they are doing or something.

 

[PaulB]

Unless I am missing smth. I think this is incorrect:

It's still correct. I should've been clearer: an injected script can still use the session cookie--it just can't read the value through document.cookie.

From the perspective of an attacker utilizing XSS, there's no practical difference between a session cookie with the HttpOnly flag and alternative authentication methods such as mTLS. The injected script is constrained to acting on behalf of the current user while it's running in that user's browser, which means an attacker needs to do additional work and planning.

If the cookies weren't HttpOnly, then there would be a difference.

But yes... both xf_session and xf_user cookies are not accessible to JavaScript.

Just to be clear, that's not strictly true, and you should assume that any script running on your site is capable of utilizing those cookies. If you are logged in as an admin with sufficient permissions, on a standard installation, such a script can also retrieve the values of those cookies.

For anyone joining the conversation late: this is all theoretical and is discussing a worst-case scenario in which your website is already compromised.

 

[Kirby]

It's still correct.

That's debatable @Pawn Studios said an injected JS could access the cookie to "send it off somewhere".
To me "send it off somewhere" means "read the value and send it somewhere else than the origin".

How would that be possible for just a JS with HttpOnly?

 

[PaulB]

XenForo is a mature enough code base that any in-band attacks against a vanilla, up-to-date installation are almost certainly going to require chaining multiple zero-day exploits. Anyone skilled and determined enough to perform such an attack would be able to work around lack of access to document.cookie. I don't think it's worth going into detail about hypotheticals: the point is that if an attacker is able to run arbitrary JavaScript in a user's browser, they're capable of performing any interactions that user could perform; for an admin, that might include changing templates, installing add-ons, or promoting other users.

Modern attacks against stable applications typically work that way: chaining together several exploits in a careful manner so as to gain increasing levels of access. Even if you find an XSS vulnerability in XenForo today, if you want to actually exploit it in a meaningful way, you're probably going to have to do a lot of additional work.

That's debatable @Pawn Studios said an injected JS could access the cookie to "send it off somewhere".
To me "send it off somewhere" means "read the value and send it somewhere else than the origin".

With full XSS, that would be possible--it would just require a lot more effort than merely reading document.cookie.

However, we're deep in the realm of hypotheticals now. None of this really matters. The point is made: as long as XenForo is using HttpOnly, cookieless auth tech isn't any stronger against XSS than traditional cookies. It's stronger against other attack vectors, but not XSS.