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

password encoding

Details

    • Task
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      When creating/updating a password, those are crypted in some hash based on socket passwords bytes value.
      These password's bytes depend on current charset connection (@@character_set_client).

      When driver try to established a new connection, authentication use driver current charset, that might be different than the one used when creating/update this password.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. CONJ-212 Implement password encoding charset option

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment -

            Possible approaches:

            • convert passwords to a fixed character set, e.g. utf8. Problems:
              • existing password hashes becomes invalid
              • passwords must consist of valid characters, arbitrary binary passwords are no longer possible
            • remember character set per password. Problem:
              • extra round-trip to send this charset to the client during handshake
            • something complex, like remember a charset per password (but remember ascii, if the repertoire fits), only do a second round-trip if the charset is not ascii. Problems:
              • over-engineering
              • needs to be careful not to disclose any information if the password is wrong
            serg Sergei Golubchik added a comment - Possible approaches: convert passwords to a fixed character set, e.g. utf8. Problems: existing password hashes becomes invalid passwords must consist of valid characters, arbitrary binary passwords are no longer possible remember character set per password. Problem: extra round-trip to send this charset to the client during handshake something complex, like remember a charset per password (but remember ascii, if the repertoire fits), only do a second round-trip if the charset is not ascii. Problems: over-engineering needs to be careful not to disclose any information if the password is wrong
            wlad Vladislav Vaintroub added a comment - - edited

            I do not think passwords should ever be arbitrary binary blobs.
            They are typed on the terminals, n Web pages, passed as command line arguments (and thus, in Windows world have to be convertable to and from Unicode), and exists in different non-C API , and one would be hard pressed to find a non-C language, where string is arbitrary bytes.

            If someone needs to pass non-string , certificate or whatever to a hashing function, on the client, there are hex or base64 conversions, which make ASCII/UTF-8 out of anything.

            A possible approach could be that server will start returning error, when CREATE USER or SET PASSWORD with invalid UTF8 was used for PASSWORD() function. And CLI starts issuing a warning if it used non-UTF8 to compute the hash . Warning will encourage user to change password maybe to ASCII (such a warning is not likely happen in UTF-8 aware environments).

            Then, after a grace period of 10 to 20 years, one could maybe assume passwords are all in UTF-8.

            wlad Vladislav Vaintroub added a comment - - edited I do not think passwords should ever be arbitrary binary blobs. They are typed on the terminals, n Web pages, passed as command line arguments (and thus, in Windows world have to be convertable to and from Unicode), and exists in different non-C API , and one would be hard pressed to find a non-C language, where string is arbitrary bytes. If someone needs to pass non-string , certificate or whatever to a hashing function, on the client, there are hex or base64 conversions, which make ASCII/UTF-8 out of anything. A possible approach could be that server will start returning error, when CREATE USER or SET PASSWORD with invalid UTF8 was used for PASSWORD() function. And CLI starts issuing a warning if it used non-UTF8 to compute the hash . Warning will encourage user to change password maybe to ASCII (such a warning is not likely happen in UTF-8 aware environments). Then, after a grace period of 10 to 20 years, one could maybe assume passwords are all in UTF-8.

            People

              Unassigned Unassigned
              diego dupin Diego Dupin
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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