In the Payment Card Industry (PCI), security is always a major concern. A lot of enterprise applications have application passwords hard-coded in configuration files, which are not allowed by the
... [More]
Payment Card Industry Data Security Standard (PCI DSS). Smart Account Management (SAcct) is a light-weight Security Framework to ease your pain of removing the account passwords from application configuration files. The SAcct server reads in the account information from a secured soft token and acts as an account server. The SAcct client communicates with the SAcct Server over a secured channel to retrieve account passwords on behalf of the application on start-up.
Problems and ChallengesTake a Spring application as an example, the following wiring file includes a database user name and a user password,
To put the database user password into the configuration file is a serious security problem and it is not allowed by the Payment Card Industry Data Security Standard (PCI DSS). Some frameworks try to encrypt the passwords, but they still need to wire in the encryption password, which does not really solve the problem. We propose to store the accounts in a secured token file, which you can put into a USB drive or other secured devices, then the SAcct framework can retrieve them on behalf of the application during the application start-up phase.
SAcct ArchitectureThe SAcct architecture is shown in the following diagram,
The SAcct server is a standalone Java application and mainly consists of the following components: Session Manager: create a session key for each connection based on the Diffie-Hellman Key Exchange protocol. It also generates a session id and maintains the sessions in the cache. Account Manager: read account data from the account token file and service client account requests. Connector: read requests from the client and write the responses back to the client. Message encryption/decryption is handled on this layer.
The SAcct client usually is one part of the business application. It derives the session key and stores the session information in a token. The SAcct client also includes a socket connector to communicate with the SAcct server. All request messages are encrypted except the session Id as shown in the system diagram. The communication flows are summarized as follows,
handshake request: The client generates two big numbers, Cr as the private key, Cp as the public key, and initiates the connection by sending the public key Cp to the SAcct server. handshake response: Upon receiving the client request, the SAcct Server generates its own private key Sr and public key Sp. In the meanwhile, it derives a secret key as the session key based the client's public key Cp and its own keys. Then the SAcct server responds back to the client with its public key Sp and a random session id. account service request: The client derives the same secret key after received the server's public key Sp and starts to send a secured service request to the server using the session key. account service response: The SAcct server decrypts the request and replies back the encrypted service response with the session key. closeSession request: The client finishes its job and sends a closeSession request to the SAcct server. closeSession response: The SAcct server replies back and the client closes the socket connection. SAcct FeaturesSAcct is a Java application and suitable for Enterprise Java applications. SAcct features are highlighted as follows,
Light-Weight Use Google Guice as the dependency injection framework for the SAcct Server Account information are encrypted and stored as a soft token on a carry on device Utility tools are provided to encrypt and decrypt the soft token Use the Diffie-Hellman key exchange protocol to derive the session key The communications between the SAcct Server and the SAcct Client are encrypted by the session key An One Time Password (OTP) is used to prevent session replay attack All encryptions use the Advanced Encryption Standard (AES) algorithm Spring support Many security utility classes SAcct ModulesSAcct consists of the following modules:
SAcct Common: common and shared classes between the SAcct server and the SAcct client. SAcct Server: SAcct server is a standalone Java application. SAcct Client: SAcct client acts as a client stub communicate with the SAcct server. SAcct Spring: Utility classes for the Spring framework. Reference Project: will create a reference project to demonstrate how to use SAcct. Account UI: will add UI to manage account tokens. SAcct SolutionsWhat to know how SAcct solves the problems? Take a Spring application as an example.
First, you need to download SAcct server, unpack it, go to the bin directory, and run
./sacct_serverThe SAcct server will read in the soft token and listen on socket port 9000 by default.
The Account Provider is an abstraction of the SAcct client. In your Spring application, you can define the account provider bean as follows.
The account factory bean is used to retrieve the actual account password information from the account provider. Optionally, you can provide the default/dummy password in the case that the SAcct is not available.
Finally, the dataSource bean can be rewritten as
For more details, please read SAcct 0.1.0 User Guide and the FAQs.
Maven RepositoryThanks to Matt Senter, SAcct artfacts are in our Maven repositories now:
SAcct Maven Release Repository SAcct Maven Snapshot Repository For how to use Maven with SAcct, please refer to the Maven guide in the user guide.
SupportIf you have any problems, please post to our SAcct User Group, I will get back to you as quick as possible.
If you are interested in contributing to SAcct, please read How to Contribute.
NEWSJuly 9 2009, added SAcct Server Implementation Experience With Google Guice. July 8 2009, added SAcct 0.1.0 User Guide. July 7 2009, SAcct 0.1.0 is released, please check the release announcement. June 19 2009, SAcct became an open source project. NOTESAcct is one of the Open Source Open Mind Initiative projects. [Less]
java
password
security
