r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[MySQL]

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? :-)