Archive for 'Database Security'

Hardware Security Module (HSM) plays a critical role in securing the storage of private keys and accelerating compute-intensive cryptographic processes associated with public-key encryption, symmetric-key(secret-key) encryption and digital signature applications. Using HSM in Oracle Transparent Data Encryption applications will ensure that the Key material stored on the card is protected and not exportable (never leaves the card) and all associated cryptographic operations are performed on the card. Using HSM in payment card transactions is critical and it is mandatory for compliance with Payment Card Industry – Data Security Standard (PCI-DSS), Payment Application – Data Security Standard (PA-DSS) and Health Insurance Portability and Accountability Act (HIPAA) privacy and security requirements and several government security standards.

Oracle Transparent Data Encryption

Oracle Transparent Data Encryption (TDE) was first introduced in Oracle Database 10gR2 as part of the Oracle Advanced Security option. TDE performs encryption and decryption of application table columns or entire application tablespaces. TDE uses standard algorithms and facilitates a built-in key management services for supporting data encryption. Since Oracle Database 11gR1, TDE supports HSMs using PKCS#11 interface to support providing centralized key management and to secure TDE’s master encryption key.

Sun Cryptographic Accelerator 6000 (SCA-6000)

The Sun Crypto Accelerator 6000 is a PCI-E card that combines a cryptographic accelerator for Secure Sockets Layer (SSL) and IPSec sessions and also it can act as a local HSM for performing secure key management functions. Qualified as a FIPS 140-2 Level 3 compliant device, the SCA-6000 PCI-E card is designed to prevent the disclosure or corruption of cryptographic keys, results, or other sensitive data. SCA-600o supports both Solaris and Linux environments.

Applied Scenarios

  • HSM based Secure key store and Master Key Management for supporting encryption and decryption of keys performing actual data encryption:
    1. Encryption/decryption of tablespace keys and table keys
    2. Encryption/decryption support for Oracle Data Pump utility
    3. Encryption/decryption support for Oracle Recovery Manager (RMAN)
    4. Master key backup and recovery
  • FIPS-140-2 Level 3 compliance
  • Acceleration of Network encryption -  SSL/TLS communication between the Oracle client and server.
    • Offloading computationally intensive cryptographic operations to the accelerator

The Role of SCA-6000 as a HSM for Oracle TDE

If you are curious to know the configuration details and ready to test-drive the solution using Sun Crypto Accelerator 6000 (SCA-6000) PCIe card for Oracle TDE – Please download and read the following whitepaper (available from Sun Wiki).

Don’t forget to post your comments.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati Digg Google Yahoo Buzz StumbleUpon

Access control exploits, user credential exposures and related security compromises are becoming increasingly common in Web 2.0 world ! Most of these issues pertain to broken or insufficient authentication controls and flawed credential management that allows attackers to compromise vulnerable applications by stealing or manipulating credentials such as passwords, keys, session cookies and/or impersonating another user through forged or guessed credentials.  Any such access control failure leads to unauthorized access and disclosure of underlying application databases, user accounts and stored data.  Most access control related vulnerabilities are due to the inherent application-specific weakness and failure to enforce authentication mechanisms, verify authentication credentials, lack of policy enforcement prior to granting or denying access to the underlying database.

This is my second installment of work exploring MySQL security features to enforce stronger authentication controls and defend against unauthorized disclosure of user account credentials and application-related database tables.  In simpler terms, I will be uncovering a set of MySQL security mechanisms intended for the following:

  1. X.509 certificate-based  MySQL authentication
  2. Enabling host verification to cease access from untrusted hosts
  3. Restricting remote access to MySQL database
  4. Disable unauthorized access to local files
  5. Securing MySQL user accounts, passwords and access privileges
  6. Data encryption using AES

X.509 Certificate based MySQL authentication

Enforcing X.509 v3 Certificate authentication allows clients to authenticate the MySQL database server using X.509 certificates and its attributes. To enable certificate based authentication,  the MySQL  GRANT statement allows to limit user access to request X.509 certificate by specifying a set of options.  To connect the client must specify the certificates using  –ssl-ca  (CA certificate),  –ssl-cert (Client certficate) and -ssl-key (Client key).


a)  The REQUIRE X509  option allows user to provide a valid X.509 certificate, where the signing authority should be verifiable using the CA certificate. 


mysql>  GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE  X509;


b) The REQUIRE SUBJECT  ..  AND ISSUER  .. option allows the user to provide a valid X.509 certificate containing the subject information of the user and the certificate issued by a specific CA  as defined in the GRANT statement. The user’s certificate and the specified SUBJECT and ISSUER attributes are verified against the information provided with GRANT statement.


mysql>  GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE SUBJECT  ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=Ramesh Nagappan/Email’  AND ISSUER ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=SunTest CA’;


