[MDEV-32618] PARSEC Authentication Plugin - Jira

Sergei Golubchik created issue - 2023-10-29 18:27

Sergei Golubchik made changes - 2023-10-29 18:28

Field	Original Value	New Value
Description	New auth plugin: * uses KDF * salted * uses server- and client-side scrambles * set as default auth plugin * ed25119 based?	New auth plugin: * uses KDF * salted * uses server- and client-side scrambles * set as default auth plugin * ed25119 based? verify that if client has mysql_native_password as default, there's no extra roundtrip

Sergei Golubchik made changes - 2023-10-29 20:28

Description

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25119 based?

verify that if client has mysql_native_password as default, there's no extra roundtrip

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

verify that if client has mysql_native_password as default, there's no extra roundtrip

Sergei Golubchik made changes - 2023-11-06 09:50

Description

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

verify that if client has mysql_native_password as default, there's no extra roundtrip

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

reduce roundtrips:
* set is as default
* allow clients to provide the salt (--plugin-salt=XXX). if it's incorrect — connection fails.

Sergei Golubchik made changes - 2023-11-06 09:51

Description

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

reduce roundtrips:
* set is as default
* allow clients to provide the salt (--plugin-salt=XXX). if it's incorrect — connection fails.

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX). if it's incorrect — connection fails.

Sergei Golubchik made changes - 2023-11-06 09:51

Description

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX). if it's incorrect — connection fails.

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Sergei Golubchik made changes - 2023-11-06 09:52

Description

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Sergei Golubchik made changes - 2023-12-01 16:36

Issue Type

Task [ 3 ]

New Feature [ 2 ]

Sergei Golubchik made changes - 2023-12-07 14:16

Component/s

Protocol [ 14604 ]

Sergei Golubchik made changes - 2023-12-07 15:07

Description

New auth plugin:
* uses KDF
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based?
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Sergei Golubchik made changes - 2023-12-10 15:45

Assignee

Sergei Golubchik [ serg ]

Vladislav Vaintroub [ wlad ]

Vladislav Vaintroub made changes - 2023-12-21 01:15

Status

Open [ 1 ]

In Progress [ 3 ]

Sergei Golubchik made changes - 2023-12-22 17:45

Fix Version/s		11.5 [ 29506 ]
Fix Version/s	11.4 [ 29301 ]

Vladislav Vaintroub made changes - 2024-01-15 17:54

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Rough idea
* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2],

Vladislav Vaintroub made changes - 2024-01-15 17:56

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Rough idea
* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2],

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Rough idea
* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET

Vladislav Vaintroub made changes - 2024-01-15 20:51

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

Rough idea
* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(XOR(server_scramble,client_scramble), derived_key))

