Browse Prior Art Database

Using Private Encryption Keys For Remote Database Access Eliminating The Need For ID/Password Verification

IP.com Disclosure Number: IPCOM000126679D
Original Publication Date: 2005-Jul-28
Included in the Prior Art Database: 2005-Jul-28
Document File: 1 page(s) / 31K

Publishing Venue

IBM

Abstract

The idea is to eliminate the need to use this ID/Password combination to connect to remote databases by using private encrypted keys. In this case the database server would be "the lock", and if another team or application needs access to data in that database they must request a key from the DB Administrator. The DB Administrator will use a key generation tool that would be included in the DB2 server package that specifically allows a connection from a specific ID on a specific remote system to access data on the DB server without using a Password, but by possessing this key. The keys would have to have variable levels of access of course, from SELECT only ranging to UPDATE, MODIFY, DELETE, etc.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 65% of the total text.

Page 1 of 1

Using Private Encryption Keys For Remote Database Access Eliminating The Need For ID/Password Verification

The current method of feeding data between systems/Applications is typically done by a remote database connection using an Id/Password combination. This has been the cause of numerous scheduled and unscheduled outages. If the password is going to expire in the near future and the appropriate support team knows this an outage is usually scheduled to take down the Application, change the password, update appropriate files that contain the password, then restart the Application. Several times unscheduled outages are also caused by passwords expiring unknowingly by the support team causing pieces or entire Application to stop working due to IDs locking up.

The idea is to eliminate the need to use this ID/Password combination to connect to remote databases by using private encrypted keys. In this case the database server would be "the lock", and if another team or application needs access to data in that database they must request a key from the DB Administrator. The DB Administrator will use a key generation tool that would be included in the DB2 server package that specifically allows a connection from a specific ID on a specific remote system to access data on the DB server without using a Password, but by possessing this key. The keys would have to have variable levels of access of course, from SELECT only ranging to UPDATE, MODIFY, DELETE, etc.

In this manor...