JDBC Java ConnString / EncryptedPassword (ENP) connection parameter

[Former Member]

Hey guys, standard connection to connect from a java application to an sybase16 db with jconn3.jar

Connection con = DriverManager.getConnection( "jdbc:sqlanywhere:UserID=<user_id>;Password=<password>;Start=..." );

I'm searching for a solution to save the database-user and password out of my java programm like commandline tool dbisql

dbisql @dbconfig.cfg

dbconfig.cfg contains (servername), username,password

dbconfig.cfg is also crypted by dbfhide

Any ideas how i can do this in java oder c# connectionstring?

Thanks, Peter

---

solution at http://sqlasupport.sap.com/readme/sqla1600.html Search String Build #2041 - Engineering Case #773529

[Former Member]

You could model your solution to the way many Java programs use propertiy files. It is very common for J2EE Web applications to do this but property files have been common practice since the earliest days of J2SE(1.0) and there is some history of obfuscating passwords there.

There are also newer efforts to use tighter encryption technolociges (like some of the hits I find on StackOverflow concerning the Jasypt effort but there could be more or even better options out there).

I won't be recommending any specific approach other than to do more searches on other forums (Java or .Net) to give yourself a more complete picture of what's available.

• • {others might have better suggestions} * *

[Former Member]

Thanks for this, I'll try the Jasypt effort an will search on java forums.

[VolkerBarth]

What platform are you using?

To cite from another FAQ:

Q: There's no way to use DBFHide (and configuration files) with client connections (besides the database tools and DBISQL), right?
A: You can create a file DSN and use dbfhide to hide the file, and then use the FileDSN connection parameter.

I guess that a JDBC connection could use a FileDSN similarily. (Note that while DSNs are basically an ODBC feature, they can be used by all supported SQL Anywhere client libraries.)

---

Furthermore, as you are using a v16 database, with v16.0.0.2041 there have been important changes to enhance the security of encrypted passwords (i.e. the ENP connection parameter), as stated in the cited FAQ - more details can be found in the description for CR #773529 in the v16 EBF readme...

[Vlad]

Internet also says that it is more secure to give user/password pairs for each user individually and setup permissions properly (e.g. do not allow to read/update tables that are secret). At least this should be safer to tell the user - here is your user/password and use it to connect to DB.

Usually Internet adds that if you give a direct access to the DB server, your password will be retrieved from the application regardless how you encrypt it (one can take a heap dump and analyze all strings 🙂 ).

I was thinking about using a one-time password technique similar to this scenario: your user starts the application, sends a request to the server (could be your DB server with an open HTTP port) and ask to create a temporary user/password in the DB and use this user for your application. You can try to do some checks such as "accept connections from a single machine only" and then remove this user if it wasn't used for 1-2 days.

I know this sounds tricky, Internet has 1-2 interesting proposals, but not more. The best solution, as I said - protect the data that should be protected.

E.g. Foxhound DB is fully encrypted (Sorry Breck, I was simply curious). You can execute appropriate stored procedures, but you cannot see their code. Some data is encrypted etc...

[VolkerBarth]

solution at http://sqlasupport.sap.com/readme/sqla1600.html Search String Build #2041 - Engineering Case #773529

Well, if that does answer your question resp. does solve the problem, feel free to add it here as an answer:)

[Vlad]

Wow, looks cool. The question is how the password is encrypted :) If the user doesn't enter any "salt" then the protection is not secure.

[VolkerBarth]

Yes, a good question:)

FWIW, the dbfhide options -wm (computer-only) and -w (computer/user-only) have been implemented on Windows via the standard Windows DPAPI, as far as i know. Don't know whether this is still true as they now are supported on all platforms, as stated in the same CR note.