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

Modern alternative to the SHA1 authentication plugin

Details

    • 10.1.22

    Description

      Authentication plugin that

      • uses a crypto-hash that is considered secure nowadays
      • does not allow to get the password even if mysql.user is read and the authentication exchange is intercepted
      • as easy to use as native_mysql_authentication plugin, no public/private key files or anything
      • pure plugin

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            Probably to help define what is it is, uses:

            • Slave to master authentication
            • Application to mariadb server authentication for web scripts etc

            Rough thoughts:

            Registration:

            1. Using modern authentication, the first use creates a registration with the server with the server and saves one side of the authentication (as a local file) and the server saves the other side (in the users table).
            2. The user is created without permissions
            3. A server administrator with existing permissions creates grants for the user
            4. "Change Master TO" could also use the same registration if PASSWORD was made optional (could help simplify the easiest part of MDEV-7502)
            5. Todo - optional MITM registration protection
              ( Assumptions: database servers are installed in network environments where the risk of a DoS though registration is low, however its not totally risk free and a post process to enable the registration is required )

            Connection:

            1. The client connection will mmap the file used in registration and will use DH aspects of a key exchange to prevent MITM
            2. A shared secret will be provided to the client and stored in shared memory (mmap MAP_SHARED) with the other process by the client plugin using the same user (i.e. php-fpm, and equivalent for other languages)

            Subsequent connections:

            1. use a HMAC based authentication from the shared secret in shared memory (for CPU speed in computation and less exchanges compared to DH)
            danblack Daniel Black added a comment - Probably to help define what is it is, uses: Slave to master authentication Application to mariadb server authentication for web scripts etc Rough thoughts: Registration: Using modern authentication, the first use creates a registration with the server with the server and saves one side of the authentication (as a local file) and the server saves the other side (in the users table). The user is created without permissions A server administrator with existing permissions creates grants for the user "Change Master TO" could also use the same registration if PASSWORD was made optional (could help simplify the easiest part of MDEV-7502 ) Todo - optional MITM registration protection ( Assumptions: database servers are installed in network environments where the risk of a DoS though registration is low, however its not totally risk free and a post process to enable the registration is required ) Connection: The client connection will mmap the file used in registration and will use DH aspects of a key exchange to prevent MITM A shared secret will be provided to the client and stored in shared memory (mmap MAP_SHARED) with the other process by the client plugin using the same user (i.e. php-fpm, and equivalent for other languages) Subsequent connections: use a HMAC based authentication from the shared secret in shared memory (for CPU speed in computation and less exchanges compared to DH)

            I'm currently just looking to replace SHA1-based password auth. So the new one should do the same — get the password from the client to the server, so that the server could compare it, without actually seeing or storing the password.

            I'd rather avoid saving files on the server or client side, I think it complicates usage.

            btw, my working prototype uses ed25519.

            serg Sergei Golubchik added a comment - I'm currently just looking to replace SHA1-based password auth. So the new one should do the same — get the password from the client to the server, so that the server could compare it, without actually seeing or storing the password. I'd rather avoid saving files on the server or client side, I think it complicates usage. btw, my working prototype uses ed25519.

            People

              serg Sergei Golubchik
              serg Sergei Golubchik
              Votes:
              1 Vote for this issue
              Watchers:
              4 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.