Results 1 to 9 of 9

Thread: Hide password in datasource config

  1. #1
    Join Date
    Nov 2005
    Location
    Munich
    Posts
    3

    Default Hide password in datasource config

    Hi all,
    does anyone have an idea how I can hide/encrypt the password for a datasource configuration? Maybe you can give me a little example.

    Code:
    <bean id="localMySqlDataSource" class="org.apache.commons.dbcp.BasicDataSource">
    		<property name="driverClassName">
    			<value>com.mysql.jdbc.Driver</value>
    		</property>
    		<property name="url">
    			<value>jdbc:mysql://localhost/test</value>
    		</property>
    		<property name="username">
    			<value>root</value>
    		</property>
    		<property name="password">
    			<value>howCanIHideThis</value>
    		</property>
    </bean>
    Thanks,
    Alex

  2. #2

    Default

    Subclass BasicDataSource and override setPassword where you decode the password. However if the intruder is smart he or she would decompile your class and then decode the password

  3. #3
    Join Date
    Feb 2005
    Location
    Boston, MA
    Posts
    1,142

    Default

    Quote Originally Posted by epitoman
    Subclass BasicDataSource and override setPassword where you decode the password. However if the intruder is smart he or she would decompile your class and then decode the password
    Actually you should probably subclass DelegatingDataSource and delegate to whatever datasource you are using. That way you wouldn't have to tie yourself to a particular datasource implementation (ie you later decide to move to a database pool like C3P0).

    Just override getConnection and getConnection(String,String) to perform the decryption. Maybe call the class DecryptingDataSourceWrapper.
    Bill

  4. #4
    Join Date
    May 2006
    Location
    Crawley, UK
    Posts
    105

    Default

    Try externalising the connection parameters into a properties file.

    To do this you need to use PropertyPlacholderConfigurer - which is becoming a bit of a theme on this forum today.

    Doing this will allow you to...
    1. Have a different config for each deployment
    2. Keep sensitive information out of the source code
    3. Have a single 'binary' that can be deployed in multiple environments


    Enjoy!

    Bob
    If you didn't learn anything today, you weren't paying attention!

  5. #5
    Join Date
    Nov 2005
    Location
    Munich
    Posts
    3

    Default

    when I use the PropertyPlaceholderConfigurer and a property file does I have not the same problem with a clear text information for the password because the property file is not encrypted?

    I think I'll subclassing the DelegatingDataSource and use an encrypted property file.

    Alex.

  6. #6
    Join Date
    Feb 2005
    Location
    Boston, MA
    Posts
    1,142

    Default

    Yes, you do have the same problem with a property file. But his point was a property file easier to manage than an XML file which since it contains object wiring information it, is more like code than configuration. Where as a property file is pure configuration.
    Bill

  7. #7
    Join Date
    Dec 2005
    Location
    U-241
    Posts
    237

    Default

    I do not see a problem wether a password to a ds for an application server is encrypted or in a clear text.
    Code:
    <property name="username">
                <value>root</value>
            </property>
    Here I see a problem. User root never ever launches application server!!!
    Spring, it's a wonderful thing...

  8. #8
    Join Date
    May 2006
    Location
    Crawley, UK
    Posts
    105

    Unhappy

    Eggi,

    I didn't explain clearly enough - sorry for that.

    As somebody else pointed out, externalising the password puts us in a situation where the developer has visibility of the username/password used for the development environment, but not for the production environment.

    It's all a case of sensitivity really, it doesn't hurt too much to trust developers with access to development systems as they can (or at least should) be possible to recreate with minimal effort. Production systems are much more critical to the bottom line of a business and therefore need to be protected from unauthorised access - whether that's malicious or accidental.

    The basic philosophy is to be able to configure 'environmental details' at the point of use, without having to modify the binary assets that make up the product.

    I hope this clears things up.

    Bob
    If you didn't learn anything today, you weren't paying attention!

  9. #9
    Join Date
    Nov 2005
    Location
    Munich
    Posts
    3

    Default

    Hi Bob,
    thanks for explaining - I know what you mean.

    Now I have create a subclass of DelegatingDataSource and inject the targetDataSource with the real datasource config (see above). When I overwrite the getConnection and getConnection(user, password) I get following stacktrace:

    Code:
    	at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:116)
    	at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:554)
    	at org.springframework.jdbc.datasource.DelegatingDataSource.getConnection(DelegatingDataSource.java:68)
    	at config.DataSourceWrapper.getConnection(DataSourceWrapper.java:16)
    	at org.springframework.orm.hibernate.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:76)
    Here part of config for Hibernate and datasource

    Code:
    <bean id="dsWrapper" class="config.DataSourceWrapper">
    		<property name="targetDataSource" ref="localMySqlDataSource"/>
    </bean>
    		
    <!-- Hibernate SessionFactory -->
    <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
    		<property name="dataSource">
    			<ref local="dsWrapper"/>
    		</property>
    		<property name="hibernateProperties">
    			<ref local="hibernateProperties"/>
    		</property>
    .....
    Here the new class:
    Code:
    public class DataSourceWrapper extends DelegatingDataSource {
    
        public Connection getConnection() throws SQLException {
            return super.getConnection("user", "password");
        }
    
        public Connection getConnection(String username, String password) throws SQLException {
            return super.getConnection("user", "password");
        }
    }
    Does someone have a hint for me what I'm doing wrong?
    ___________
    Alex

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •