TYPO3 Core

I agree.

Here are the reasons:

1. With the extension the password transmission is the only thing that is encrypted
2. Even though the transmission is encrypted, the public key exchange from server to client is not authenticated. This means an attacker in the middle can hand out a bogus public key to the client, which means that the password will then be encrypted with the key of the attacker
3. Session ids via cookies are still transferred unencrypted. Since (valid) session ids are almost as valuable as passwords, jumping through hoops to protect the password, but keeping the session id unencrypted, seems irrational (and is insecure).

What I see as task list in early phase of 9.0 development:

• do not install rsaauth by default any more
• add report in security section that issues a warning in following conditions: SSL is not enforced, rsaauth is active
• add deprecation messages on login with rsaauth

Task list for early 10.0 development:

• remove all checks for this in JS and PHP
• remove rsaauth and move it to TER

Many small clients still want to use http instead of https. With rsaauth TYPO3 is secure out of the box. It is strange to hear arguments to make the system less secure...

I'm with Dmitry here.
I just don't understand the reasoning.

http-only: worst
http + rsaauth: better
https: goal

Considering that many big hosting providers still do not provide https for free, http+rsaauth still is an advantage over http-only.
Yes, it causes quite some headaches in the Core code, to maintain and keep rsaauth working, but still, no reason to throw that away.

Dmitry Dulepov wrote:

Many small clients still want to use http instead of https.

Markus Klein wrote:

Considering that many big hosting providers still do not provide https for free

Unfortunately still correct nowadays

Markus Klein wrote:

http+rsaauth still is an advantage over http-only

This is also correct.

It is also correct that a four character password is more secure than a two letter password.
But: It does not turn a four character password into a secure password.

Dmitry Dulepov wrote:

With rsaauth TYPO3 is secure out of the box.

That is why I consider this statement to not be true (any more), regarding authenticated sessions.
A TYPO3 installation is not secure enough, when being delivered over http even when rsaauth is enabled.

The intention of this change is communicate exactly that. With not having SSL enabled, your site is not secure enough (nowadays).
This point of view is supported by major browser vendors like Firefox and Chrome, as they started to issue warnings when the page is delivered over http
and in the near future (which is a matter of weeks not months) these warnings will become even more prominent.

Google also already started to make a statement on that, by lower the ranking of not https enabled sites.

That said, and respecting the time frame when browsers will change to show prominent warnings (within the course of this year) and the time frame of removing rsaauth from the core (in 3-4 years), I think it is a logical step to deprecate an insecure setup with the release of TYPO3 9LTS in 1,5 years.

There are many hosters that have letsencrypt certificates for free already in very cheap hosting plans.
Having SSL enabled for your website won't be optional very soon, which is a good thing and is nothing we as CMS vendor can (or should) ignore.

Sorry Helmut, but removing a feature to make an installation even more insecure is then even less the way to go.
Following your reasoning the right way would be to deprecate http usage completely.

But: It does not turn a four character password into a secure password.

Removing rsaauth does not make the Core a more secure product either.

Honestly, I want this topic discussed at least within the Core Team and not just within this ticket here.

Markus Klein wrote:

Sorry Helmut, but removing a feature to make an installation even more insecure is then even less the way to go.
Following your reasoning the right way would be to deprecate http usage completely.

Yes, this is the intention indeed.

Current state:

• http without rsaauth: warning in reports module
• http with rsaauth: no warning (ignoring all sorts of still present security issues)

Desired state:

• http: warning in reports module to use https

But: It does not turn a four character password into a secure password.

Removing rsaauth does not make the Core a more secure product either.

True. What is making the core more secure is giving a clear hint that the only way to secure a website is to use https
and not let people think it is secure enough with using rsaauth.

Honestly, I want this topic discussed at least within the Core Team and not just within this ticket here.

I'm fine with that.

Helmut Hummel wrote:

Desired state:
http: warning in reports module to use https

What about:

• http without rsaauth: warning in reports module that the system is totally insecure
• http with rsaauth: warning in report module that the system is only partially secured (*) and suggest to use https

Honestly, I want this topic discussed at least within the Core Team and not just within this ticket here.

I agree too. The decision platform should be the right place IMO.

(*) I know the objection: security is like a chain, it's as strong as the weakest of its rings, so "partially secured" is like "no secure at all"

Okay. I'm with you with the desired goal!
So warnings are in BE are totally fine.

To be sure about the action plan:

• Add warnings to reports module
• Keep rsaauth in action as it was

I would not remove/deprecate rsaauth until http is disabled on the internet (or so ;-)).