4. client looks that AES_DECRYPT(ServerVerificationResponse, derived_key) = XOR(server_scramble,client_scramble) .
     If they match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(XOR(hash_func(password), XOR(server_scramble^client_scramble),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password= XOR(tmp, XOR(server_scramble^client_scramble))
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

Vladislav Vaintroub made changes - 2024-01-15 20:51

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(XOR(server_scramble,client_scramble), derived_key))

4. client looks that AES_DECRYPT(ServerVerificationResponse, derived_key) = XOR(server_scramble,client_scramble) .
     If they match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(XOR(hash_func(password), XOR(server_scramble^client_scramble),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password= XOR(tmp, XOR(server_scramble^client_scramble))
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(XOR(server_scramble,client_scramble), derived_key))

4. client looks that AES_DECRYPT(ServerVerificationResponse, derived_key) = XOR(server_scramble,client_scramble) .
     If they match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(XOR(hash_func(password), XOR(server_scramble^client_scramble),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password= XOR(tmp, XOR(server_scramble^client_scramble))
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

Vladislav Vaintroub made changes - 2024-01-15 21:38

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(XOR(server_scramble,client_scramble), derived_key))

4. client looks that AES_DECRYPT(ServerVerificationResponse, derived_key) = XOR(server_scramble,client_scramble) .
     If they match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(XOR(hash_func(password), XOR(server_scramble^client_scramble),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password= XOR(tmp, XOR(server_scramble^client_scramble))
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

Sergei Golubchik made changes - 2024-01-16 09:40

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

Daniel Black made changes - 2024-01-30 09:47

Remote Link

This issue links to "OWASP Password Storage Cheat Sheet (Web Link)" [ 36383 ]

Sergei Golubchik made changes - 2024-02-13 10:01

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Sergei Golubchik made changes - 2024-02-13 12:14

Assignee

Vladislav Vaintroub [ wlad ]

Sergei Golubchik [ serg ]

Sergei Golubchik made changes - 2024-02-13 16:41

Assignee

Sergei Golubchik [ serg ]

Nikita Malyavin [ nikitamalyavin ]

Nikita Malyavin made changes - 2024-03-05 14:53

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Sergei Golubchik made changes - 2024-03-07 14:16

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

{panel:title=first idea}

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

Sergei Golubchik made changes - 2024-03-07 14:44

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

{panel:title=first idea}

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=first idea|collapse}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

Sergei Golubchik made changes - 2024-03-07 15:37

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=first idea|collapse}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{noformat}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{noformat}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt* in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

Sergei Golubchik made changes - 2024-03-07 15:37

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{noformat}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{noformat}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt* in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{noformat}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{noformat}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt*, in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

Sergei Golubchik made changes - 2024-03-07 15:38

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{noformat}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{noformat}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt*, in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{code:sql}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{code}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt*, in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

Nikita Malyavin made changes - 2024-03-13 21:29

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Ralf Gebhardt made changes - 2024-03-19 10:32

Fix Version/s		11.6 [ 29515 ]
Fix Version/s	11.5 [ 29506 ]

Nikita Malyavin made changes - 2024-05-13 11:04

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Nikita Malyavin made changes - 2024-05-27 11:59

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Nikita Malyavin added a comment - 2024-06-04 12:12 - edited

The estimate is updated with regard to the roadmap, which is set below:

MVP
Set as default plugin
➡️ Make use of system's crypto provider
Reduce roundtrips with ext-salt provided through client's config

Nikita Malyavin added a comment - 2024-06-04 12:12 - edited The estimate is updated with regard to the roadmap, which is set below: MVP Set as default plugin ➡️ Make use of system's crypto provider Reduce roundtrips with ext-salt provided through client's config

Nikita Malyavin made changes - 2024-06-04 15:15

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Sergei Golubchik made changes - 2024-06-11 21:59

Link

This issue is part of TODO-4765 [ TODO-4765 ]

markus makela made changes - 2024-06-13 10:28

Link

This issue relates to ~~MXS-5130~~ [ ~~MXS-5130~~ ]

markus makela added a comment - 2024-06-13 10:31 - edited

Would it be possible to (eventually) document the authentication protocol here? https://mariadb.com/kb/en/connection/#plugin-list

markus makela added a comment - 2024-06-13 10:31 - edited Would it be possible to (eventually) document the authentication protocol here? https://mariadb.com/kb/en/connection/#plugin-list

Nikita Malyavin added a comment - 2024-06-13 11:10

It should!

Nikita Malyavin added a comment - 2024-06-13 11:10 It should!

Nikita Malyavin made changes - 2024-06-13 11:10

Attachment

noname [ 73630 ]

Sergei Golubchik made changes - 2024-06-14 09:20

Link

This issue relates to MDEV-12320 [ MDEV-12320 ]

Sergei Golubchik made changes - 2024-06-14 09:21

Description

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{code:sql}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{code}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt*, in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

New auth plugin:
* uses KDF (try to use what openssl provides)
* salted
* uses server- and client-side scrambles
* set as default auth plugin
* ed25519 based? (or try to use what openssl provides)
* support old hashes?

reduce roundtrips:
* set as default (MDEV-12320)
* allow clients to provide the salt (--plugin-salt=XXX)
** if it's incorrect — connection fails.
** PASSWORD() returns the salt in a Note

{panel:title=revised idea}
h2. Password generation and storage

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), iteration count, salt, key_length, together with derived key = PBKDF2(func, password, salt, iteration_count, key_length)
* number of iterations is a power of 2, greater than 9
* the algorithm is ed25519, "hash" is the public key generated using ed25519 from the PBKDF2(password)

The authentication string, stored by the server, is
{code:sql}
concat('P', conv(log2(iterations)-10, 10, 62), ':', base64(salt), ':', base64(hash))
{code}
that e.g. {{P0:WW9sXaaL/o:vubFBzIrapbfHct1/J72dnUryz5VS7lA6XHH8sIx4TI}}
* it consists of colon-separated fields
* first field is 'P' (denotes KDF algorithm = PBKDF2) and the number of iterations, '0' means 1024, '1' means 2048, etc
* then salt
* then the password hash

Let's call everything except the password hash the *ext-salt*, in the example above it's {{P0:WW9sXaaL/o}}

h2. Login process, packet exchange

1. Server sends the welcome packet with a 32-byte random scramble

2 . if the ext-salt was specified in the .my.cnf, the client skips to step 4, otherwise it sends the user name (and nothing else) to the server

3. Server sends the ext-salt to the client

4. 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)

5. Server replies with "ok" or "acces denied"
{panel}

{panel:title=first idea}
h1. Rough idea

* the KDF function is pbkdf2 (supported by everything, including [windows native|https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptderivekeypbkdf2], Java, javascript, PHP, .NET
* parameters to the pbkdf2 are stored in with authentication plugin data : hash function (SHA512,SHA256), interation count, salt, key_length, together with derived key = PBKDF2(func, password, oalt, iteration_count, key_length)

h2. Login process, packet exchange

1. Server sends ServerPluginParameters message with hash function, interation count, salt, key_length.
    This is the only unencrypted message during entire exchange

2 . Client computes derived key from password and parameters:
     derived_key= PBKDF2(hash_func, password, salt, iteration_count, key_length)
     Client sends ServerVerificationChallenge = AES_ENCRYPT(client_scramble,derived_key) to server

3. server decrypts ServerVerificationChallenge and sends

     ServerVerificationResponse = AES_ENCRYPT(concat(server_scramble,client_scramble)), derived_key))

