10000 UserInterface is thightly coupled with password authentication · Issue #28365 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

UserInterface is thightly coupled with password authentication #28365

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Spomky opened this issue Sep 4, 2018 · 3 comments
Closed

UserInterface is thightly coupled with password authentication #28365

Spomky opened this issue Sep 4, 2018 · 3 comments
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed) Security
Milestone
4.4

Comments

@Spomky
Copy link
Contributor
Spomky commented Sep 4, 2018 •
edited
Loading

This is not an issue, but rather a forward-looking discussion about the user authentication topic.

Description
At the moment, the user interface is thighly coupled with an authentication based on a username/password pairs.
This not not a problem at all as 999‰ of the running applications use this authentication method.
However, with the coming Webauthn standard, passwords won’t be needed anymore. This standard allows user to associate an infinite number of security tokens that will mainly communicate through the USB, NFC, Bluetooth or an internal protocol.
Data that is supposed to be stored is credential IDs and associated cryptographic public keys instead of passwords and salts.
Therefore, the methods getPassword, getSalt and all the associated functionalities (e.g. password encoders) will become completely useless.

Possible Solution
This interface and the other classes that use/implement those methods may gradually evolve to take into account this new authentication scheme.
Methods could be renamed into getCredentials or another generic equivalent that is not specifically linked to a password.
In any cases, changes will undoubtedly affect several classes, associated logic (e.g. AbstractToken or SwitchUserListener) and the way application manage their user credentials.

Please, do not hesitate to participate and share here the way you imagine futur authentication architecture.
@curry684
Copy link
Contributor
curry684 commented Sep 4, 2018 •
edited
Loading

This not not a problem at all as 999‰ of the running applications use this authentication method.

This premise is already way off today. In just about every application I've designed and written over the past 2 years I've implemented UserInterface in an Identity class (which is what it should be) and left the getPassword and getSalt methods intentionally empty. The concept of a User itself is of course already way off today in a world of microservices using service/machine accounts and even OAuth2 being extended with Device Flow to support headless IoT devices. .NET actually got this right mostly with their notion of Principals rather than Users.

The issue has been discussed before that the authentication part of Symfony Security component is rather archaic and outdated (not authorization which is, apart from some painful bug-inviting design choices in Voter, generally fine). Specifically I recommend you read #21029 to the end, especially from my comment at #21029 (comment)

However I do think that issue should not have been closed at the time as the underlying issue is currently, months later, still not fixed or to my knowledge fundamentally being refactored into 2018 authentication paradigms, and 5.x is nearing fast if we want to do really breaking stuff.

I suggest we start a Project on this to get to a future proof implementation in time for 5.0 next year.

@chalasr chalasr added Security RFC RFC = Request For Comments (proposals about features that you want to be discussed) labels Sep 5, 2018
@javiereguiluz javiereguiluz added this to the next milestone Sep 5, 2018
@xabbuh
Copy link
Member
xabbuh commented Sep 6, 2018

Thanks for the issue, but I think we should continue in #23081. :)

@xabbuh xabbuh closed this as completed Sep 6, 2018
@Spomky
Copy link
Contributor Author
Spomky commented Sep 6, 2018

Hi @curry684, I was way off the reality. Thank you for the links, I was not aware of ongoing discussions about this topic. Let's continue there.

@nicolas-grekas nicolas-grekas modified the milestones: next, 4.4 Oct 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed) Security
Projects
None yet
Milestone
4.4
Development

No branches or pull requests
6 participants
@javiereguiluz @nicolas-grekas @Spomky @curry684 @xabbuh @chalasr
0