• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Protect JDBC password

 
Greenhorn
Posts: 9
1
Mac Postgres Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a Java Swing app that connects directly to a JDBC relational database (Postgres 9) over the Internets.

[User] <--> [Swing app] <--> [JDBC] <--> [Internets] <--> [Database]

--> How do I secure the JDBC password?

My question is along the same lines as this Store JDBC connection password topic, but there the discussion lost focus.

First, I realize there are other architectures that get around this challenge. But I really want the richness and flexibility of Swing with the simplicity and flexibility of directly talking to the database. I don't want to burden the users with hardware keys/dongles. So instead of debating alternatives, let's focus the question to this:

  • Can the architecture shown above be secured (within the reasonable needs and resources of a common small business, not Top Secret military) ?
  • If so, how?


  • From what I've learned one good approach is:

    1) Human user gives their own logon name and password to the Swing app.

    2) The Swing app makes a secure connection (TLS/SSL) to a little password app or servlet passing the credentials (user name, user password plus a salt (perhaps).

    3) The little password app or servlet (a) authenticates that user, and (b) returns the current JDBC password.

    3) The Swing app stores that JDBC password in memory.

    4) The Swing app uses that JDBC password plus a salt (perhaps) to make a JDBC connection to the database over TLS/SSL.

    Diagram of these steps:



    Assuming the TLS/SSL is reliable, to break this and gain direct access to the database, an outside hacker would have to know a user's name and password, attach a debugger or memory-scanner to the Swing app to locate the JDBC password held temporarily in memory, and decompile the Swing app to find any hard-coded salt values. And we have the advantage of being able to change the JDBC password at anytime. So, not impenetrable, but also not easy to break. Is this correct?

    Is there a better approach to accomplish the same goals?

    --Basil Bourque
     
    Ranch Hand
    Posts: 34
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Sounds reasonable. However, you can make this stronger by using a client certificate in a JKS/JCEKS file that provides strong-authentication without the burden of the hardware (https://coderanch.com/t/554774/Security/Connect-SSL-client-Certificate-java). What does it buy you on top of what you've designed? The inability of an attacker to launch a dictionary/rainbow-table attack on the servlet.

    Arshad Noor
    StrongAuth, Inc.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic