As a Brit, I like to use some of our classic literature and movies to analogize some of the security topics I am invited to talk about. So for this month's article, I would like to use the movie Monty Python and the Holy Grail to explain what can go wrong with authentication.

Toward the end of the movie, the brave knights are tasked with crossing the infamous Bridge of Death to continue with their quest. Sir Lancelot, the bravest of the knights, takes the challenge and is met by the keeper of the bridge, who asks three questions of the knight, who will be permitted to pass only if he answers correctly. He accepts the challenge and in the humorous style of the movie is asked, "What is your name, what is your quest, and what is your favorite color?" On answering these obviously simple questions, the bridgekeeper allows Lancelot to cross the bridge to safety.

Subsequently, Sir Galahad calmly approaches to take the test, having seen and heard the challenges. Unfortunately, on being asked the final question, he wavers and says, "Blue...no, yellow" and is immediately whisked into the air and cast into the Gorge of Eternal Peril below the bridge.

So what does this prove, apart from the tendency of the British to find humor in anything? I believe that this shows that the type of authentication, in this case an inelegantly worded "challenge and response" set of questions, is not the best type of method for validating everybody. I have seen actual computer-based challenge and response questions that specify something like, "What is your favorite drink/band/song/movie?" To many people, these may be so fixed in their minds that they know them today, tomorrow, and even next year. But there are just as many people who will change their mind even within the next 24 hours.

So the first thing we can learn from this is that we often need many different types of authentication to assist the different types of people who need access to your systems. In fact, one of the first lessons I try to pass on to my clients when I start to talk about their security requirements is to "free your mind"--that is, not to restrict themselves to what they have done before or what they believe the OS limits them to but to consider what the business needs. Once they have identified this, they need to find ways to achieve the requirements--by either internal development or external tools.

As an example, most systems (and the i5/OS is certainly no exception) will have a small group of super-users who have a lot of authority because they have many critical system tasks to perform. If they are in their regular offices and the security guard/keypass system has allowed them access to the building, it is likely that a simple, strong password will suffice. However, if these users need to have direct access to the iSeries from home or a hotel room, maybe a stronger authentication methodology would be necessary. For those, I recommend a form of token-based, two-factor authentication:

1. Something they have, such as a token card or key fob
2. Something they know, such as a PIN or passcode

Many organizations use these sorts of technologies at network entry points, RAS servers, etc. However, we have seen many recent audits strongly recommending these for iSeries access, too. (If this is a requirement within your organization, a couple of vendors do provide such technology on the iSeries.) Returning to my original point: This is not a solution for all users, but it may be critical for some of the high-level users.

Let's move to the other end of the scale: the much-maligned password. Again, trying to set one security policy for the whole user base across the iSeries will not be good practice. The average user in the distribution center, at the hotel front desk, or in the sales inquiry office needs a simple, easy-to-remember password that will not expire too frequently. However, for the system users who deal with critical data, a more complex password would be advisable.

The audit companies and security advisors can spend from now till doomsday disagreeing about whether a password length should be a minimum of 6, 7, 8, 9.... In the end, the value that you set QPWDMINLEN to in i5/OS is nowhere near as important as the education you give your users on what the password should be. There is a classic tale (maybe an urban myth, but it proves a point) of a security review at the Paris offices of a large multinational computer manufacturer (I think you know who I am talking about here). At the end of the audit, the manager was surprised to hear that a high percentage of the personnel were using exactly the same password. On investigation, the manager found that they had not been breaking company rules, but instead had used the same source for password ideas. Every month, as the time for the password change rolled around, most of the people on the sunny side of the office gazed out of the window and looked at the same billboards. And that's why so many users were using "Renault" or "Chanel" at the same time.

That's the problem with passwords--that moment when your mind goes blank and you have millions of words in that filing system that is your brain but none of them come out. So why not help your users with some tips?

• Use as your base word something that changes in your life regularly, e.g., the book you are reading, a song you heard today, or the last movie you saw (for example, "grail").
• Incorporate some numbers into your base word by appending a value to the end (grail99), replacing the vowels with the same numbers each time (gr98l), or replacing the vowels with numbers representing their position in the sequence "AEIOU" (gr13l).