c) In addition to SUBJECT and ISSUER, the user’s certificate can be identified with the specific CIPHER .  The REQUIRE CIPHER option allows to specify the required algorithm to grant access to the database.


mysql>  GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE SUBJECT  ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=Ramesh Nagappan/Email’  AND ISSUER ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=SunTest CA’   AND  CIPHER ”DHE-RSA-AES256-SHA’;


d)  To allow access to user with SSL-enabled connection.

GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE SSL;



Trusted Host Verification

Host identification helps to allow the user requests initiated from the specified host only. If the user and hostname doesnot match the specified host the server will deny access to the database.  To enable host verification, the MySQL  CREATE USER and GRANT statements allows to specify the user assigned with a target hostname.


a)  The CREATE USER allows to specify the user assigned to a specific hostname. The user will be allowed access only if the request orginated from the specified hostname.

mysql>   CREATE  USER  ‘ramesh’@'localhost’  IDENTIFIED BY ‘some_password’;

 The above statement creates an user ‘ramesh’ assigned to hostname ‘localhost’.  This means ‘ramesh’@'localhost’ account can be used only when connecting from the localhost. 


b)  The GRANT statement allows to define user privileges on a database table only when the user is accessed from a specified host.  If the user connected from a different host the access will be denied.

mysql>   GRANT SELECT,INSERT,UPDATE  ON  test.*  TO  ‘ramesh’@'’;



Disabling Remote Access from Network 


If the MySQL database is accessed locally by the coexisting appplications, remote access from the network can be disabled.  To disable remote access via network,  you may add skip-networking under the [mysqld] section of my.cnf or start mysqld using the –skip-networking option.  To enable MySQL listen to a specific host IP address, you need to set the following attribute in the [mysqld] section of my.cnf  as follows:




Disabling unauthorized access to Local files

To disable unauthorized access or reading of local files, particularly to prevent applications access local files using SQL injection attacks – you may add the set-variable=local-infile=0 under the [mysqld] section of my.cnf .

Also, run MySQL as run as an user with minimized privileges so that any potential attacks does not result in damages to the operating system and other processes. 



Securing MySQL User Accounts, Passwords and Privileges


a) To prevent unauthorized and anonymous access to the server,  first remove the test database and all user accounts (with the exception of root account).

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host=”localhost” and user=”root”);
mysql> flush privileges;

mysql> quit;


b)  Change the MySQL root password and make sure the password is done via mysql> command line.  It is a bad practice, to change passwords via mysqladmin – u root password as the password can be accessed via “ps -aef”  (Solaris) “ps -aux” (Linux) command or by reviewing the Unix command history files. 


c)  Passwords are usually visible as plain text in SQL statements especially while executing CREATE USER, GRANT and SET PASSWORD statements. If the MySQL server is logging the SQL events and action to tables, then make sure those tables are protected from unauthorized users.


d) Change the default administrator account name from ‘root’ to a harder to guess ‘username’.  This would help defend against hackers performing dictionary/brute-force guessing attacks for administrator credentials.

mysql>  update user set user=”mysqlgeek’ where user=”root”;
mysql> flush privileges;


e) MySQL stores user accounts and its passwords in mysql.user table. Disable access to this table for any non-administrator users.


f)  Enforce the ‘principle of least privileges’ by granting minimum privileges for performing the required actions especially for user accounts that connects to the MySQL database from external applications. Do not grant privileges at the database level, MySQL allows to define privileges as required at the Table and Column level.

    grant <privileges> <column> on <database>.<table> to <login-name>@<FQDN-or-IP> identified by <password>;


Data Encryption using AES

MySQL supports data encryption functions by providing support for AES (Advanced Encryption Standard) and DES (Triple-DES) algorithms.  It is important to note, the encryption function return binary strings as BLOBS, so you may need to store the encrypted data in columns of BLOB or VARBINARY data types. MySQL provides AES_ENCRYPT( ) and AES_DECRYPT ( )  to facilitate AES based encryption and decryption  and DES_ENCRYPT( ) and DES_DECRYPT ( )  to facilitate Triple-DES based encryption and decryption  operations.


For example:


mysql>  insert into mytable (username, password)  VALUES (‘nramesh’,  AES_ENCRYPT(‘g01ns@n3′, ‘myaeskey’));


mysql>  select username, AES_DECRYPT(password, ‘myaeskey’) from mytable;

| username | des_decrypt(password, ‘myaesencryptionkey’)  |
| nramesh | g01ns@n3 | 
| bobama | s@v3u5a |


It is important to note, the encryption KEY must be provided by the application user to MySQL. It means that MySQL does’nt provide mechanisms for generating the keys. Also it is critical to store the key for supporting further decryption operations.



That’s all folks. I will revisit again on my next MySQL security project …till then let me practice wearing an Oracle shirt :-)

Onlinerel Facebook Twitter Myspace Friendfeed Technorati Digg Google Yahoo Buzz StumbleUpon

Web 2.0 applications are proliferating and it has become widely popular for delivering dynamic user-generated content, information collaboration, data mashups, social networking and Web services. Building security for Web 2.0 applications pose several daunting challenges to Web 2.0 developers as these applications are publicly accessible and it blindly opens door to several intentional/unintentional abuses and malicious practices including data interception and manipulation by cyber-criminals.  Unfortunately, Web 2.0 has no silver bullet or one-size fits all security solution ! Interestingly, the most common Web 2.0 security threats pertain to the inherent flaws with the application design, deployment architecture and its failure to proactively identify the potential application-level risks  and mitigate them with appropriate countermeasures.


Lately Web 2.0 application databases have become an easier target for cyber criminals – as it is transparent to user with rich-client applications and draws close proximity to the network perimeter ignoring the traditional logical-tiers of insulation considered with multi-tier architectures (such as Java EE). If we explore the existing Web 2.0 attack patterns and attempt to identify the potential security threats and exploits of Web 2.0 databases, we will find the most common vulnerabilities pertain to the following issues:

·         Eavesdropping database connections

·         Un-trusted application clients

·         Insufficient authentication controls

·         Insecure database access execution privileges

·         Unauthorized disclosure of user account credentials

·         Unauthorized access to application data tables

·         SQL injection or Arbitrary code execution

·         Lack of auditing controls


Thus it becomes extremely critical to proactively address the known database security issues by deploying appropriate countermeasures and ensuring confidentiality and integrity of the database including user accounts and stored data.

MySQL is the most popular open-source database and widely popular in Web 2.0 application environments.  MySQL is certainly not my forte! Recently, I had my first experiences with MySQL on couple of projects so I ended up digging deeper into MySQL security and churned up  the features for use in Web 2.0 applications.  Here is my first installment of my hitchhiker’s view on MySQL security and its relevance to Web 2.0 applications.


Securing MySQL database connections


Enforcing confidentiality and integrity of database communications is critical for thwarting eavesdropping and untrusted client connections.  Enabling MySQL connections with SSL/TLS protocol guarantees transport-layer security and assures that the database communciation is not accessible for unauthorized access and the data exchanged is not modified or altered during transit.


To secure communication between the client and the database server,  MySQL supports the use of SSL for ensuring transport-level security using encrypted communication.  Since MySQL 5.0.x, MySQL bundles yaSSL  (compatible with OpenSSL ) to support SSL and related cryptographic requirements.


Configuring MySQL with SSL/TLS communication


If you are using binary versions of MySQL to verify the existence of yaSSL support, login to the mysql client and try the following:


mysql> SHOW VARIABLES LIKE ‘have_ssl’;


| Variable_name | Value  |


| have_ssl      | YES   |




Incase of using MySQL source distribution and if you want to choose OpenSSL  (I strongly recommend OpenSSL as it is FIPS-140 certified) as your SSL provider, you may choose to recompile your MySQL server using  –with-openssl   as configure switches.


# ./configure –with-openssl


To verify the configuration with OpenSSL


mysql> SHOW VARIABLES LIKE ‘have_openssl’;


| Variable_name | Value |


| have_openssl  | YES   |



To establish an SSL communication, you must obtain the SSL certificates from a certificate authority (CA) (recommended) or alternatively you would able generate the certificates using  Solaris Key Management Framework (pktool utility) or OpenSSL (refer my earlier post on OpenSSL as CA/SSL Test Kit: Cheat Sheet) .  To enable SSL, MySQL requires the following three certificate files for both server and client (if required):


a)      CA certificate

b)      Server certificate

c)      Client certificate


You may append the location of these certificate files in the [mysqld] and [client] section of the MySQL server configuration file  my.cnf.  For example:












Alternatively, you can specify each certificate as a command-line argument to mysqld (server) and mysql (client) environments. 


To start the MySQL server daemon with the SSL configuration:







To start the MySQL client to use SSL, assuming the connecting user has no client certificate authentication requirements:


mysql –ssl-ca=cacert.pem


To start the MySQL client, assuming the connecting user is required to provide a client certificate for SSL authentication:








To verify configuration and to ensure that the MySQL server uses SSL connection, the status can be checked from the MySQL client using ssl_cipher status variable.


mysql> SHOW STATUS LIKE ‘ssl_cipher’;


| Variable_name | Value              |


| Ssl_cipher    | DHE-RSA-AES256-SHA |



Test-driving MySQL SSL connections using JDBC

 To test-drive SSL communication using JDBC, MySQL Connector/J  (MySQL JDBC driver) supports using SSL communication as long as the MySQL database server and Java client is configured with SSL certificates. To enable JDBC communication with SSL, it requires setting JDBC property requireSSL=true and useSSL=true.  In case, if you want to validate the Server certificate you may choose to use verifyServerCertificate=true.


Here is the example code, I tried out :


import java.sql.*;

public class TestJDBCoverSSL    {

public static void main(String args[])   {

      Connection mySQLconnection = null;

          try {

                //Register the JDBC driver for MySQL.

                 String url =  “jdbc:mysql://localhost:3306/mysql?&verifyServerCertificate=false&useSSL=true&requireSSL=true”;
                 mySQLconnection =  DriverManager.getConnection(url,  “jdbcuser”, “password”);

                 //Print URL and connection information
                  System.out.println(“URL: ” + url);
                  System.out.println(“Connection: ” + mySQLconnection); 
                 // Close the connection

             }    catch(Exception ex)  {

More importantly, You need to import the SSL certificates in the Java keystore and then provide the Java keystore location properties where the SSL certificates are stored. You may provide these values as -D Java runtime options on the command line as follows:

Alternatively, you may incorporate the Java keystore and truststore properties in the JDBC application:


To summarize, enabling SSL/TLS based MySQL connections ensure trusted communication between MySQL clients and the database server. It helps thwarting attacks related to eavesdropping MySQL communications, Man-in-the-Middle (MITM), Forged requests and so forth.  In my next post, I will discuss how to secure user accounts and enable stronger authentication controls in MySQL.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati Digg Google Yahoo Buzz StumbleUpon

A month ago, I had a chance to meet with John Beveridge (Deputy State Auditor at Office of the State Auditor of Massachusetts) at an ISACA event in Boston. During a casual chat, he briefly mentioned about the upcoming regulation highlighting “Mass 201 CMR 17.00 – Massachusetts Standards for Data Protection of Personal Information”  and it’s compelling security requirements !  With all curiousity…I had my first dig at Mass 201 CMR 17.00 last week… it is the toughest data protection law so far (as a Govt initiative for preventing identity theft).. I am quite amazed by the stringent rules imposed by this regulation for protecting the personal identity information of Massachusetts residents. I am not a lawyer or an auditor by profession…so here is a my layman interpretation of the regulation and its dictated requirements for securing personal identity information.

  • Comprehensive Information Security Program mandates ALL businesses that deals with personal identity information of Massachusetts residents  (in paper and electronic forms)  to provide  comprehensive documentation of all practiced security measures taken for preventing unauthorized access and ensuring confidentiality and integrity of the personal identity information.
    • Access control policies and rules for all employees who have access to identity information and enforce disciplinary action on those who violated the rules.
    • Upon employee termination, all physical and logical access privileges must be instantly revoked.
    • Third-party service providers need to comply with the Information security program and it requires a contractual binding before providing them access to personal information.
    • Identification of media including Laptops and PDA devices that store identity information and written procedures detailing how the physical access to those media is restricted.
    • Monitoring to verify the information security is operational preventing unauthorized access and support putting safeguards for minimizing both internal and external risks.
    • Require atleast an annual review and also whenever there is a material change has occurred in the business practices that relates to security and integrity of the information.
    • Documentation of incidents, response actions and post-incident review of events and actions.
  • Secure User Authentication
    • Control of user identifiers and secure methods for selecting and assigning passwords.
    • Use of authentication technologies such as Token devices and Biometrics.
    • Restricting access to active users only.
    • Blocking access to multiple unauthorized access attempts.
  • Data Encryption for all personal information in transit and storage.
    • Encryption of all records/files in storage (Laptops/other media) and transmitted over the wired/wireless networks.
  • Firewall protection and Operating System Security Patches must be updated to support maintain the integrity of personal identity information.
  • Malware and Virus protections ensuring all patches and definitions are updated on regular basis.
  • Education and employee awareness training on the Information security program and practices.

Mass 201 CMR 17 data protection requirements aligns well with Federal Trade Commission’s Red Flag rules on Identity Theft Prevention. Some of the security practices has already been in use at many big companies addressing PCI-DSS, GLBA and HIPAA requirements. At the outset, this is a big business boost to Security architects and consulting companies deal with providing Information Security and identity management infrastructure and solutions.  This regulation supposed to be effective on Jan 1, 2009 and now for some reasons the deadline is extended till May 1, 2009 – Not sure it helps everyone – but the deadline for compliance is chasing and not too far !

Onlinerel Facebook Twitter Myspace Friendfeed Technorati Digg Google Yahoo Buzz StumbleUpon

Important Disclaimer:The information presented in this weblog is provided “AS IS” with no warranties, and confers no rights. It solely represents our opinions. This weblog does not represent the thoughts, intentions, plans or strategies of our employers.