Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
authentication plugin: SET PASSWORD support.
The syntax could stay the as before:
SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } |
The PASSWORD() syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function. For example, writing PASSWORD() for the user, who uses mysql_old_password will be the same as using OLD_PASSWORD() function in earlier MySQL/MariaDB versions. OLD_PASSWORD() syntax could stay or, better, could be removed as nobody should be using that plugin anymore.
The same syntax can be used for CREATE USER and GRANT:
CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") |
This makes the standalone PASSWORD function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions:
- Add an optional second argument to specify a plugin, or
- Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues [*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it.
[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that PASSWORD() would use a random salt. Got huge number of complains about PASSWORD() being non-deterministic, it broke all applications where users did, like
SELECT ... FROM user_table WHERE user_name="name_input_field" AND |
user_password=PASSWORD("password_input_field") |
Attachments
Issue Links
- blocks
-
MDEV-12835 Write warning to error log if user's login password is ignored
-
- Closed
-
- causes
-
MDEV-17950 SHOW GRANTS FOR does not work for a user identified with non-existing plugin
-
- Closed
-
- relates to
-
MDEV-11180 CREATE USER .. IDENTIFIED WITH .. BY .. is not supported
-
- Closed
-
-
MDEV-12160 Modern alternative to the SHA1 authentication plugin
-
- Closed
-
-
MDEV-10457 simple_password_check is incompatible with pam
-
- Closed
-
-
MDEV-11340 Allow multiple alternative authentication methods for the same user
-
- Closed
-
Activity
Field | Original Value | New Value |
---|---|---|
Link |
This issue relates to |
Link |
This issue relates to |
Description | authentication plugin: SET PASSWORD support |
authentication plugin: SET PASSWORD support.
The syntax could stay the same: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function, for example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax can stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
Description |
authentication plugin: SET PASSWORD support.
The syntax could stay the same: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function, for example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax can stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
authentication plugin: SET PASSWORD support.
The syntax could stay the as before: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function, for example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax can stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
Description |
authentication plugin: SET PASSWORD support.
The syntax could stay the as before: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function, for example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax can stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
authentication plugin: SET PASSWORD support.
The syntax could stay the as before: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function. For example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax can stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
Description |
authentication plugin: SET PASSWORD support.
The syntax could stay the as before: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function. For example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax can stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
authentication plugin: SET PASSWORD support.
The syntax could stay the as before: {code:sql} SET PASSWORD [ FOR user ] = { "hash" | PASSWORD("password") } {code} The {{PASSWORD()}} syntax will need to use the plugin-specific password hashing callback. There is no need to have per-plugin password hashing function. For example, writing {{PASSWORD()}} for the user, who uses {{mysql_old_password}} will be the same as using {{OLD_PASSWORD()}} function in earlier MySQL/MariaDB versions. {{OLD_PASSWORD()}} syntax could stay or, better, could be removed as nobody should be using that plugin anymore. The same syntax can be used for {{CREATE USER}} and {{GRANT}}: {code:sql} CREATE USER name IDENTIFIED WITH plugin AS PASSWORD("foo") {code} This makes the standalone {{PASSWORD}} function will become somewhat confusing, because it'll use double-SHA1 hashing, it cannot use the "corresponding user's auth plugin", because it's not run in the user context. Possible solutions: * Add an optional second argument to specify a plugin, or * Keep it that way, it's good that one cannot arbitrarily invoke plugin's password hashing function. We've had a lot of issues \[*] before when users tried to use PASSWORD() as a generic password-hashing function for their applications. It is not, it's an internal MariaDB authentication plugin dependent password hashing, only to be used for MariaDB authentication. Not allowing a user to use plugin hashing directly will create less possibilities for abusing it. \[*] In MySQL 4.0.0 (or 4.1.0?) we've tried to salt passwords, so that {{PASSWORD()}} would use a random salt. Got huge number of complains about {{PASSWORD()}} being non-deterministic, it broke all applications where users did, like {code:sql}SELECT ... FROM user_table WHERE user_name="name_input_field" AND user_password=PASSWORD("password_input_field"){code} |
Link |
This issue relates to |
Fix Version/s | 10.4 [ 22408 ] | |
Fix Version/s | 10.3 [ 22126 ] |
Link |
This issue blocks |
Assignee | Sergei Golubchik [ serg ] |
Assignee | Vladislav Vaintroub [ wlad ] |
Epic Link | PT-73 [ 68549 ] |
Rank | Ranked higher |
Assignee | Vladislav Vaintroub [ wlad ] | Sergei Golubchik [ serg ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Status | In Progress [ 3 ] | Stalled [ 10000 ] |
Assignee | Sergei Golubchik [ serg ] | Vicentiu Ciorbaru [ cvicentiu ] |
Status | Stalled [ 10000 ] | In Review [ 10002 ] |
Assignee | Vicentiu Ciorbaru [ cvicentiu ] | Sergei Golubchik [ serg ] |
Status | In Review [ 10002 ] | Stalled [ 10000 ] |
Fix Version/s | 10.4.0 [ 23115 ] | |
Fix Version/s | 10.4 [ 22408 ] | |
Resolution | Fixed [ 1 ] | |
Status | Stalled [ 10000 ] | Closed [ 6 ] |
Link |
This issue causes |
Link |
This issue relates to |
Workflow | MariaDB v3 [ 80066 ] | MariaDB v4 [ 133188 ] |