On 20/12/2011 08:19, Alex Peshkoff wrote: > On 12/20/11 13:54, Adriano dos Santos Fernandes wrote: >> On 20/12/2011 06:57, Alex Peshkoff wrote: >>> connect: client's public key, login and database name => server >>> accept: server's public key and salt => client >>> attach: client's proof => server >>> response: success if client's proof == server's proof >>> >>> >> What I would like to know is that if there is a way to configure the >> client to know if the server is a trusted one, cause if you only use >> generated keys you don't prevent man in the middle attacks. > The power [ sorry for too beautiful words :) ] of SRP is that it DOES > prevent man in the middle attack even with generated keys. This works > cause in fact a kind of small key - password's hash - is placed on the > server in advance. And that hash is used as a part of server's public > key, returned to client. Correct session secret (and based on it proof) > can be built from that public key only knowing login, salt (this 2 are > not a problem certainly) and password, which is supposed to be unknown > to attacker. If you want more details - http://srp.stanford.edu/ > > I really can't read a security spec and fully understand it, sorry, but I do not think this scheme prevents what I mean.
Suppose someone intercepts client op_connect and acts like a server to the client. This middle-man then acts like a client to the real server. He's then able to intercept the whole connection, but probably can't reuse the password for future connections. That may be inevitable per see, so it's why I think we must have in the client a way to know (and otherwise prevent) if the connection is really made with the real (trusted) server. This is AFAIK how browsers shows to you that you're connected to real (trusted) server, . Adriano ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
