• 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

Credentials Storing - Best Approach

 
Ranch Hand
Posts: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the best and secured approach of storing the credentials such as DB, queues etc. Because if we store them in plain text in the application, anyone can misuse it.
 
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anyone? You suspect your sys admins of malicious intent?
 
Vaibhav Gargs
Ranch Hand
Posts: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No Tim, just to ensure best security mechanisms in place.
 
Tim Moores
Saloon Keeper
Posts: 7585
176
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"best security" is always relative to the attack scenarios against which you want (or need) to protect. There may also be further regulations for particular sets of data (like medical or financial) that you need to take into account. But without knowing what kinds of attack you're trying to guard against, this is just guesswork.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Credentials for what? JEE web applications can be secured by Container-based authentication and authorization. That's a system that allows you to plug in a security module to handle the actual validation and typically webapp servers give you a wide variety of options from JDBC to LDAP/Active Directory to site-wide/single signon and so forth and so on.

The absolute worst place to keep credentials regardless of platform is inside the app itself. Even encrypted, the entire credential database is available to anyone who can break into the application code and take over and even encrypted credenticals are marketable commodities to the right ("wrong") people.

The JEE container Realm modules - at least the ones designed by serious security people - never present user id/password or even access rights back to the webapp server and application. Instead they query an external mechanism with credentials provided to them. For example:

If the credentials match, a non-zero result (actually 1, we hope!) is returned. Given a bad password and/or userid, zero is returned. We're asking the JDBC serve "does this match?" instead of asking the server to bring back the actual user ID and password where an invader could scoop it up. That's a much smaller attack target.

While I'm using webapps as the example, most Java security systems have similar mechanisms for externalizing credentials. And by all means, use them! The technical term for people who invent their own security systems is "hacked". Unless security is a full-time job that you are professionally trained for, someone can probably find a way to break what you've invented. And sometimes even if you are. Security is a chain and even one weak link breaks the whole thing. And besides, don't you have enough to do without designing and debugging a security system on top of that?
 
Vaibhav Gargs
Ranch Hand
Posts: 441
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe I couldn't make the question clearer, apologize for it. I meant the application needs to connect to the database using some credentials (URL, username, password etc.) and some other connection parameters as well, so, how can we protect this sensitive information in our application.
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vaibhav Gargs wrote:I believe I couldn't make the question clearer, apologize for it. I meant the application needs to connect to the database using some credentials (URL, username, password etc.) and some other connection parameters as well, so, how can we protect this sensitive information in our application.



Ah. Tim Moores asked you if you suspected the sysadmins of malicious intent. Regrettably, such is often the case.

To minimise exposure, if you have, say, a webapp that you want to secure and it, in turn has a user database you want secured, then one of the first things I'd recommend is that you not keep both the application data and user data in the same database.

The next thing would be to create an account for the webapp which was restricted 18 ways from Sunday. That is, first, that account user should not be able to write to any tables that the webapp isn't supposed to write to or read from any tables that the webapp shouldn't be allowed to read. In addition, many DBMS's can restrict things like what network addresses can use a database account, so, for example, that userid should be valid from the production webserver machine(s), but not from any desktop machine (including the sysadmins). At some point you're pretty much going to have to have a terminus in the authentication/authorization chain. In the case of Tomcat, that would be Context and server.xml in the TOMCAT_HOME config directory. The entire server directory subtree (in this particular case, TOMCAT_HOME) should have as few access rights as you can tolerate. Tomcat, of course, would need to be able to read and write, but depending on how things are managed, a sysadmin might be partially or totally blocked.

Then the next level of paranoia is that if you have an app for adding/modifying user accounts for the webapp in question, that app should ideally be a completely separate webapp from the main web application, and thus administer the user account database and only the user account database, with the converse being true that the actual application app would have no access to the userid/password/access rights database.

And to complete our paranoia, have all access to the server machine(s) be done using an encrypted LAN - or better yet a restricted encrypted VPN, both for shell access and database access. And firewall everything.

Nothing's unbreakable, but this will make it much harder to crack.

Again, I've use a web application as an example, but even if that's not what you're looking for, I hope it will give some ideas.
 
reply
    Bookmark Topic Watch Topic
  • New Topic