One of my customers, that uses DML replication for years, recently asked me about DDL replication in Sybase Replication Server. I explained him that in order to replicate DDL, RS connects to the replicated dataserver with the login that actually performed the DDL on the primary dataserver. For this reason, logins and passwords on all dataservers participating in DDL replication must be kept in sync. Then, the customer asked me how RS knows what password it should use each time it connects to the replicated dataserver to apply a DDL statement. My answer was – the replication agent passes login and password to RS as an integral part of DDL transaction. Then, RS knows to extract the credentials and use them to connect to replicate dataservers. But it must be a security flaw my customer said. Passwords of power users travel across the network!
I answered that Sybase engineers must have thought about it, but I was rather unaware how exactly the password encryption across the replication flow is implemented. So, I decided to do some research on this subject.
It appears that the feature called “Extended Password Encryption” has been introduced in Open Server 15.0. I’m not sure about the exact implementation of this feature, but it allows strong encryption of passwords in a way that allows secure transmission over the network. At some stage, ASE and RS, which support OpenServer, started to support this extended password encryption too. To be more specific, starting from ASE 15.0.2 and RS 15.1. So far so good.
Then, I decided to replicate some DDL between two ASE 15.5 dataservers via RS 15.6 and put RIBO between the RS and the replicated dataserver to see if the passwords are actually encrypted and how it looks. To my great surprise, I discovered that by default RS submits clear passwords. Everyone with minimal WireShark experience can catch such a password; you don’t need to be a hacker for this. I looked how to enable the encryption for a bit and found that setting of send_enc_password to ‘on’ does the job, I have verified it. And what about the RA -> RS part of the flow? It appears that in this case the password encryption is enabled by default.
The bottom line: extended password encryption is not enabled by default and in my opinion, it is a very good idea to enable it if versions of RS and ASE involved in the replication topology allow you to do so. I can only guess that send_enc_password is not enabled by default in order to support older ASE versions.
Thanks for sharing such a pleasant thought, post is nice, thats why i have read it entirely
Posted by: corporate training program | 01 October 2013 at 09:42