- What is stored on the server?
When setting password, the password is turned into bytes (don't know which encoding is used), then the password bytes are hashed with SHA-512 once, to produce the "left half" and the "right half" of an ed25519 private key. The "left half" (first 32 bytes of the hash output) (well, byte 0 and byte 31) is clamped to valid curve25519 private scalar "a", and this is multiplied by the curve generator to get group element "A", an ed25519 public key. The resulting value is serialized back to 32 bytes, and the value is then stored encoded with base64 (43 bytes without the final padding byte "=") as the user's hashed password.
This process is entirely deterministic - there is no salt.
Every user with the same password will have the same hashed password.
Every time a user changes their password back to a password they already used before, the hash of their password will be set to the hash used before. There is a unit test to verify this fact. Code, unit test.
- What is sent during login?
When the client wants to login using this scheme, the server sends a 32 byte random nonce, the client asks user for password, generates the same ed25519 private key and performs what I'll trust is correct ed25519 signature of the nonce using the private key and send the signature back to the server. The server then does what I'll trust is correct ed25519 signature verification. If the signature is verified successfully then you're logged in.
This to me seems to be secure - performing an ed25519 signature of random 32 bytes should be secure and never reveal the private key itself, and the signed value is long so it won't repeat.
code: 1 2 3 4 5 6
- Is the scheme secure without TLS?
Well, it won't trivially reveal your password to a network eavesdropper (though using mysql without TLS will reveal all your queries, all your data, and allow an active attacker to wait for you to login and then take over the connection and do whatever they want with it). I don't know how much better or worse this is than login by HMAC(password, random nonce), but I guess it's ok.
- How resistant is it against password dumps?
Not at all. Since it's fully deterministic, it already fails. But can we crack the password hashes? curve25519 scalarmut on CPU is about 75,000 per second, but in 2013 it was about a million per second on GPU (source), so a modern password cracking rig can crack those passwords quite fast even without using a lookup table (which you can do because it's deterministic!). So it completely fails to be a decent password hash.
- What is the name of this scheme?
No idea. "hash a password directly into a ed25519 private key"?
- Is it used by anything else besides MariaDB?
I hope not.
- Are there other implementations?
java , C#
- Final words?
The MariaDB documentation strongly implies this is secure because it's exactly like what openssh does to authenticate by ed25519 keys, but shows examples which use human generated passwords, which never happen with ssh-keygen. This password hashing scheme is secure only when the "password" typed in by the human is a uniformly random value at least 256 bits long (64 hex bytes, 24 words chosen from a dictionary of 2048 words) - meaning a computer generated key, not a human generated password. This is completely insecure for human generated passwords!
