Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-12321

authentication plugin: SET PASSWORD support

Details

    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

          Activity

            serg Sergei Golubchik created issue -
            serg Sergei Golubchik made changes -
            Field Original Value New Value
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            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}
            serg Sergei Golubchik made changes -
            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}
            serg Sergei Golubchik made changes -
            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}
            serg Sergei Golubchik made changes -
            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}
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10.4 [ 22408 ]
            Fix Version/s 10.3 [ 22126 ]
            serg Sergei Golubchik made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            Assignee Sergei Golubchik [ serg ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Assignee Vladislav Vaintroub [ wlad ]
            julien.fritsch Julien Fritsch made changes -
            Epic Link PT-73 [ 68549 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Rank Ranked higher
            serg Sergei Golubchik made changes -
            Assignee Vladislav Vaintroub [ wlad ] Sergei Golubchik [ serg ]
            serg Sergei Golubchik made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            serg Sergei Golubchik made changes -
            Status In Progress [ 3 ] Stalled [ 10000 ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Vicentiu Ciorbaru [ cvicentiu ]
            Status Stalled [ 10000 ] In Review [ 10002 ]
            cvicentiu Vicențiu Ciorbaru made changes -
            Assignee Vicentiu Ciorbaru [ cvicentiu ] Sergei Golubchik [ serg ]
            Status In Review [ 10002 ] Stalled [ 10000 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.4.0 [ 23115 ]
            Fix Version/s 10.4 [ 22408 ]
            Resolution Fixed [ 1 ]
            Status Stalled [ 10000 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            GeoffMontee Geoff Montee (Inactive) made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 80066 ] MariaDB v4 [ 133188 ]

            People

              serg Sergei Golubchik
              serg Sergei Golubchik
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.