World: r3wp

I just know that mySQL distinguishes it for itself simply by using 
asterisk as a first char in password ...

nice - checksum/secure "mypass" = checsum/method "mypass" 'sha1

Does this help? http://www.redferni.uklinux.net/mysql/MySQL-Protocol.html

so maybe we are closer to solution then it might seem :-) with older 
password schemes, maybe all those funcs were needed, as 'sha1standard 
 was not used?

could be.

thanks for the above link, informative ... clears some bits for me 
...

That article says password-length is given by a count-byte.

Doc already has 'long-password constant there, but it is not further 
used ...

what do you mean by "count-byte"?

ah, length? passwd?

but - server does not send password, only the 'seed ...

look for "preceeded with a single byte". yes, length.

ok, going for lunch .... I will look into it later ... thanks for 
the tips ...

its not the password, its this sha1-thing i guess.

it says "usually 20", like the cha1-length. Good lunch.

yes, hash is 20 bytes long, but server sends you a seed, which is 
shorter ... if I will not be able to distinguish by seed-lenght, 
then I will have to look elsewhere ... will check-on long-password 
constant ...

salt is sended before that, Salt="yF/WHCWj"

salt = seed ...

password is never sent ....

i think so. and a PROTOCOL_41 in a line nearby.

yes, it says scrambeled password. i guess the clients sends the length 
and then that sha1-wrangled thing.

so I have to find a way, how to distinguish, what passwd version 
is stored on the server ... it starts with asterisk, so the server 
easily knows, but seed does not start with asterisk ... which is 
a pity, would be trivial :-)

Caps=LONG_FLAG | CONNECT_WITH_DB | COMPRESS | TRANSACTIONS | PROTOCOL_41 
| SECURE_CONNECTION

is send by the server.

and?

protocol_41 means a long password?

i hope so. reminds on mysql 4.1

btw - from description it seems to me that seed is the random string 
...

but you can use 4.11 with old password ... well, will look into it, 
- other than that it seems to me I might be able to fix the scheme 
in less than 10 minutes now :-)

maybe it relies on the count-byte you send?

fix=make it working - we will see - not just with automatic distinguishing 
what password scheme should be used .... good doc, Volker! I searched 
Google yesterday, but did not find the one describing the protocol 
...

then look how Doc parses this header, maybe you can hexdump it and 
test with old and new password?

The new authentication is performed in following manner:

  SERVER:  public_seed=create_random_string()
           send(public_seed)

  CLIENT:  recv(public_seed)
           hash_stage1=sha1("password")
           hash_stage2=sha1(hash_stage1)
           reply=xor(hash_stage1, sha1(public_seed,hash_stage2)

           // this three steps are done in scramble() 

           send(reply)

     
  SERVER:  recv(reply)
           hash_stage1=xor(reply, sha1(public_seed,hash_stage2))
           candidate_hash2=sha1(hash_stage1)
           check(candidate_hash2==hash_stage2)

           // this three steps are done in check_scramble()

he does nice job, he puts it into words ...

just went away for lunch :-)

CLIENT:  recv(public_seed) //must be that salt-thing
 zapadapadu password

send(reply) //must be the scrambled password, makes no sense otherwise.

Doc probably wanted his script to work independently of Pro and Command. 
(or, that method wasn't implemented at that time).

I think so. I guess they used no sha1 and rebol had nothing inbuild. 
now checksum/secure matches perfect.

hmm, sadly, there is probably bug in protocol read-out directly. 
I thought that salt (seed) is those 8 bytes only. It is so, only 
if old password scheme is used, otherwise another 12 bytes follow. 
But Doc keeps only 8 bytes in crypt-seed word no matter what protocol 
password version is used ...

The host sends an initial greeting
 in docu,
do-handshake:
 in Docs code.

you see the first entries match.

I know - I proceeded further - it calls decode ....

No, you must extend the parse-rule.

but look at do-handshake parser ... it does not parse for the rest, 
it seems to stop at the capabilities ...

agreed :-)

there are 16 bytes to ignore (latin1 etc.)

that a 16 skip

to ignore or not :-)

I may as well extend the protocol, but it may come later :-)

and then the other 12 for salt. copy salt2 12 skip