Simple advice like this should be part of the induction training program for all new employees. Don't just trust them to be able to think of something that a) they can remember and b) you regard as strong enough. If you don't train them, they will either overload your Help Desk with "reset" calls or write their passwords on Post-it notes under the keyboard.

Another critical aspect of security training that is often overlooked is how your users will be interacting with the Help Desk and IT security teams. Not many people know that some of the most successful hacks that the infamous Kevin Mitnick perpetrated were through social engineering. This involved posing as someone from the security team of an organization and finding a way to persuade users to give up their passwords. If you don't warn your personnel that the Help Desk personnel will not ask them for their password, then you are asking for trouble.

To give you an example of how successful social engineering can be, a survey was carried out at a London train station, where commuters were asked to give up their passwords to a researcher. Over 70% of those interviewed agreed to announce their passwords. And what magnificent prize was offered to entice the public? $1000, $100, an iPod, center court tickets for Wimbledon? No, it was a bar of chocolate. Admittedly, it was English chocolate, which is some of the best in the world, but it was a small price to pay to give up something that should be held close to the chest.

My co-author of the "Security Sentinel" column, Pat Botz, has been a shining light in the promotion of the Enterprise Identity Mapping (EIM) technology from IBM. One of the main benefits of EIM is that you can configure single sign-on for your IBM midrange platforms and some associated technologies. Whilst I applaud IBM for its work in this field, I find that most people do not really understand the practical capabilities of the technology. Every time I sit down and discuss EIM with my clients, they go through a roller coaster of emotions.

Their first thought is that they have found their Holy Grail. They can please their C-level executives as well as their loudest critics, who forever complain about how many passwords they need to remember and how many times they need to enter those passwords. But then reality sinks in: What is the weakest link in the chain? Can it be hacked so that the attacker will have the "keys to the kingdom"? Is there an advantage to enforcing password re-entry on the most critical systems? What about the many other user registries outside of the scope of EIM, which the user will still need to authenticate to?

My suggestion is that, whilst recognizing the power and convenience of EIM, it is only part of the puzzle. As I mentioned, a security administrator needs to analyze the needs of each type of user. But just as importantly, he must analyze the needs of each user registry that a user may need to authenticate to. A great solution would be a combination of many technologies:

• EIM on as many systems as practical
• Password synchronization to other registries not covered by EIM
• Very strong passwords or two-factor tokens for high-level users, remote access, and critical systems

Other technologies are starting to become more mainstream and therefore more relevant and applicable to the iSeries. For example, with biometrics getting more and more prevalent, many laptops are now available with fingerprint readers. Other types of biometrics are also touted, such as iris readers and, more recently, vein-pattern recognition. But all of these carry the same baggage--cost, support logistics, and false positives and false negatives--causing low adoption.

Another technology that is coming to the forefront of authentication is in the area of federated identity management. Next month's article will cover this in detail, along with associated identity management topics.

So free your mind from the constraints of what you have always done or the recommendations of some theoretical security standard. Authentication for your users should be designed so that it is sensible, secure, and usable. For most organizations, a combination of methods should be used, based on user roles and criticality of systems.

Returning back to my example from the Holy Grail movie, this scene ends when the bridgekeeper changes his final question to "What is the air-speed velocity of an unladen swallow?" King Arthur, forever intelligent, challenges the bridgekeeper to clarify whether he means an African or European swallow. When the bridgekeeper admits that he doesn't know, he is cast into the abyss below. Authentication can be painful for the questioner, too!

Martin Norman is Senior Systems Engineer for SafeStone Technologies, an IBM BP specializing in compliance and identity management. As one of the original developers of SafeStone's security portfolio, Martin has performed security audits and advised on installations for clients throughout the United States and Europe. Martin can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Getting Started with Ansible on IBM i

Maximize the power of your lines of defense against cyber-attacks with IBM Storage FlashSystem and IBM Storage Defender

Building the human firewall: Navigating behavioral change in security awareness and culture