Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Current parsec implementation decription has many steps :
- server send an Initial handshake packet
- Client send an Handshake response packet.
- receiving an Authentication Switch Request packet with 'parsec' plugin type with a 32-byte server random scramble
- if the ext-salt was specified in the .my.cnf, the client skips go to step 6, otherwise it sends the user name (and nothing else) to the server
- Server sends the ext-salt to the client
- Client sends the random 32-byte scramble, and the concat(server scramble, client scramble) ed25519-signed by a secret key generated from the PBKDF2(password, ext-salt)
- Server replies with "ok" or "acces denied"
most connectors are using pool configured, with one user, and ext-salt is fixed for a user ( until password change), so for any new connection, after a successful authentication, ext-salt can be cached.
Sending an empty packet requesting to ext-salt is actually mandatory: if ext-salt is known by connector, and go directly to step 6, connection fails.
second point concerns when https://jira.mariadb.org/browse/MDEV-12320 default authentication permitting parsec will be done:
if connector cache the ext-salt that is specific to the user, exchanges can be faster :
- server send an Initial handshake packet with 'parsec' default authentication and 32-byte server random scramble
- Client can directly send the random 32-byte scramble, and the concat(server scramble, client scramble) ed25519-signed by a secret key generated from the PBKDF2(password, ext-salt)
- Server replies with "ok" or "acces denied"
Attachments
Issue Links
- relates to
-
MDEV-32618 PARSEC Authentication Plugin
- Closed