After the keynote, many people were wondering how long the new system will remain "experimental". I've been thinking about this for the past weeks and I want to work hard to make 5.3 the first stable release of the new system.
This would give us 1 release (5.4) to add features and fixes that people find when migrating to the new system. In 6.0, the old system will be removed and thus the new system must fill all gaps of the old system. While I highly recommend people to test the new security system, I can completely understand people not to upgrade their large production applications to an experimental feature.

This brings an important deadline, as it means the upcoming 6 months are the last months we can "fix security" while breaking BC. Personally, I've 3 security goals left that I think may result in BC breaks:

• Refactor the remember me system
• At some knowledge of authentication factors (sudo mode)
• Revisit UserInterface

Refactor the remember me system, see ☑️ #40145

Goal: Have the system work automatically and extracting the storage (persistent token, etc) from the logic that determines if remember me should be used (mostly AbstractRememberMeServices)

The current remember me system requires lots of manual interactions (calling loginSuccess(), loginFailure(), autoLogin() on exactly the correct cases every time). We should use the new events (and probably add a few new ones) in order to let it run automatically at the correct cases.

Also, currently it is almost impossible to customize when remember me should be activated (e.g. in 2fa situations). The AbstractRememberMeServices logic should be extracted from the services and into a new class to allow customization.

For some background on this topic:

• [Security] AuthenticatorManager to make "authenticators" first-class security #33558 (comment)
• https://github.com/scheb/symfony/pull/1/files#diff-d678875988dcd92beec6cc4711ce8cc963265002fd5708a011607b2fb24baf4e

At some knowledge of authentication factors (sudo mode)

Goal: Add the idea of "authentication factors" (i.e. being authenticated using 1 factor may not be considered "fully authenticated" if 2fa is required)

We already have https://github.com/scheb/2fa as a great solution for mfa in Symfony. I don't think we should replace it, but there are some things that we still have to refactor in Symfony to make the bundle work nicer (instead of working around the current limitations). @weaverryan, @scheb and I have had a discussion about this on Slack with this as some sort of conclusion: https://gist.github.com/weaverryan/d828ef860b1119862cf3828d016b8f41 This is anything but a final conclusion, but it can be used as a reference for the work on this subject.

Revisit UserInterface, see ☑️ #40267 & #40403

Goal: remove credential related methods (getSalt(), getPassword(), eraseCredentials()) from the main UserInterface

These methods are becoming "outdated" (salts are autogenerated in bcrypt/libsodium and passwordless authentication is becoming more and more common). There still is a need to have a "security user" (or principal). Ideally, we also rename getUsername() to a more generic method (getIdentifier() or the like). This change does require to remain BC as it's also used in the old system (or can we somehow have a new-system only user interface?)

I would be interested to connect with people that can help with these tasks. At the same time, I'm also interested in peoples opinion on the ideas of this issue.
If you have great idea for Security, please note that there is a larger meta issue: #30914 This issue is a subset of that issue, to cover only the changes that require the current component to still be "experimental".