4. client verifies AES_DECRYPT(ServerVerificationResponse, derived_key) =concat(server_scramble,client_scramble).
     If they don't match, client could not verify the server, and error is reported.

    Client still has to prove it has the password, not just the derived key
     So it sends
     ClientEncryptedPassword message = AES_ENCRYPT(concat(hash_func(password),server_scramble,client_scramble)),derived_key)

5. Server verifies the client
    a) tmp = AES_DECRYPT(ClientEncryptedPassword. derived_key)
    b) hashed_password=substr(tmp, hash_length)
    c) derived_key2 = PBKDF2(hash_func, hashed_password, salt, iteration_count, key_length)
    and compares derived_key and derived_key2 for equality, (due to the [HMAC_collisions property of pbkdf2| https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions], password and hash_func(password) would produce the same keys)
   Server sends OK or ERR packet
{panel}

Sergei Golubchik made changes - 2024-06-14 10:33

Assignee

Nikita Malyavin [ nikitamalyavin ]

Sergei Golubchik [ serg ]

Sergei Golubchik made changes - 2024-06-14 10:33

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Sergei Golubchik made changes - 2024-06-14 10:33

Status

Stalled [ 10000 ]

In Testing [ 10301 ]

Sergei Golubchik made changes - 2024-06-14 10:33

Assignee

Sergei Golubchik [ serg ]

Ramesh Sivaraman [ JIRAUSER48189 ]

Sergei Golubchik made changes - 2024-06-14 10:41

Link

This issue relates to CONC-705 [ CONC-705 ]

Ramesh Sivaraman made changes - 2024-06-19 05:27

Link

This issue causes ~~MDEV-34424~~ [ ~~MDEV-34424~~ ]

