To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
Smart card systems consist of the cards themselves and the back-end databases containing their data. The cards contain chips that can carry a range of information from just authentication credentials by themselves to customer information, account information and even sums of money.
The beauty of a smart card is that it provides an extra layer of defense for an authentication system. If someone has to insert a card into a reader while also entering a user ID and password, there are two systems an attacker would have to break to gain access. This is a textbook example of a two-factor authentication system.
The idea behind a smart card is that it holds all the authentication credentials on a chip. Unlike user IDs and passwords, which can be forgotten or forged, smart cards are harder to exploit. But the chips on the cards are still vulnerable; if the data on them isn't encrypted, there are ways a malicious user with a reader can sift the data off the card. The small size of the chips on the cards only allows a limited amount of memory, which also limits the size of the encryption keys the card can hold, which in turn weakens the strength of the encryption of the card.
But these vulnerabilities are unique to the card itself. As for the databases supporting smart cards and holding their data, the vulnerabilities are the same as for any server-based system. There's nothing special about them just because they're part of a smart card system.
The same rules apply to database servers -- or for any server, for that matter. The database and its hosting server should have up-to-date security patches from the vendor, and access should be limited to those who need it. Data sent to and from the database should be encrypted in transit and sensitive data in the database itself should be encrypted.
In addition, the server hosting the database should have all unnecessary services turned off. The server should be dedicated to that database only and no other applications besides the operating system required to run the server. The only ports open should be those required for access to the database and should be filtered to only allow access from the application server needing to connect to the database. The database shouldn't sit in a DMZ and should be behind a firewall without a direct connection to any outside network.
But, that said, in most cases, since smart cards are used mostly for authentication, they're linked to directory services like Active Directory and LDAP. Both of these systems allow smart card data from individual users to be integrated into their profile. Though Active Directory or LDAP have their own security issues, unlike plain old databases, they encrypt authentication data by default and tend to be more secure.
More information:
|
