This bug is still happening.

"The second issue I had was with the PlgAuthenticationCookie::onUserAfterLogin. I ran into the case where some browsers (safari, webkit based and possibly firefox) do a prefetch on the url even before you hit enter to go to the site. This is causing a valid login via PlgSystemRemember, but the PlgAuthenticationCookie::onUserAfterLogin is attempting to change the login cookies password hash based on a random password. It appears that these browsers are not keeping the result of the cookie change based on the reset when you actually goto the site and sending the original saved cookie password hash instead. So a login failure happens."

That's exactly what it is. If you disable preloading/prefetching in your browser settings, the problem doesn't occure anymore.

If not, browser will log in and receive new cookie hash but won't save it so when you then try log in with old hash Joomla will reject it.

I tested it with the latest and clean Joomla version in different servers with different browsers.

That part will always be the case. The remember-me doesn't allow to log in more than once with the same cookie value, so it has to be changed after each successfull login. It's part of the security mechanism.
And last I checked, I didn't see a way to detect if the browser does a prefetch or a real access. If we could detect that, we could deny the login on the prefetch or something like that. But since we don't know it, we can't do anything.
So either disable prefetch on your browser or don't use remember-me.

Hello, Bakual!

Even if somebody stole your cookie, he would need to have the same headers as you otherwise Joomla will receive different getShortHashedUserAgent value, isn't it?

Maybe it would be great to add an option in Joomla admin panel to choose if admin wants to cancel cookie value changes or modify algorithm of cookie validation because almost every modern browser has prefetching by default and some of them (Safari for instance) don't provide switching-off. And admin has to explain to every user what he has to change in browser preferences to ensure that remember-me plugin is worked.

Even if somebody stole your cookie, he would need to have the same headers as you otherwise Joomla will receive different getShortHashedUserAgent value, isn't it?

The name of the cookie isn't something that is part of the security mechanism. Imho it could be named rememberme and still be exactly the same safety.
I guess it's also easy to answer the request with a completely different cookie, as that part is controlled by the browser and not the server.

Maybe it would be great to add an option in Joomla admin panel to choose if admin wants to cancel cookie value changes

No, that would be a horrible option. If you don't change the value, then the remember-me feature is absolutely unsafe and shouldn't be used at all. Keep in mind that you bypass the authentication with this, so it has to be as safe as possible.

So actually we have to fix getShortHashedUserAgent because we should remove all browser versions we can find in it... and getShortHashedUserAgent is not a really good security mechanism at all. Because the chance that you get the useragent with the cookie is really high (it's part of the cookiename) so the attacker has already the information he/she needs to generate the correct user-agent. In addition to this apple started to reduce the information in the user-agent to prevent fingerprinting.

@joomla/security what's your thought's about removing getShortHashedUserAgent in J4?

No, that would be a horrible option. If you don't change the value, then the remember-me feature is absolutely unsafe and shouldn't be used at all. Keep in mind that you bypass the authentication with this, so it has to be as safe as possible.

As far as I understand not all browsers send special headers while prefetching the link:
https://bugs.chromium.org/p/chromium/issues/detail?id=86175

So there are no any solutions in terms of current Remember-Me mechanism of Joomla?

No, that would be a horrible option. If you don't change the value, then the remember-me feature is absolutely unsafe and shouldn't be used at all. Keep in mind that you bypass the authentication with this, so it has to be as safe as possible.

Excuse me, could you please explain me why using persistent token value is unsafe in comparison with its changing after every log-in.

I read this article and they only say: "Important: If the user should ever change their password, you should invalidate all existing long-term authentication tokens for that user."
https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence

@HLeithner You don't have to fix the function. It's not really a big issue. All it does is invalidating the cookie if you update the browser. So you have to log in earlier than expected if the browser string changes. But we could also use a different unique string. We just need a way to differentiate multiple instances of the same user on different devices/browsers so we can look up the correct entry in the database.

Excuse me, could you please explain me why using persistent token value is unsafe in comparison with its changing after every log-in.

@brndt Think of the cookie value as a one-time password. Because that's what it basically is. Simple said - it's a bit more complex in reality. It's actually a two part string with a persistent part and a part that is changing.

@brndt Think of the cookie value as a one-time password. Because that's what it basically is. Simple said - it's a bit more complex in reality. It's actually a two part string with a persistent part and a part that is changing.

Yes but if somebody steal your current remember-me cookie (how, if you use https?) he can still use it whether Joomla changes it every time when user log-in or not. Just as in the case with the real password which you don't change every time.

If someone steals the cookie from your computer and uses it, then yes. He still has to use the same browser or fake the correct UA String. But yes, that's the risk you take by using the remember-me feature. However it will only work as long as the original user doesn't try to login as well. If that happens, both cookies will be invalidated and a regular login is required for both user (orginal and hacker).
Also if you manually log out from the site, all cookies for all browsers will be invalidated.

The one-time part is required to prevent brute-forcing. As that would be rather simple otherwise.
With the remember-me you have exactly one try to log in. If that fails, the cookie is useless. That part is actually more safe than the user/password login ?

That beside, if you use a persistent value, you could as well just write the user/password into the cookie and log in with that. It would be exactly the same. I think you see that this isn't a good idea.

The one-time part is required to prevent brute-forcing. As that would be rather simple otherwise.
With the remember-me you have exactly one try to log in. If that fails, the cookie is useless. That part is actually more safe than the user/password login

Maybe we should set a fixed amount of trying (for example, 3 or 5) to log in by adding a counter to DB. If somebody has N numbers of fails, the algorithm has to invalidate the token. Are you referring to this code?

Anyway, in this case it doesn't depend on type of cookie (permanent or one-time), is it?

That beside, if you use a persistent value, you could as well just write the user/password into the cookie and log in with that. It would be exactly the same. I think you see that this isn't a good idea.

I don't see any difference between persistent and one time value from this point of view. If you somehow steal a current cookie and can get UA String, you can manage to log in regardless of type of cookie. In both cases, remember-me cookie is the equivalent of password.

Sorry if i'm wrong, just trying to help.

just a note: you can write a custom authentication plugin for your specific case, wich will work for your mobile-webview.

Maybe we should set a fixed amount of trying (for example, 3 or 5) to log in by adding a counter to DB. If somebody has N numbers of fails, the algorithm has to invalidate the token. Are you referring to this code?

No. It's fundamental from a security view that it works only once.

I don't see any difference between persistent and one time value from this point of view. If you somehow steal a current cookie and can get UA String, you can manage to log in regardless of type of cookie. In both cases, remember-me cookie is the equivalent of password.

If someone steals your user/password or a persistent value, he could login as many times as he wants with it, and we or the user will not notice it at all.
However with the current implementation, it will invalidated as soon as the original user logs in. That's the whole point. Changing that is absolutely not acceptable.

Beside this discussion, isn't there a no prefetch header/ attribute?

isn't there a no prefetch header/ attribute?

I think problem described in original message is not a core issue , but issue of the tamplate/extensions used on that site,
<link rel="prefetch" .. (or headers) should not be added for "preload" any kind of login page

Beside this discussion, isn't there a no prefetch header/ attribute?

To my knowledge, there are browsers which send such a header (Safari and Firefox, each a different one) and browsers which don't (eg Chrome). So there is no standard yet and no secure way to detect a prefetch.
Of course it could be done for the browsers which send a header, if someone is willing to do that. In that case, you would just have to ignore the authentication request in the cookie plugin and return before doing anything else.

Hi there. I spent a couple of months studying this issue on the following platforms: 1. Desktop Browsers, 2. Webkit/Chrome for Android App, 3. Windows 10 App.

In the customer’s scenario they use one Joomla Platform for the above implementations. On all 3 of them the current implementation of Remember Me is problematic, whether its Browser prefetching or the Version of the browser changing. It occurs a lot more regularly in case 2) due to more regular version changes, but it also happens on 1). I do think this is an issue that needs to be addressed. Some of the users’ feedback on the App was that they don’t use the app because they need to log in too regularly, don’t remember their password and need to go through “reset password” process .

