Authentication in a B2B environment

I have had a running discussion with a colleague of mine concerning the use of password expiration for B2B sites. We are talking here about partner sites accessed through the Internet to some type of web portal. My argument was that for a B2B site without mission critical or very sensitive data, it does not make sense financially or from a security perspective to require the external organizations to change their passwords or force two-factor authentication. Let's step back for a minute not to the nine solutions, which are running through your head right now, bit to the question of what we are trying to prevent - the question.

We are trying to prevent one of the following:

• An unauthorized person at the partner organization from accessing someone else's account and information, or performing some type of fraud with someone elses account.
• An unauthorized reckless wrongdoer on the Internet from accessing the partner's information, or accessing the target system and doing bad things that cost money to either side.
• Someone leaving partner firm A and going to work for partner firm B and still having their account active.

There are probably several I cannot think of right now, but let's concentrate on these for a moment, and break them down into several risks and address them.

Risk 1 - password cracking by someone internal or external to the partner firm guessing the password.

If the account locks after several attempts, then this will be largely ineffective, and if it doesn't they would be able to script a password cracker that would most likely break the password long before the password was due to change anyways. That is unless you are going to have them change their password daily (good luck with this one). But just use a token you say, then they wouldn't be able to break their password. This is certainly a good solution for very sensitive data, but for a large group of users it gets very expensive, and usually results in the token being taped to the monitor, perhaps with the code attached to it as well. Certificates are another solution, but are not as portable as most people would like and are a bitch to manage and revoke. The more you force a user, especially someone at an external firm who probably doesn't care much about their own company's security and even less about yours to change their password, the more likely the password will be written down on their monitor, or in the clear in a spreadsheet shared by everyone in the company.

Risk 2 - person leaves partner company A and goes to work for partner company B and their account is not disabled.

If the accounts are disabled after x days of not being used then this will have the same effect without causing heartache, and I would argue less security for the people that are logging in.

For what it is worth, here is my take on this, but I would appreciate any feedback on differing opinions.

1. Force users to pick passwords that are forced to be complex (contain no dictionary words, have a suitable length, Upper/lowercase, special characters, etc.)
2. Disable accounts that have not been logged in for more than x days
3. Lock accounts after 5 invalid attempts
4. Only use tokens for very sensitive sites with a smaller number of end users. Since two factor or ten factor authentication won't prevent the trojan installed on Partner A's system from letting the user logon and piggybacking on that connection the whole way to your site.
5. Audit authentication events and trigger alerts on things like several invalid attempts for several accounts being accessed from the same source, or a large number of attempts in a short period of time

In my opinion we either need to force users to change their passwords hourly or not at all. Passwords are ineffective for truly good authentication, but the alternatives are either too expensive, too difficult to mange or both to make good business sense. Furthermore, the strong authentication solutions are ineffective against today's threat, and their advantages are often circumvented by end users due to their difficulties. We need to make it easy enough for users to use without needing to circumvent the controls in place, and use risk analysis to ensure we are placing controls at the correct points to mitigate the problems mentioned earlier. Additionally, when you look at the reports from the Anti-phishing Workgroup, the FFIEC mandates that went into effect at the end of 2006, that included amongst other items, strong authentication has had no effect on phishing.