Are biometrics easy to deploy? They are easy to deploy in building access-control systems, or on a case-by-case...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
basis for securing individual devices like laptops, or embedded into authentication tokens. But they are hard to deploy by themselves on networks. For example, imagine that a company has deployed a fingerprint-based system for remote authentication. How is that supposed to work? Would the fingerprint simply be a substitute for a memorized password? If so, then there's nothing to prevent an attacker from sniffing a fingerprint reading and then replaying it later to masquerade as the fingerprint's owner. The only way to prevent such masquerades is by installing cryptographic protections in your fingerprint readers. To make the cryptography work, however, you have to install and maintain cryptographic keys in all of those readers. This gives your administrators the same type of chore they face when deploying authentication tokens, like one-time password devices or smart cards. But that's not all. Once you've managed to deploy the readers' cryptographic keys, you still have to collect biometrics from all of your registered users. That's going to take a good deal of training in typical organizations. Please briefly explain pros and cons of outsourced PKI vs. in-house? I like to make an analogy with a retail company that issues its own credit cards. Back when credit cards were really new, there were a few companies that provided regional credit cards. Department stores brought the credit card operations in-house when they realized it gave them better control over who received cards (an issue of managing risk and the cost of fraud), and that revolving credit could itself be a source of income. Now, of course, nobody has figured out how to make money (yet) by issuing in-house public key certificates, but the issues of costs and risk management do apply to PKI. If you outsource your PKI, you pay others to develop and maintain the expertise in the technology. This might be a good choice in certain cases. For example, if you're in a huge hurry, you might be able to roll out something faster if you outsource. Also, if you're simply experimenting with new business systems and don't want to commit to PKI yet, outsourcing might be a good idea. On the other hand, if your organization is committed to PKI, then you give up certain things by outsourcing. First, you have to pay a premium to cover the PKI vendor's perceived liability. This might consist of genuine insurance payments. More often, it might simply consist of excessive caution on the vendor's part that increases your deployment and maintenance costs. With outsourcing, you also give up the opportunity to build in-house understanding of how to make the systems work. Long term, this may help you reap even greater benefits from the technology. It also frees you from any biases the PKI vendor might have with regards to equipment selection. If we follow our credit-card analogy a bit further, note that today's credit cards are dominated by "outsourcing" organizations (member banks of Visa, MC, Amex, etc.). Long term, we'll no doubt see some central agencies like Visa, MC, et al, in the PKI space. Can I identify users/sessions without password protection? It all depends on your environment. I've written about trying to infer identities based on location information or addresses. If you aren't facing a strong risk of subversion or masquerade, then there's often a way to associate addresses or locations with identities. However, it's not a reliable technique. There are usually lots of ways to subvert it. Does an 802.11 wireless network create new authentication problems? Definitely. It makes sniffing easier than it has ever been. People with laptops and wireless interfaces can "surf" your private network just by parking near your building, intercept passwords and then log on. Developers have tried unsuccessfully to implement security measures that were both light from an engineering standpoint and strong from a security standpoint. To my knowledge, every security scheme that's been designed expressly for 802.11 so far has been broken. Why not use biometrics for stronger integrity of usernames, then add strength through the use of passwords? Both the biometric reading and the password can be "sniffed," that is, they can be intercepted by an attacker. Then the attacker can replay them later and masquerade as the owner of that biometric and password. What prevents someone from stealing a "soft token" and using it to create multiple "valid" tokens? Nothing at all. At that point, the only thing that can prevent masquerades would be PIN protection embedded in the soft token. Unfortunately, that is weak protection indeed, since many soft tokens can be tricked into revealing if the PIN is guessed correctly. If a site really needs to prevent multiple tokens, then soft tokens are not a good choice. There are ways to make soft tokens resist attack, but not all soft token vendors use them. What are the security risks with allowing employees to use technology such as instant messaging? The most obvious problem is that instant messaging transmits its messages "in the clear" so that anyone with a sniffer on the Internet can intercept the contents of such messages. Even worse, a sniffer can probably intercept user names and passwords, allowing an attacker to masquerade as an instant message participant. How can I get the host name of a remote user? See the question above about identifying users/sessions, since this is a question of associating identities with locations or addresses. The way to do it depends entirely on your networking environment. To consider a common example, look at the Internet. There's no 100% reliable way to identify hosts on the Internet. Under ideal conditions, you can identify the source of Internet messages by looking at the source IP address in a packet. Next, you use the Domain Name Service (DNS) to convert the IP address to a domain name. That gives you the host name. In practice, it's easy to forge the source address in a single IP packet, especially if it's sent using UDP. It's trickier but still possible to forge addresses in TCP traffic. Moreover, there are several ways to trick DNS to produce the wrong domain name for a given IP address. And, of course, many organizations today use DHCP to dynamically assign IP addresses, so the host connected to a particular address today will probably be someone else tomorrow. So in theory, you can find the host name but in practice you can't have much confidence in the host name you retrieve. What is your opinion of the IBM Lotus Notes/Domino password, public-private key scheme? Like so many security mechanisms on the market, it's far, far better than using nothing at all. It usually presents the attacker with enough of a challenge to send him somewhere else. The principal weakness is that you have those key files that hold the private keys, and the key files are protected by memorized passwords. No doubt someone has constructed a password-cracking tool that can unlock a key file by applying a dictionary attack to it. If you are implementing a remote-access VPN solution using PKI, do you still have to have users authenticate against a database on the VPN device or the NT domain database? This depends on how you've constructed your VPN and your internal defenses. Ideally, you should only have to authenticate the host once to the VPN device. That should be sufficient to set up the IPSec tunnel. Often, however, you have to authenticate yourself a second time to the internal host environment, like an NT domain, since the VPN authentication doesn't actually involve your client's domain authentication software -? the VPN authentication is a completely separate process. Thus, the PKI credentials used to establish your VPN probably can't be used to authenticate activities at other levels of the protocol stack. This isn't necessarily because it's unsafe or impossible to use the credentials that way; it's just that public key software isn't always as general purpose as we might wish. There actually might be some products that let you use your credentials for both. My reading of the Win 2000 documents seems to hint that they expect to support such behavior, but I've never tried to make it work in practice. Is there a way to set the http password to expire on a regular basis? It depends on your server, though I know of no standard technique that would work for all servers. However, I'm not a fan of expiring passwords. If you are expecting users to remember passwords, it's a bad idea to change them. Otherwise, the users will feel inclined to write them down to remember them. There may be situations where expiration is a good thing, but that's generally in a situation where you acknowledge that people will keep a written copy of the password that gets changed. What is the best authentication system for SSO? Single sign-on means different things to different people. I suspect the most practical approach today are those based on centralized authentication servers like Secure Computing's SafeWord PremierAccess or perhaps those that piggy-back atop Microsoft domain authentication or the newer Kerberos implementation. It's important to decide how much convenience you want and how that trades off against your security concerns. A problem with the central servers is that it provides a single, tempting target for an attacker. In practice, the SafeWord servers have been in operation since the '80s, and I've heard no reports of server penetrations.
To purchase "Authentication: From Passwords to Public Keys," click here.Wouldn't biometric authentication eliminate password management costs, which are huge?
They replace password management costs with the maintenance of these biometric readers, which are hardware devices that break down and must be replaced.