Simple password authentication schemes are usually guarding against one of two evils – either leaked password tables, or sniffed network traffic. In 4.1 MySQL introduced challenge-response scheme, that is guarding against both, just not both at the same time. How does one obtain the token required to log into the server? There are few methods:
- Use gdb, dtrace or any other deep-inspection method to grab ‘buf’ in check_scramble()
- Grab mysql.user table, sniff network traffic, calculate the hash_stage1 value out of public_seed (initial server packet), client’s reply and actual password hash
- Intercept the password client-side at libmysqlclient level (again, gdb, dtrace, etc ;-)
- Mix ethyl alcohol with the carbohydrate-based bipedal DBA, until it becomes quadrupedal and tells the password (might not be able to tell anything else at that moment).
P.S. I was asked by MySQL Conference organizers to do some shameless plugs, so… yeah, I’m going to talk about first three methods in my talk on MySQL security, and do live trials of last method during conference evening program.
domas mituzas 
Thanks, Domas, that is a *great* shameless plug! :)
The original design for the 4.1 scheme (by serg and I) did have both covered, but the implementation got completely borked.
Arjen, the very original design cover both, but not at the same time.
Did you suggest asymmetric encryption? That is the only way to pass a token over internet without tradeoffs of usual challenge-response schemes.
Of course, there is also Diffie-Hellman style key exchange, but it is quite an overhead for unencrypted fast connection…
Anyway, thermal cryptanalysis can be involved against any cryptosystem. Take a hot iron and apply it on the DBA untill THE password is recovered.
P.S. Congratulations.
P.P.S The devil hides in detail (a.k.a key exchange). Hopefully not this time.