20.12.2011 12:57, Alex Peshkoff wrote:

> Certainly, and it's already done. With one exception - FB3 protocol
> begins authentication inside op_connect. That's absolutely backward
> compatible - I've added new tags to CNCT_ID block, and they are
> certainly just ignored by older servers. For FB3 client-server pair this
> helps to avoid extra roundtrip when attaching database.

I don't mind an extra round-trip during the attach call if it would make 
the scheme more secure. But it doesn't seem to be the case here.

> connect: client's public key, login and database name =>  server
> accept: (server ignored SRP info) =>  client
> attach: legacy password_enc =>  server
> response: success if password is correct

So, by "compromised" you mean that the password intended for the secure 
communication is encoded using the weak legacy encryption routine and 
sent over-the-wire?

Honestly, I don't see how it can be avoided in general. We either make 
the auth configurable on the client (which we'd like to avoid) or 
introduce some runtime control (e.g. isc_dpb_sec_password) that prevents 
the password to be sent using the non-SRP way. But this requires 
application developers to care about the security which does not look 
like a good option either.

So perhaps a warning could be enough. A one-time user error is unlikely 
to make the system immediately broken but [provided the warning has been 
seen] it would prevent this from happening again.


Dmitry

------------------------------------------------------------------------------
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

Reply via email to