|
||||||||
|
|
![]() |
|
|
Reader Feedback and Insights I don't believe for a second that biometrics will replace passwords, at least not in the near future ["Biometrics Ready to Replace Passwords, Vendors Say"]. My reason is simple. Currently, if I have several accounts at different organizations, I use different passwords for them. If one password is compromised, the others are safe. If, in the future, all of the accounts use the same biometric identifier (say, retinal or fingerprint scan), then once one organization has been compromised, all of my accounts are in danger. These scans must be stored digitally; therefore, my major concern is unauthorized use of my digital scan. What precautions will be taken to ensure that the scanning device is not bypassed and that the raw digital scan is not used to access my information without my knowledge? --William Mark P. Wade, Daon vice president for the Americas, responds: Your reader makes two excellent points. How does one handle a compromise in the system? And how does one ensure that the stored credential (user ID/password, biometric, certificate, etc.) will not be used for illicit purposes, without user consent? While one will always endeavor to deploy the most complete and secure system, using best-of-breed components, in terms of biometric algorithms, reader devices, cryptographic algorithms, secure hardware, etc., compromises can happen. This is why "best of breed" security requires enforceable business logic. There are a number of methodologies, which can be constantly reviewed, such as: Revocable Templates. One does not store an image of the fingerprint (unless required for background checking), but a digital template of the user's fingers. These digital templates are algorithm-specific. Should the credential be compromised, a new template can be captured from the user for use with a different algorithm. This would render the compromised template void. Random Seed. Another method is that of adding a random "seed" to the template and using both as the virtual template. Should the template be compromised, one changes the seed and the virtual template is now different from the one compromised. Multiple Biometric Templates. Multiple biometrics are captured during enrolment (multiple fingers, iris, etc.). One can increase or decrease the level of biometrics required on an ad hoc basis. In the event of a compromise, multiple biometrics would require an attacker to have multiple biometric templates. Indeed, multiple organizations can have different templates and may also be using different algorithms. Random Template Requests. Organizations that enroll multiple biometrics can enable the system to request the user to use varying biometrics and varying combinations of biometrics at each login (combinational biometrics, random finger request, or iris scan, etc.). When an organization has to contend with unauthorized use of a user's credentials, this problem is a potential threat, regardless of which system one deploys. This could be overcome by using cryptography and secure hardware to ensure that the matching of the template never leaves the secure hardware (Hardware Secure Module). One should use a secure channel between the client and the server (ssl, tls, etc.) to ensure that the path between the client and the server is not compromised. There have been recent strides in device technology to allow secure encryption keys (symmetric keys, PKI, etc.) to be embedded in the device, and they can be updated in the event of a compromise. This ensures a secure channel between the device and the client workstation, and further, between the client workstation and the server. Clearly, when it comes down to trusted environments, it is more than prudent to have a comprehensive usage policy. Much like a privacy policy, a usage policy should be clearly defined, regularly updated, legally binding, and readily available to each user. We value your feedback and insights. Feel free to send a letter to the editor. Letters may be printed, unless otherwise specified, and edited for clarity or length.
|
Editor
Contact the Editors |
| Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |