World: r3wp
[MySQL]
older newer | first last |
Pekr 9-Jan-2006 [267] | protocol_41 means a long password? |
Volker 9-Jan-2006 [268] | i hope so. reminds on mysql 4.1 |
Pekr 9-Jan-2006 [269x2] | 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 :-) | |
Volker 9-Jan-2006 [271] | maybe it relies on the count-byte you send? |
Pekr 9-Jan-2006 [272] | 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 ... |
Volker 9-Jan-2006 [273] | then look how Doc parses this header, maybe you can hexdump it and test with old and new password? |
Pekr 9-Jan-2006 [274x3] | 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 :-) | |
Volker 9-Jan-2006 [277] | CLIENT: recv(public_seed) //must be that salt-thing zapadapadu password send(reply) //must be the scrambled password, makes no sense otherwise. |
Anton 9-Jan-2006 [278] | Doc probably wanted his script to work independently of Pro and Command. (or, that method wasn't implemented at that time). |
Volker 9-Jan-2006 [279] | I think so. I guess they used no sha1 and rebol had nothing inbuild. now checksum/secure matches perfect. |
Pekr 9-Jan-2006 [280] | 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 ... |
Volker 9-Jan-2006 [281x2] | The host sends an initial greeting in docu, do-handshake: in Docs code. |
you see the first entries match. | |
Pekr 9-Jan-2006 [283] | I know - I proceeded further - it calls decode .... |
Volker 9-Jan-2006 [284] | No, you must extend the parse-rule. |
Pekr 9-Jan-2006 [285x2] | but look at do-handshake parser ... it does not parse for the rest, it seems to stop at the capabilities ... |
agreed :-) | |
Volker 9-Jan-2006 [287x2] | there are 16 bytes to ignore (latin1 etc.) |
that a 16 skip | |
Pekr 9-Jan-2006 [289x2] | to ignore or not :-) |
I may as well extend the protocol, but it may come later :-) | |
Volker 9-Jan-2006 [291] | and then the other 12 for salt. copy salt2 12 skip |
Pekr 9-Jan-2006 [292] | I need language info :-) hmm, but that can be obtained later .... |
Volker 9-Jan-2006 [293] | thehn joinboth salts. with some luck that works. |
Pekr 9-Jan-2006 [294x2] | do those two salts to be joined? |
it will not work probably, no? | |
Volker 9-Jan-2006 [296x2] | should. together 20 bytes, can not be accidental (i hope..) |
also the example says "Rest of Salt" | |
Pekr 9-Jan-2006 [298x2] | do you think Doc's hash-v10 and crypt-v10 are equivalent to chekcsum/secure sha1? |
let's hope so ... going to extend the parse now ... | |
Volker 9-Jan-2006 [300] | i have no idea. i see lots of cryptic binary stuff, no idea whatit does. |
Pekr 9-Jan-2006 [301x2] | imo Doc found some C code and translated it to rebol back then, when checksum/secure was not available? dunno .... |
ehm, ehm .... :-) | |
Volker 9-Jan-2006 [303] | Maybe its something custom? They mention no name, while they refer to sha1 in the new version. |
Pekr 9-Jan-2006 [304x3] | I just put some probe [name int and value] into decode function to know capabilities, but: decode-integer: 41516 long-password 0 found-rows 0 long-flag 4 connect-with-db 8 no-schema 0 compress 32 odbc 0 locl-files 0 ignore-space 0 change-user 512 interactive 0 ssl 0 ignore-sigpipe 0 transactions 8196 |
how is that long-password, sent to me by server initial handshake sequence is 0? | |
that somehow does not make sense to me ... | |
Volker 9-Jan-2006 [307] | me too. hmm. long-flags is set. |
Pekr 9-Jan-2006 [308] | yes, curious what it means ... |
Volker 9-Jan-2006 [309x2] | do you have a long password in the db? |
that example has also only long-flag | |
Pekr 9-Jan-2006 [311] | yes .... |
Volker 9-Jan-2006 [312x2] | long_password is in the clients response. |
The client now sends a request | |
Pekr 9-Jan-2006 [314] | although - I just try to connect to /mysql table ... but passwd is user dependant, and as a root, I can see, it is long already :-) |
Volker 9-Jan-2006 [315] | we get a little score for the first round? :) |
Pekr 9-Jan-2006 [316] | what do you mean? :-) |
older newer | first last |