Ralf Gebhardt made changes - 2024-06-25 06:53

Labels

Preview_11.6

Sergei Golubchik made changes - 2024-07-12 14:11

Link

This issue relates to ~~CONJ-1193~~ [ ~~CONJ-1193~~ ]

Sergei Golubchik made changes - 2024-07-12 14:11

Link

This issue relates to ~~CONJS-299~~ [ ~~CONJS-299~~ ]

Ramesh Sivaraman added a comment - 2024-07-16 05:18

ok to push

Ramesh Sivaraman added a comment - 2024-07-16 05:18 ok to push

Ramesh Sivaraman made changes - 2024-07-16 05:18

Assignee	Ramesh Sivaraman [ JIRAUSER48189 ]	Nikita Malyavin [ nikitamalyavin ]
Status	In Testing [ 10301 ]	Stalled [ 10000 ]

Ralf Gebhardt made changes - 2024-07-24 12:27

Summary

new auth plugin

PARSEC Authentication Plugin

Ralf Gebhardt made changes - 2024-07-24 12:29

Remote Link

This issue links to "Documentation (Web Link)" [ 37036 ]

Georg Richter added a comment - 2024-07-28 08:17

Any reason to use ed25519? Windows bcrypt doesn't support ed22519, so it can't be used under windows.

Georg Richter added a comment - 2024-07-28 08:17 Any reason to use ed25519? Windows bcrypt doesn't support ed22519, so it can't be used under windows.

Nikita Malyavin added a comment - 2024-07-28 08:32

georg bcrypt supports it, but poorly. Wee need to generate public key from private key in order to make our protocol work.

Do you have some other algorithm in mind?

Nikita Malyavin added a comment - 2024-07-28 08:32 georg bcrypt supports it, but poorly. Wee need to generate public key from private key in order to make our protocol work. Do you have some other algorithm in mind?

Sergei Golubchik added a comment - 2024-07-28 09:32

georg, also, if there will be no other solution (like ed22519 in bcrypt or some other algorithm) we can resort to linking with plugins/auth/ref10, it's already a part of the source anyway. I'd prefer not to, but it's an option.

Sergei Golubchik added a comment - 2024-07-28 09:32 georg , also, if there will be no other solution (like ed22519 in bcrypt or some other algorithm) we can resort to linking with plugins/auth/ref10 , it's already a part of the source anyway. I'd prefer not to, but it's an option.

Nikita Malyavin added a comment - 2024-07-28 09:38

Just to clarify, ed25519 is available on windows through openssl

Nikita Malyavin added a comment - 2024-07-28 09:38 Just to clarify, ed25519 is available on windows through openssl

Georg Richter added a comment - 2024-07-29 03:53

nikitamalyavin Right, but by default we build Connector/C under windows with SChannel/Bcrypt
to avoid possible license problems and to minimize external dependencies.

wlad Any insights about bcrypt and ed25519 support ?

Georg Richter added a comment - 2024-07-29 03:53 nikitamalyavin Right, but by default we build Connector/C under windows with SChannel/Bcrypt to avoid possible license problems and to minimize external dependencies. wlad Any insights about bcrypt and ed25519 support ?

Vladislav Vaintroub added a comment - 2024-07-29 04:25

No idea, @Georg.But if someone came with brilliant idea of using some particular algorithms, he thought about it being available on every platform, beforehand, right? Also in languages other than C, because if we want that to be default, it should be kinda mainstream?

Vladislav Vaintroub added a comment - 2024-07-29 04:25 No idea, @Georg.But if someone came with brilliant idea of using some particular algorithms, he thought about it being available on every platform, beforehand, right? Also in languages other than C, because if we want that to be default, it should be kinda mainstream?

Vladislav Vaintroub added a comment - 2024-07-29 04:41

Having said that, there is some code I shared with nikita, some time ago https://github.com/WireGuard/wireguard-nt/blob/cbf27645083b25caf9dd0c4d6b07163a10c3841d/example/example.c#L147 . this generates public-private key pair with ed25519, although uses some undocumented structure.