I also hear you on the security risks, but in their implementation the user has very basic rights (lower risk if cookie is lost) and very strict rules for admins which obviously doesn’t use Remember Me. In their case the suggestion made of having an option at Joomla backend to choose your implementation would be nice.

From: Thomas Hunziker notifications@github.com
Sent: Tuesday, 31 December 2019 12:02
To: joomla/joomla-cms joomla-cms@noreply.github.com
Cc: corne ccvdwalt@gmail.com; Author author@noreply.github.com
Subject: Re: [joomla/joomla-cms] cookies / remember issues on webview mobile platforms (#26386)

@HLeithner https://github.com/HLeithner You don't have to fix the function. It's not really a big issue. All it does is invalidating the cookie if you update the browser. So you have to log in earlier than expected if the browser string changes. But we could also use a different unique string. We just need a way to differentiate multiple instances of the same user on different devices/browsers so we can look up the correct entry in the database.

Excuse me, could you please explain me why using persistent token value is unsafe in comparison with its changing after every log-in.

@brndt https://github.com/brndt Think of the cookie value as a one-time password. Because that's what it basically is. Simple said - it's a bit more complex in reality. It's actually a two part string with a persistent part and a part that is changing.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/joomla/joomla-cms/issues/26386?email_source=notifications&email_token=ACDGKI7M7RJ4IFB5IDH3AHTQ3MKCNA5CNFSM4IZHA4X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH4ABMI#issuecomment-569901233 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDGKI4PMLRJ6PUHGQBWGEDQ3MKCNANCNFSM4IZHA4XQ .

It is quite standard behavior with most websites and web-platform that you regularly have to login again. Especially after website upgrades and browser upgrades. I see this as reasonable and needed security and a non-issue.

there is no security gain because the ShortHashedUserAgent is based on the browser user-agent and is part of the cookie name. If someone get the cookie he/she has the ShortHashedUserAgent token too and can generate the browser agent based on this information. In case of a mitm the browser agent is known too.

Removing all numbers in the ShortHashedUserAgent and add the site "secret" key to the mix would makes more sense and should reduces the problem. We already remove the browser version from the hash.

Just to be clear, since there seems to be some confusion: The browser name (= cookie name) is just an identifier (a bit comparable to username but specific to the browser). It doesn't need to be secure. Mixing it with the site secret doesn't add any value.
But it needs to be unique enough so you can differentiate the various instances on the server side. So if a user logs in with Chrome on Desktop and Chrome on his Android, it needs to be a different string. We use this string to lookup the expected token/series in the database table (#__user_keys).
Afaik it already fails if Chrome on your PC at home has the same UA String as Chrome on your work PC. You can't be logged in at both PC/browsers at the same time, it will invalidate it each time.

If we can use a different identifier which is unique enough, or maybe even more unique, then it's simple to change that. However taking the numbers away from the browser user-agent will likely not help as it just raises other issues.

I agree it's about finding a unique identifier. You can run multiple versions on chrome on the same machine (e.g. https://blog.chromium.org/2017/08/run-multiple-versions-of-chrome-side-by.html) which this would then mean you're logged in on the same device with. Honestly I'm not totally happy just removing the versions - but I would also be open to alternative suggestions of something unique enough.

you do realise that the browsers are all moving away from having any user agent strings!

I read it more like they were going to keep them more static? Rather than outright remove?

src https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ

So if that gets implemented we would eventually need to adapt the code to UA-CH https://wicg.github.io/ua-client-hints/ if I read that correctly.
Important is that they don't remove the UA string, only freeze it. So we can still use it for now.

Anyway: If we find another identifier unique enough, we can always change it. We are not fixed to the UA string, it was just the simplest available at the time ?

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features.

As this issue doesn't relate to Joomla 4 it will now been closed.

If we are mistaken and this does apply to Joomla 4 please open a new issue (and reference this one if you wish) with updated details for testing in Joomla 4.
cc @zero-24