Authentication protocol client_ed25519

[daniel-pfeiffer]

Our DBAs are (due to PCI/DSS compliance) switching to this password scheme. When connecting to such a server with crate mysql I get

DriverError { Unknown authentication protocol: `client_ed25519` }

I see ed25519_dalek and underlying curve25519-dalek are separate crates, but I don’t know how to tie them in. I hope this isn’t meant to say that’s currently impossible:

implements necessary functionality for MySql cached_sha2_password, mysql_native_password and legacy authentication plugins

What needs to be done?

[blackbeam]

@daniel-pfeiffer, Hi.

When connecting to such a server with crate mysql I get:

DriverError { Unknown authentication protocol: `client_ed25519` }

This is because the client_ed25519 plugin is not implemented. I believe there was another issue mentioning this plugin but I couldn't find it 🤷‍♂️. Anyway..

What needs to be done?

• Well first you need to implement the plugin — this involves doing sha512 as well as few scalar and group operations on ed25519 (here is a good reference implementation I googled). You can put this somewhere inside src/scramble.rs
• Then you need to extend the AuthPlugin enumeration with the new variant.
• The next step depends on which client you are using:
  • if it is mysql_async client, then you need to catch the new plugin here and perform the authentication
  • if it is mysql client, then you need to catch the new plugin here and perform the authentication

If you'll be able to implement this please consider filing a PR — it's not always possible to put time and effort in features I'm not personally interested in, so the only way for the library to evolve comprehensively is the community contributions

[daniel-pfeiffer]

@blackbeam Hi Anatoly,

thanks for the pointers! Since no crypto expert stepped in, I’ll look at this.

In packets/mod.rs you use the 3 scramble* functions plus one simpler one. The naming is orthogonal to this: 3x Mysql*Password and CachingSha2Password – with the latter and 2 of the former calling the scramble* functions, none of which seem to cache. Not sure what the difference in naming is trying to convey here? And not sure whether MysqlEd25519Password or CachingEd25519Password suits you better?

More confusing: matching the latter there is a similar named file caching_sha2_password.rs pulled in with a mod statement, but the class therein PublicKeyRequest only gets referenced in comments.

kind regards – Daniel

[daniel-pfeiffer]

We are reconsidering using this at all. Based on this well founded answer, with our security experts, we have done some experiments. It seems that MariaDB took a good signature algorithm, and misapplied it to passwords. Since these are usually low entropy, that’s a bad fit. Anybody capturing the password storage, can hope to crack them too easily, as they are stored unsalted.

We have asked MariaDB to justify this. Let’s see, if they manage to convince us that they do know what they are doing.

Update: They were already aware of these concerns, and are working on a new auth plugin.

[crai0n]

@daniel-pfeiffer Have you put any meaningful effort into implementing this already? I might take a shot at implementing this and creating a PR, although I am by no means an expert on cryptography.

Even though MariaDB is moving to PARSEC now, it might be nice to have this functionality in the crate for completeness.

[daniel-pfeiffer]

Hi CraiOn, there seem to be 2 lines of thought: implement it anyway because the auditor (vaguely heard about it and thus) said we should. Or ignore it, because it's not fit for purpose. I adhere to the latter, and hope this whole thing will be buried quietly.

…

-----Original-Nachricht----- Betreff: Re: [blackbeam/rust_mysql_common] Authentication protocol client_ed25519 (Issue #138) Datum: 2024-09-03T13:35:31+0200 Von: "crai0n" ***@***.***> An: "blackbeam/rust_mysql_common" ***@***.***> @daniel-pfeiffer <https://github.com/daniel-pfeiffer> Have you put any meaningful effort into implementing this already? I might take a shot at implementing this and creating a PR, although I am by no means an expert on cryptography. Even though MariaDB is moving to PARSEC now, it might be nice to have this functionality in the crate for completeness. — Reply to this email directly, view it on GitHub <#138 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACITTVBNKHK55S32PKWQZ4DZUWMODAVCNFSM6AAAAABIWKX3S6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRWGI4DENJQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#138 (comment)", "url": "#138 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ] 

[daniel-pfeiffer]

MariaDB seems to have reacted to this criticism by introducing the PARSEC plugin. It looks like a version 2 renamed ed25519 plugin. I don’t know if that is secure, but at least it fixes the worst security sin of unsalted password storage and transmission.

It’s been six weeks (or more? 11.6.1 only internal?) since PARSEC stabilisation with 11.6.2. Yet MariaDB don’t seem to be transparent about this. The ed25519 plugin documentation still doesn’t even mention its shortcomings, leave alone announce whether it will be deprecated. Nor does it mention PARSEC as a successor (other than it being mechanically listed in the sidebar.)

Their Pluggable Authentication Overview also has nothing to say about PARSEC yet. So far only the PARSEC page claims that it is the future, leaving everyone to discover it by chance.

[daniel-pfeiffer]

The more secure successor scheme PARSEC was only released as Enterprise last week. Now my company will have find time to evaluate 11.4, after which it’ll be gradually rolled out to many instances.

We’ve weighed the pros and cons and gotten the green light from security, to continue the switch to ED25519. So I’m after all very interested.

@crai0n When compiling this, I get:

    --> /home/pfeiffer/dp/Rust/rust_mysql_common/src/packets/mod.rs:2701:38
     |
2644 | impl<'a> ComRegisterSlave<'a> {
     |      -- lifetime `'a` declared here
...
2701 |     pub fn hostname_raw(&'a self) -> &[u8] {
     |                                      ^ this elided lifetime gets resolved as `'a`
     |
     = note: `#[warn(elided_named_lifetimes)]` on by default

warning: elided lifetime has a name
    --> /home/pfeiffer/dp/Rust/rust_mysql_common/src/packets/mod.rs:2711:34
     |
2644 | impl<'a> ComRegisterSlave<'a> {
     |      -- lifetime `'a` declared here
...
2711 |     pub fn user_raw(&'a self) -> &[u8] {
     |                                  ^ this elided lifetime gets resolved as `'a`

warning: elided lifetime has a name
    --> /home/pfeiffer/dp/Rust/rust_mysql_common/src/packets/mod.rs:2721:38
     |
2644 | impl<'a> ComRegisterSlave<'a> {
     |      -- lifetime `'a` declared here
...
2721 |     pub fn password_raw(&'a self) -> &[u8] {
     |                                      ^ this elided lifetime gets resolved as `'a`

You should change &'a self to &self because that’s the default in this case. Else, though unnecessary, also give a lifetime to the result.