there is something similar in https://stackoverflow.com/questions/76925303/generating-curve25519-curve-key-pair-with-bcrypt-in-windows/77062918#77062918

I do not know nikita's specific needs, not an expert in what he did

Vladislav Vaintroub added a comment - 2024-07-29 04:41 Having said that, there is some code I shared with nikita, some time ago https://github.com/WireGuard/wireguard-nt/blob/cbf27645083b25caf9dd0c4d6b07163a10c3841d/example/example.c#L147 . this generates public-private key pair with ed25519, although uses some undocumented structure. there is something similar in https://stackoverflow.com/questions/76925303/generating-curve25519-curve-key-pair-with-bcrypt-in-windows/77062918#77062918 I do not know nikita's specific needs, not an expert in what he did

Georg Richter added a comment - 2024-07-29 09:51

nikitamalyavin No, I don't have another algorithm in mind. And that should have been discussed before starting implementation (by adding issues for C/C and non C-based Connectors).

Georg Richter added a comment - 2024-07-29 09:51 nikitamalyavin No, I don't have another algorithm in mind. And that should have been discussed before starting implementation (by adding issues for C/C and non C-based Connectors).

Nikita Malyavin added a comment - 2024-07-29 11:43

No worries, georg. We have a compatible ed25519 implementation bundled in the ed25519 auth plugin, sowe had a plan for the case if some mainstream config couldn't cover it. We just intended to use what system has. And we decided that it can be released without bcrypt support in its initial version.

Nikita Malyavin added a comment - 2024-07-29 11:43 No worries, georg . We have a compatible ed25519 implementation bundled in the ed25519 auth plugin, sowe had a plan for the case if some mainstream config couldn't cover it. We just intended to use what system has. And we decided that it can be released without bcrypt support in its initial version.

Nikita Malyavin added a comment - 2024-08-12 16:33 - edited

ralf.gebhardt I'd thought to reply that let's see it in main branch first, but since its client part is already released in C/C 3.4 – yes, I think we can close it

Nikita Malyavin added a comment - 2024-08-12 16:33 - edited ralf.gebhardt I'd thought to reply that let's see it in main branch first, but since its client part is already released in C/C 3.4 – yes, I think we can close it

Georg Richter added a comment - 2024-08-12 20:01

Please don't close it. We will not release C/C 3.4 GA before there is a working solution for windows. And please also file a corresponding task for CONC and other Connectors which don't use Connector/C.

Georg Richter added a comment - 2024-08-12 20:01 Please don't close it. We will not release C/C 3.4 GA before there is a working solution for windows. And please also file a corresponding task for CONC and other Connectors which don't use Connector/C.

Sergei Golubchik made changes - 2024-08-12 20:42

Link

This issue causes ~~MDEV-34742~~ [ ~~MDEV-34742~~ ]

Sergei Golubchik made changes - 2024-08-12 20:43

Link

This issue causes ~~MDEV-34743~~ [ ~~MDEV-34743~~ ]

Sergei Golubchik made changes - 2024-08-12 20:50

Link

This issue relates to MDEV-34744 [ MDEV-34744 ]

Nikita Malyavin added a comment - 2024-08-13 14:08

C/C 3.4 is already released with PARSEC support.

Nikita Malyavin added a comment - 2024-08-13 14:08 C/C 3.4 is already released with PARSEC support.

Nikita Malyavin made changes - 2024-08-13 14:08

Fix Version/s		11.6.1 [ 29847 ]
Fix Version/s	11.6 [ 29515 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Diego Dupin made changes - 2024-08-30 14:57

Link

This issue relates to MDEV-34846 [ MDEV-34846 ]

Diego Dupin made changes - 2024-09-02 09:05

Link

This issue relates to ~~MDEV-34854~~ [ ~~MDEV-34854~~ ]

Sergei Golubchik made changes - 2024-09-02 10:32

Link

This issue causes ~~MDEV-34854~~ [ ~~MDEV-34854~~ ]

Sergei Golubchik made changes - 2024-09-02 10:32

Link

This issue relates to ~~MDEV-34854~~ [ ~~MDEV-34854~~ ]

Marko Mäkelä made changes - 2024-09-15 13:03

Link

This issue relates to MDEV-34933 [ MDEV-34933 ]

Ralf Gebhardt made changes - 2024-10-02 07:47

Link

This issue blocks MENT-2142 [ MENT-2142 ]

Vicențiu Ciorbaru made changes - 2024-10-25 08:41

Link

This issue is blocked by MDEV-35254 [ MDEV-35254 ]

Nikita Malyavin made changes - 2024-11-20 17:49

Link

This issue is blocked by MDEV-35254 [ MDEV-35254 ]

Nikita Malyavin made changes - 2024-11-20 17:50

Link

This issue causes MDEV-35254 [ MDEV-35254 ]

Matthias Wirtz added a comment - 2024-11-21 19:28

Should parsec work ootb in server 11.6.2 ?
I had do lower plugin_maturity to beta to be able to load the plugin.

Matthias Wirtz added a comment - 2024-11-21 19:28 Should parsec work ootb in server 11.6.2 ? I had do lower plugin_maturity to beta to be able to load the plugin.

Nikita Malyavin added a comment - 2024-11-21 22:52

Hello, swiffer!

Yes, it is supposed to just work, but I think 11.6.2 still needed openssl on windows.

What's your setup, and what are the steps to reproduce?

Nikita Malyavin added a comment - 2024-11-21 22:52 Hello, swiffer ! Yes, it is supposed to just work, but I think 11.6.2 still needed openssl on windows. What's your setup, and what are the steps to reproduce?

Matthias Wirtz added a comment - 2024-11-22 04:27

I'm running MariaDB 11.6.2 on Ubuntu 24.04. Within /etc/mysql/mariadb.conf.d/50-server.cnf I enabled the parsec plugin as described in the mariadb docs via plugin_load_add = auth_parsec.

MariaDB emmits these ERRORs on startup:

Nov 21 19:34:03 XXX mariadbd[46425]: 2024-11-21 19:34:03 0 [ERROR] mariadbd: Can't open shared library 'auth_parsec.so' (errno: 1, Loading of beta plugin parsec is prohibited by >
Nov 21 19:34:03 XXX mariadbd[46425]: 2024-11-21 19:34:03 0 [ERROR] Couldn't load plugins from 'auth_parsec.so'.

Adding plugin_maturity = beta to the conf solved the issue for now. I guess the Plugin maturity hasn't been bumped when going from 11.6.1 to 11.6.2.

Matthias Wirtz added a comment - 2024-11-22 04:27 I'm running MariaDB 11.6.2 on Ubuntu 24.04. Within /etc/mysql/mariadb.conf.d/50-server.cnf I enabled the parsec plugin as described in the mariadb docs via plugin_load_add = auth_parsec. MariaDB emmits these ERRORs on startup: Nov 21 19:34:03 XXX mariadbd [46425] : 2024-11-21 19:34:03 0 [ERROR] mariadbd: Can't open shared library 'auth_parsec.so' (errno: 1, Loading of beta plugin parsec is prohibited by > Nov 21 19:34:03 XXX mariadbd [46425] : 2024-11-21 19:34:03 0 [ERROR] Couldn't load plugins from 'auth_parsec.so'. Adding plugin_maturity = beta to the conf solved the issue for now. I guess the Plugin maturity hasn't been bumped when going from 11.6.1 to 11.6.2.

Nikita Malyavin made changes - 2024-11-22 11:22

Link

This issue causes ~~MDEV-35482~~ [ ~~MDEV-35482~~ ]

Nikita Malyavin added a comment - 2024-11-22 11:38

thanks, created ~~MDEV-35482~~

Nikita Malyavin added a comment - 2024-11-22 11:38 thanks, created MDEV-35482

MariaDB Server

PARSEC Authentication Plugin

Details

Description

Password generation and storage

Login process, packet exchange

Rough idea

Login process, packet exchange

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration