Skip to content

[Security] Extract password hashing from security-core - with proper wording #39802

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.

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

Merged
merged 1 commit into from
Feb 12, 2021

Conversation

chalasr
Copy link
Member

@chalasr chalasr commented Jan 12, 2021

Q A
Branch? 5.x
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fixes #39698
License MIT
Doc PR todo

This PR renames password "encoders" to password hashers (naming widely used, see e.g. django or laravel).
This also takes the opportunity to extract the logic related to password hashing from security-core, moving it to a new password-hasher component.
Nowadays, many modern web apps and APIs don't deal with passwords at all, that's why splitting makes sense as a step towards making security-core not tied to the password concept.

For upgrading, applications will have to use passwords_hashers instead of encoders in their security configuration, and type-hint against PasswordHasherInterface (and related) instead of PasswordEncoderInterface.

The proposed API is not much different from the encoder one regarding behavior and signatures, and it is slightly more close to the PHP built-in password hashing API:

namespace Symfony\Component\PasswordHasher;

interface PasswordHasherInterface
{
    public function hash(string $plainPassword): string;

    public function verify(string $hashedPassword, string $plainPassword): bool;

    public function needsRehash(string $hashedPassword): bool;
}

@chalasr chalasr force-pushed the password-hasher branch 2 times, most recently from ed07ff3 to 1dd61cc Compare January 12, 2021 18:15
@derrabus
Copy link
Member

I like the idea of moving password hasing out of security-core. Would it make sense to create a contracts package for the new hasher interfaces?

@stof
Copy link
Member

stof commented Jan 12, 2021

I don't think these interfaces need to be in contracts. HasherInterface is not something you would typehint anyway most of the time (you need the factory to get the right hasher for that user class).
And HasherFactoryInterface is not really a contract that make sense to reimplement outside symfony/security-* as it depends on other concepts there. So to me, there is no reason to use the interfaces without also using the component itself.

@chalasr chalasr force-pushed the password-hasher branch 4 times, most recently from 7203a1e to b40a7e0 Compare January 12, 2021 21:18
@goetas
Copy link
Contributor

goetas commented Jan 13, 2021

A note on the interface implementation, it happened multiple times that the neeed for a re hashing of a password was something depended on the user/token holding it, not just the password itself. Would it be possible to talke that into consideration somehow?

@chalasr chalasr force-pushed the password-hasher branch 4 times, most recently from b39ced8 to b6ed024 Compare January 15, 2021 11:37
chalasr added a commit that referenced this pull request Jan 16, 2021
…TypeDeclarationsPass (chalasr)

This PR was merged into the 4.4 branch.

Discussion
----------

[DependencyInjection] Skip deprecated definitions in CheckTypeDeclarationsPass

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

When a definition uses a deprecated class , `CheckTypeDeclarationsPass` (with `$autoload = true`) will autoload the class, which triggers a deprecation notice. That breaks the CI in #39802 because the compiler pass is registered inside the SecurityBundle test suite.
I propose to stop checking deprecated definitions. Makes sense?

Commits
-------

531c81a [DI] Skip deprecated definitions in CheckTypeDeclarationsPass
Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Good to me, once UPGRADE files are updated :)

@wouterj
Copy link
Member

wouterj commented Feb 12, 2021

Thanks a lot @chalasr! I can't wait to see all the deprecated stuff be removed in 6.0 :)

@wouterj wouterj merged commit c757845 into symfony:5.x Feb 12, 2021
@chalasr chalasr deleted the password-hasher branch February 12, 2021 16:02
@localheinz localheinz mentioned this pull request Feb 14, 2021
1 task
chalasr added a commit that referenced this pull request Feb 14, 2021
…for "native" and "auto" (chalasr)

This PR was merged into the 5.3-dev branch.

Discussion
----------

[PasswordHasher] Use bcrypt as default hash algorithm for "native" and "auto"

| Q             | A
| ------------- | ---
| Branch?       | 5.x
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

As suggested in #39802 (comment),  based on https://twitter.com/TerahashCorp/status/1155129705034653698

Commits
-------

332817a Use bcrypt as default password hash algorithm for "native" and "auto"
symfony-splitter pushed a commit to symfony/password-hasher that referenced this pull request Feb 14, 2021
…for "native" and "auto" (chalasr)

This PR was merged into the 5.3-dev branch.

Discussion
----------

[PasswordHasher] Use bcrypt as default hash algorithm for "native" and "auto"

| Q             | A
| ------------- | ---
| Branch?       | 5.x
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

As suggested in symfony/symfony#39802 (comment),  based on https://twitter.com/TerahashCorp/status/1155129705034653698

Commits
-------

332817ac29 Use bcrypt as default password hash algorithm for "native" and "auto"
chalasr added a commit that referenced this pull request Mar 5, 2021
…ions (chalasr)

This PR was merged into the 5.3-dev branch.

Discussion
----------

[Security] Re-add accidentally removed property declarations

| Q             | A
| ------------- | ---
| Branch?       | 5.x
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

spotted while playing with psalm locally,  mistake made in #39802

Commits
-------

bccf736 [Security] Readd accidentally removed property declarations
@fabpot fabpot mentioned this pull request Apr 18, 2021
nicolas-grekas added a commit that referenced this pull request Jun 17, 2021
…dEncoder (derrabus)

This PR was merged into the 5.3 branch.

Discussion
----------

[Security] Restore extension point in MessageDigestPasswordEncoder

| Q             | A
| ------------- | ---
| Branch?       | 5.3
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | #41696 (comment)
| License       | MIT
| Doc PR        | N/A

Until Symfony 5.2, it was possible to extend `MessageDigestPasswordEncoder` and override the way password and salt are merged. This broke with #39802. I've restored the old logic and added a test case to cover that scenario.

Commits
-------

4568876 [Security] Restore extension point in MessageDigestPasswordEncoder
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Security] Change "Encode" to "Hash" to avoid any confusion
10 participants