About 3 years ago, when I'd first decided to go down the route of getting my CCIE, I remember speaking a colleague who had done his a year or two before, and asking him was it worth the effort. He told me 'regardless of having the certification, the process will make you a better engineer'. When I asked him what he meant by that, he told me 'you'll see', then went off the pub for the afternoon leaving the hard work to his minion (me).
Now, as my first recert is getting close, I get what he meant. There's an awful lot of rubbish talked about the CCIE, and how guru-like CCIE's are begged on a daily basis to move to higher and higher paid jobs.. I can't deny, it is a door opener when looking for a gig, and sometimes clients specify they want a CCIE for a given role, but door opener is all that the certification is. You don't get an easy interview as a result - in fact when you say you're a CCIE, people try harder to catch you out, and you have to be better than ever to get and keep your credibility.
The reason the CCIE teaches you to be a better engineer, is not because it gives you god-like knowledge of the IOS (you do have to learn the IOS backwards, but this soon starts to slip and become out of date unless you keep it up), but it teaches you four things :
1) Discipline - when you're studying for the CCIE, you have to be able to come home from a tough day, go to your lab, and study for hours, day, after day, for an average of 12-18 months. You give up on your home life, lose weekends, don't see your buddies, and so on. It's hard - really hard, but you have to have the discipline to sit down, and get on with it. This stands to you afterwards, for example, before I did my CCIE, I couldn't work at home - I got nothing done. Now I work at home 4 days a week and get twice as much done as when I go into the office.
2) The use of the DocCD (sorry, I'm old fashioned). I don't remember every timer default, or how to configure every feature of the IOS. But I can find out pretty damned quick, and I never use google. You have to know the documentation site backwards to do the lab. During preparation, you learn how to navigate the documentation site quickly and effectively, and learn where everything is. In the real world, this is really useful every single day. No more searching google and hoping the answer isn't on experts-exchange.
3) Attention to detail - you can't make mistakes in the CCIE lab. One little thing can cost you the exam (the way the marking works makes a mistake on the underlying infrastructure mean that lots of questions which depend on it fail). So you have to be perfect every time. Personally, this was a bigger challenge than learning the IOS - when I did mock labs it was the dumb mistakes that got me every time. You have to work on that to a point where your planning and coding is perfect every time.
4) Troubleshooting - this is the big difference between the CCIE lab and all other Cisco exams. It's not enough to know the theory. You need to be able to set up a really complex network, spot the problems, and troubleshoot them quickly and effectively when the little trap that was left for you trips up your configuration. During your preparation, you spend hours and hours every week setting up scenarios to fail, so you can troubleshoot them. This is invaluable.
I would always recommend this process to anyone who hasn't done it, and wants to be the best engineer they can be to do the CCIE. Not because you learn lots of cool features (although you do), and not because you'll get a better paid job (hopefully you will), but because it teaches you how to work better, faster, and more reliable in the real world. This is why CCIE's are still so sought after.
One last point - don't be tempted with the shallow promises of braindump sites. By giving yourself this 'help', you're not giving yourself the main learning experience, you're only passing the exam. When you're interviewed, people will know. When you go to a job, you'll get found out..
Tuesday, April 27, 2010
Wednesday, April 14, 2010
DNSSec - and why the Internet probably won't break today.
If you're like me someone (quite possibly pointy haired) probably came running up to your desk in the last day or two telling you how the internet is about to come crashing down around us (yes, Cisco did promise it'd never be the same!) due to the deployment of DNSSec which is happening at the moment, and asked what you were doing about it. Articles like this really don't help.
DNSSec is something we all need to start looking at, and it is doing to deliver a lot of security benefits. It's also something which we need to actively test and probably change things within our infrastructures to make work. For a good overview of DNSSec, start your reading at wikipedia.
As with all DNS related subjects, there are two separate issues. Firstly, what we do with the domains we own - i.e. when do we start signing them - simple answer, not until the next tier up has (the current work is on the root servers, when that's complete the TLD's will be done, then you can start looking at your domains!). Secondly, how does it affect how we resolve other people's domains. This is where the current publicity is focused, and where we will probably have to do a little work soon.
In a simple scenario, where you have stub resolvers in your organization (i.e. your DNS servers point out to your ISP for recursive queries), there is little you need to change in the short term. This is mainly down to the fact that the main difference will be an extra flag set in the response to say 'this is Authenticated Data'.
If however, you do recursive lookups yourself (i.e. your DNS servers don't have a forwarder set, they just go out the root servers and start doing a full recursive lookup) then there is a change. Put simply, it will be asking for more data in the response from the various servers it talks to, using an extended version of DNS called EDNS. When the whole system is filled with signed DNS records, you'll be getting answers back which contain records larger then 512bytes (and probably fragmented packets). Most firewalls will block these large UDP DNS packets by default, as it has become accepted security practice to do so.
It's important to note that some firewalls will know the difference between EDNS, and will not apply the restriction to EDNS. For example, in earlier versions of PIX (6.3.2 and below), you had to manually configure the DNS fixup to permit DNS packets with the longer length :
fixup protocol dns maximum-length 4096
in more recent versions, it would be covered by :
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 4096
but here's the thing, it's EDNS not DNS, so it doesn't actually affect it. However, all firewalls are different in their support for EDNS, you do need to check this on your firewall/router to be sure that it's supported.
A good way to tell if your firewall/router is blocking these larger DNS packets, is to use the test listed at OARC. Here are two tests, the first one running to a non-EDNS capable DNS server (OpenDNS), and the other running to a EDNS capable one (Verizon). In both cases, they are running through an ASA (8.2.2) with default DNS message length of 512 :
dhughes@dynamips:~$ dig @208.67.222.222 +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"208.69.34.6 DNS reply size limit is at least 490"
"208.69.34.6 lacks EDNS, defaults to 512"
"Tested at 2010-04-14 15:32:28 UTC
Here - EDNS is not available.
dhughes@dynamips:~$ dig @158.43.128.1 +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"62.189.58.236 sent EDNS buffer size 4096"
"Tested at 2010-04-14 16:10:18 UTC"
"62.189.58.236 DNS reply size limit is at least 3843"
Here is a response which is considerably larger than 512. This means we can get the traffic through our firewall.
The Internet isn't broken. You should check to be sure that your firewall will pass the EDNS traffic ASAP, and if not, make the appropriate changes. You can tell the pointy haired boss who's sweating in the corner, that you've fixed the internet, and it'll all be fine...
DNSSec
DNSSec is something we all need to start looking at, and it is doing to deliver a lot of security benefits. It's also something which we need to actively test and probably change things within our infrastructures to make work. For a good overview of DNSSec, start your reading at wikipedia.
As with all DNS related subjects, there are two separate issues. Firstly, what we do with the domains we own - i.e. when do we start signing them - simple answer, not until the next tier up has (the current work is on the root servers, when that's complete the TLD's will be done, then you can start looking at your domains!). Secondly, how does it affect how we resolve other people's domains. This is where the current publicity is focused, and where we will probably have to do a little work soon.
In a simple scenario, where you have stub resolvers in your organization (i.e. your DNS servers point out to your ISP for recursive queries), there is little you need to change in the short term. This is mainly down to the fact that the main difference will be an extra flag set in the response to say 'this is Authenticated Data'.
If however, you do recursive lookups yourself (i.e. your DNS servers don't have a forwarder set, they just go out the root servers and start doing a full recursive lookup) then there is a change. Put simply, it will be asking for more data in the response from the various servers it talks to, using an extended version of DNS called EDNS. When the whole system is filled with signed DNS records, you'll be getting answers back which contain records larger then 512bytes (and probably fragmented packets). Most firewalls will block these large UDP DNS packets by default, as it has become accepted security practice to do so.
It's important to note that some firewalls will know the difference between EDNS, and will not apply the restriction to EDNS. For example, in earlier versions of PIX (6.3.2 and below), you had to manually configure the DNS fixup to permit DNS packets with the longer length :
fixup protocol dns maximum-length 4096
in more recent versions, it would be covered by :
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 4096
but here's the thing, it's EDNS not DNS, so it doesn't actually affect it. However, all firewalls are different in their support for EDNS, you do need to check this on your firewall/router to be sure that it's supported.
Testing
A good way to tell if your firewall/router is blocking these larger DNS packets, is to use the test listed at OARC. Here are two tests, the first one running to a non-EDNS capable DNS server (OpenDNS), and the other running to a EDNS capable one (Verizon). In both cases, they are running through an ASA (8.2.2) with default DNS message length of 512 :
dhughes@dynamips:~$ dig @208.67.222.222 +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"208.69.34.6 DNS reply size limit is at least 490"
"208.69.34.6 lacks EDNS, defaults to 512"
"Tested at 2010-04-14 15:32:28 UTC
Here - EDNS is not available.
dhughes@dynamips:~$ dig @158.43.128.1 +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"62.189.58.236 sent EDNS buffer size 4096"
"Tested at 2010-04-14 16:10:18 UTC"
"62.189.58.236 DNS reply size limit is at least 3843"
Here is a response which is considerably larger than 512. This means we can get the traffic through our firewall.
Summary
The Internet isn't broken. You should check to be sure that your firewall will pass the EDNS traffic ASAP, and if not, make the appropriate changes. You can tell the pointy haired boss who's sweating in the corner, that you've fixed the internet, and it'll all be fine...
Making changes to remote systems..
Every time we change something on the network, we take a risk. We may well have tested it in the lab/pre-prod environment, but there's always some risk. The nature of the change determines how much risk. It's why networks are most stable when the admin is on holiday.
If it's on a device that you are standing next to, you know that if it goes wrong, you can always recover it manually. But what do you do if it's remote? Now with cisco routers and switches - as long as it's something in the config, you can usually get back by rebooting*, and the startup-config will be reloaded. But it's a little bit embarrassing to have to call the office and get someone to do this for you. Also, if you're following a sensible change control process, you've made the change out of hours when there's no-one there to do this.
A really useful command here is 'reload in
1) write mem the old, known working, config
2) enter the command 'reload in 20' (or whatever interval you choose)
3) make the change.
console#telnet 192.168.1.250
Trying 192.168.1.250 ... Open
User Access Verification
Username: cisco
Password:
ADMIN-SW#wr mem
Building configuration...
[OK]
ADMIN-SW#reload in 5
Reload scheduled in 5 minutes by cisco on vty0 (192.168.1.150)
Proceed with reload? [confirm]
ADMIN-SW#
***
*** --- SHUTDOWN in 0:05:00 ---
***
ADMIN-SW#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ADMIN-SW(config)#int f0/4
ADMIN-SW(config-if)#sw acc vlan 2
Now, either the change works, and you maintain your access. Depending on the nature of the change, reconnect a new session to be sure. Then, when you're happy that it's not going to break again, enter 'reload cancel', and the scheduled reboot will be cancelled. If for some reason the change fails, then after 20 minutes, the device will reboot, and you can go back to it and work out why.
In this case, the change worked and I can reconnect :
console#telnet 192.168.1.250
Trying 192.168.1.250 ... Open
User Access Verification
Username: cisco
Password:
Reload scheduled in 4 minutes and 30 seconds by cisco on vty0 (192.168.1.150)
ADMIN-SW#relo
ADMIN-SW#reload cancel
ADMIN-SW#
***
*** --- SHUTDOWN ABORTED ---
***
ADMIN-SW#
ADMIN-SW#
If that hadn't worked (or if I hadn't gone back in to cancel it!) then after the five minutes the switch would reboot, and come back in its previous state. It's still an outage of course, and you still should have tested your change better, but at least you're able to recover, regroup, and try again.
I ALWAYS do this before a change on a remote device, even if I can't imagine any way that this change can break anything. Why - because I've been bitten too many times by devices far far away.
*ASA/PIX in FO mode is different. I'll post on it another day.
Wednesday, April 7, 2010
How to create a strong yet memorable password.
We're often told 'make sure you use a good password'. When we change our passwords at work we're often forced to add random characters into it to make it more complicated. This can have a detrimental effect on how how easy it is to remember. For a rant on the importance of passwords being memorable see this. This post is the second of a short series covering various areas of password management and related issues, and is going to cover a simple method for devising strong yet memorable passwords.
So how do we come up with a password which is memorable, and really hard to guess. We need to be sure it's a reasonable length, contains a mix both small and capital letters, numbers (ideally) and non alpha-numberic characters to make it had to guess. Unfortunately passwords like lk^7*Sn7@'h& are hard to guess, but also hard to remember..
We tend to remember things we associate images, sounds, feelings, taste, touch etc with, rather than lists of characters. Lines in songs, poems, phrases with films, headlines in newspapers stick with us because of an image we form in our minds, which we find easy to recall.
Take the time at the end of 'Back to the Future' when the Doc Brown comes back in the now flying DeLorian, and tells Marty that they need to go to the future. When told the road isn't long enough to get to 88Mph, who can forget the Doc dropping down his sunglasses and saying 'Roads, where we're going, we don't need roads!'.
Memorable right? If you weren't a fan of 'back to the future', take a song lyric you like, or line from a film/poem/court judgement you enjoyed, and write it down capitalized and punctuated.
Roads, where we're going, we don't need roads!
Lets take the first character from each word, and the punctuation, and we get :
R,wwg,wdnr!
So memorable that you will never need to write it down, and almost impossible to guess. If your system also want's a number, then either substitute, or add one.. So we could make it R,wwg,wdnr1 .
I've used this system for years, and don't have to write down my password to remember it, and have never had a problem with 'password to simple' complaints from the operating system.
Comments, as always, are welcome!
So how do we come up with a password which is memorable, and really hard to guess. We need to be sure it's a reasonable length, contains a mix both small and capital letters, numbers (ideally) and non alpha-numberic characters to make it had to guess. Unfortunately passwords like lk^7*Sn7@'h& are hard to guess, but also hard to remember..
We tend to remember things we associate images, sounds, feelings, taste, touch etc with, rather than lists of characters. Lines in songs, poems, phrases with films, headlines in newspapers stick with us because of an image we form in our minds, which we find easy to recall.
Take the time at the end of 'Back to the Future' when the Doc Brown comes back in the now flying DeLorian, and tells Marty that they need to go to the future. When told the road isn't long enough to get to 88Mph, who can forget the Doc dropping down his sunglasses and saying 'Roads, where we're going, we don't need roads!'.
Memorable right? If you weren't a fan of 'back to the future', take a song lyric you like, or line from a film/poem/court judgement you enjoyed, and write it down capitalized and punctuated.
Roads, where we're going, we don't need roads!
Lets take the first character from each word, and the punctuation, and we get :
R,wwg,wdnr!
So memorable that you will never need to write it down, and almost impossible to guess. If your system also want's a number, then either substitute, or add one.. So we could make it R,wwg,wdnr1 .
I've used this system for years, and don't have to write down my password to remember it, and have never had a problem with 'password to simple' complaints from the operating system.
Comments, as always, are welcome!
AAA Part 1 - Password Management - myths and a good rant.
Password management is a personal bugbear of mine. I think it's generally done really badly, and the security industry has adopted a number of policies which are universally accepted as best practice, without much thought as to why. I call them the myths of password management.
This post will be the first of a short series covering various areas of AAA, and is going to cover the myths around password quality and rotation.
The Myth of password rotation
I've always argued that there are two really important objectives when it comes to passwords :
1) No-one can find out your password.
2) You can remember the password.
Over simple? Not really. When you boil it down, this is what you need from a password.
Security managers tend to focus on the first objective, without much attention being given to the second. I'd argue that both are equally important. Let's take a scenario (which is amazingly common) where policy is set that passwords must be changed every 12 weeks. The first question I'd have is why?
What does this actually achieve? If the password is not guessable, then constant rotation achieves nothing positive. I'd won't go as far as saying it should never be changed (although it is the logical conclusion of my argument), but if objective 1 has been achieved, then there is no need for constant password rotation.
In fact, the one thing that is achieved by over-regular password changes, is we will fail to satisfy objective 2. A place I recently worked make me change passwords on about 20 different systems every 2 months. Most of those systems, I didn't log onto very often. As a result, I often had two or three revisions of my password in play at any one time. I couldn't remember which password to use in which place. And after one has been deprecated a while, I don't remember it at all. Which means I need to document it somewhere. Now we've broken objective 1.
I use a system (I'll do a separate post on how) for creating passwords which makes them unguessable(tm) - (but very memorable). There are plenty of others too. Any password can of course be broken by a brute force attack, but assuming any kind of sensible lock-out mechanism is applied, I'm happy to say that no-one knows my password. If someone logs into a system with my credentials - it had to be me. No excuses. The term often used for this is non-repudiation - in other words I can't deny it was me.
Once my password gets written down, even in some kind of encrypted password management tool, we can now only go as far as I'm fairly sure no-one knows my password. Other people have access to the tool (anything stored on my 'domain member' PC is readable by admins), there may be a flaw in the password management tool. You see the difference - we've gone from definitely, to fairly sure. Objective 1 is now no longer satisfied, and there is no longer non-repudiation.
To put it very simply, if the password is well formulated, and your systems have a sensible lock out mechanism, then constantly changing the password is not going to have any positive affect on your security. Conversely, constantly changing passwords make people write them down, this means they are no longer unguessable. This has made your security worse.
Myth - you need at least 8 characters in your password
This one really annoys me. Lets say a password using a combination of letters, capitals, numbers and non-alphanumberic characters (based on my Mac keyboard) gives you something like 108 to the power of X, where X is the number of characters in your password (in other words, there are 108 characters that 'could' make up each character) as the number of combinations that you could use for your password.
A 5 character password has a 1:14.7bn chance of being guessed, a 6 character password has a 1:1.5tn chance of being guessed, a 7 character password has a 1:171tn chance of getting guessed, and an 8 character password has an 1:18.5 sextillion (thousand trillion) chance of being guessed.
As long as you use a sensible way of coming up with passwords, and lock out an account after a sensible number of failed attempts - then the difference between 14.7 billion (5 characters) and 18.5 sextillion (8 characters) is irrelevant. To put it in context, the chance of winning the UK lottery jackpot is an easily guessable 1:14 million. In reality the odds will be lower than that as most people use more letters than anything else, and you'll get a couple of goes before the account locks, but you're not going to guess it.
'As long as you have good passwords and a sensible lock out policy....'
You've probably noticed that written a few times. If you've ever been in a meeting with me you've probably heard me chant it like a mantra. The more astute amongst you are hiding in the long grass waiting to pounce with something like 'ahh, but good security comes from layering good practices in case one fails - like the system that doesn't have the lockout policy set'.
Yes, that's true. But here's the thing, if you have an accessible system that does not lock out properly, and an attacker decides to run a brute force attack to guess the password, then it makes no difference if the password was changed yesterday or 6 months ago. They're either going to get it or they're not. You're into attack detection and mitigation now.
Which leads us predictably onto the question of 'how do you make users make their passwords complicated?'. It is the big question of all this - and focusing effort here, rather than on satisfying myths, is how you will achieve improved security. And of course, if I had a magic answer for this, I'd be so stinking rich I wouldn't be wasting good beach time on writing this post.
The most cost effective (best benefit for your buck) is always education, combined with the tools available within your NOS to enforce complexity. Teach people how to create good passwords - so that when windows tells them to make it complicated, they know how to do so easily. Teach them why it's important. Point out that if someone logs in as them from the outside and does something bad because they had a crappy password, they will get blamed and fired. Once a year, a compulsory 1 hour session from IT security for all staff will take less time, and achieve more, than making them change their password all the time.
If you have the need and the budget, and have the infrastructure and skills to support it, then of course OTP systems and/or biometrics will give you a great solution. It's complicated and expensive, but fulfills the requirements really well and takes the role away from the user.
Comments/flames welcome :-)
This post will be the first of a short series covering various areas of AAA, and is going to cover the myths around password quality and rotation.
The Myth of password rotation
I've always argued that there are two really important objectives when it comes to passwords :
1) No-one can find out your password.
2) You can remember the password.
Over simple? Not really. When you boil it down, this is what you need from a password.
Security managers tend to focus on the first objective, without much attention being given to the second. I'd argue that both are equally important. Let's take a scenario (which is amazingly common) where policy is set that passwords must be changed every 12 weeks. The first question I'd have is why?
What does this actually achieve? If the password is not guessable, then constant rotation achieves nothing positive. I'd won't go as far as saying it should never be changed (although it is the logical conclusion of my argument), but if objective 1 has been achieved, then there is no need for constant password rotation.
In fact, the one thing that is achieved by over-regular password changes, is we will fail to satisfy objective 2. A place I recently worked make me change passwords on about 20 different systems every 2 months. Most of those systems, I didn't log onto very often. As a result, I often had two or three revisions of my password in play at any one time. I couldn't remember which password to use in which place. And after one has been deprecated a while, I don't remember it at all. Which means I need to document it somewhere. Now we've broken objective 1.
I use a system (I'll do a separate post on how) for creating passwords which makes them unguessable(tm) - (but very memorable). There are plenty of others too. Any password can of course be broken by a brute force attack, but assuming any kind of sensible lock-out mechanism is applied, I'm happy to say that no-one knows my password. If someone logs into a system with my credentials - it had to be me. No excuses. The term often used for this is non-repudiation - in other words I can't deny it was me.
Once my password gets written down, even in some kind of encrypted password management tool, we can now only go as far as I'm fairly sure no-one knows my password. Other people have access to the tool (anything stored on my 'domain member' PC is readable by admins), there may be a flaw in the password management tool. You see the difference - we've gone from definitely, to fairly sure. Objective 1 is now no longer satisfied, and there is no longer non-repudiation.
To put it very simply, if the password is well formulated, and your systems have a sensible lock out mechanism, then constantly changing the password is not going to have any positive affect on your security. Conversely, constantly changing passwords make people write them down, this means they are no longer unguessable. This has made your security worse.
Myth - you need at least 8 characters in your password
This one really annoys me. Lets say a password using a combination of letters, capitals, numbers and non-alphanumberic characters (based on my Mac keyboard) gives you something like 108 to the power of X, where X is the number of characters in your password (in other words, there are 108 characters that 'could' make up each character) as the number of combinations that you could use for your password.
A 5 character password has a 1:14.7bn chance of being guessed, a 6 character password has a 1:1.5tn chance of being guessed, a 7 character password has a 1:171tn chance of getting guessed, and an 8 character password has an 1:18.5 sextillion (thousand trillion) chance of being guessed.
As long as you use a sensible way of coming up with passwords, and lock out an account after a sensible number of failed attempts - then the difference between 14.7 billion (5 characters) and 18.5 sextillion (8 characters) is irrelevant. To put it in context, the chance of winning the UK lottery jackpot is an easily guessable 1:14 million. In reality the odds will be lower than that as most people use more letters than anything else, and you'll get a couple of goes before the account locks, but you're not going to guess it.
'As long as you have good passwords and a sensible lock out policy....'
You've probably noticed that written a few times. If you've ever been in a meeting with me you've probably heard me chant it like a mantra. The more astute amongst you are hiding in the long grass waiting to pounce with something like 'ahh, but good security comes from layering good practices in case one fails - like the system that doesn't have the lockout policy set'.
Yes, that's true. But here's the thing, if you have an accessible system that does not lock out properly, and an attacker decides to run a brute force attack to guess the password, then it makes no difference if the password was changed yesterday or 6 months ago. They're either going to get it or they're not. You're into attack detection and mitigation now.
Which leads us predictably onto the question of 'how do you make users make their passwords complicated?'. It is the big question of all this - and focusing effort here, rather than on satisfying myths, is how you will achieve improved security. And of course, if I had a magic answer for this, I'd be so stinking rich I wouldn't be wasting good beach time on writing this post.
The most cost effective (best benefit for your buck) is always education, combined with the tools available within your NOS to enforce complexity. Teach people how to create good passwords - so that when windows tells them to make it complicated, they know how to do so easily. Teach them why it's important. Point out that if someone logs in as them from the outside and does something bad because they had a crappy password, they will get blamed and fired. Once a year, a compulsory 1 hour session from IT security for all staff will take less time, and achieve more, than making them change their password all the time.
If you have the need and the budget, and have the infrastructure and skills to support it, then of course OTP systems and/or biometrics will give you a great solution. It's complicated and expensive, but fulfills the requirements really well and takes the role away from the user.
Comments/flames welcome :-)
Subscribe to:
Posts (Atom)