Authentication News Roundup

Two items tonight, on the Authentication Hotline

Rubbish Disguises
City financial types are being directed by firms and industry bodies to wear casual clothes on the riot days, so they don't stand out. It's a lovely idea -- take one middle aged bank operative, replace suit with M&S chinos and polo shirt and Shazam! indistinguishable from a climate change protester.

Or maybe you could try wearing a keffiyah. That should do it.

Effective Disguises
New spam trend: We're starting to get stiffy lolly spam pointing to .cn sites. The sender appears to be bright enough to realise that firms have filters which spot this a mile off, but also that there will be approved addresses bypassing the filters. So this mail is spoofed from plausible addresses. Yesterday I removed unisys.com from our approved list which should stop the immediate problem, but the attack is going to work until there's some way of authenticating envelope sender addresses.

The problem will really kick off when spammers realise that everyone has a bypass for FT.com because their news alerts are totally indistinguishable from spam.

I guess we need a checkbox. For any bypass, domain or just a single address, you need to be able to say "only bypass if the sender is spf authenticated".

Naming Risks

Jerome Kerviel seems to be on the edge of getting a risk named after him. This is not the sort of distinction that will make his mummy proud, but it is a distinction nonetheless. About the only other named risk I can think of immortalises the otherwise obscure Herstatt Bank closed by regulators in 1974 before it had paid out on its forwards settling that day.
Kerviel's activities are set out in the Mission Green report, and if you were following the story at the time, it's interesting to see how wrong the initial spin was: He wasn't stealing passwords, he wasn't modifying control spreadsheets. He was exploiting his back office knowledge, but at a higher level: he knew how to use cancellations and corrections -- all the points where control can't be watertight because trading isn't -- to get his positions off the records, and he'd been doing it for some time. (It was only right at the end that he started to fake forwarded email -- nothing complicated, just editing a real forwarded email.) So this gives us a useful term: Kerviel risk is exploitable vulnerabilities -- uncompleted cycles of review and follow-up -- in a control system. A short name for a rather complicated concept, so maybe it'll stick.
No this definition means that Kerviel's name is not correct for authentication-abused-to-approve-fraudulent-actions risk. But Jagmeet Channa has come along just in time to help us out. He stole a couple of passwords to approve his multi-million pound transfers to his accomplices in N. Africa and Manchester.
The problem is figuring out what risk we're naming here. Channa's not talking so we can't tell if it's:

• Password stealing? -- he certainly did, but maybe that's not the point
• Inserted Insider?
• Coerced Insider?
• Criminal Mastermind who recruited outside help?

I'm going with the authentication, for the present. Channa Role Risk.....
And what makes this a security story? Well, the investigation started by interviewing the colleagues whose passwords Channa used. Don't fancy being in an interview like that? Then guard your password.

Microsoft Abandons AD Shock!

The Microsoft Dynamics CRM product is probably on the shortlist for every greenfield CRM implementation. It's on ours simply because we've slipped a couple of versions in our existing system.

It's no surprise. The system, developed entirely internally by Microsoft, is a showcase for the options available for .net applications: SQL, IIS, Async, Workflow and the rest. It's a modern architecture and I think it would be fair to say that this is how MS expect applications to be built now. Which means that it also contains a really good joke.

Remember Active Directory? I do, in fact I'm pretty sure it was going to be at the heart of the modern enterprise. What that means is a question for another time, what's clear for now is that Microsoft doesn't believe it any more. Dynamics CRM 4.0 barely touches the AD after the user has authenticated. All the access control, all of the organisational structure is built entirely in the application data structures. Domain groups? We've heard of them!

I asked whether this put the DBAs into an access control role we've tried to limit to the helpdesk. The answer was a peach: the data are very normal, but none the less too complicated to edit by hand. And the DBAs won't have the access anyway...

Goodbye AD. Goodbye ACLs. Goodbye integrated access control. I never really believed, but for a while I did hope.

Insourcing Authentication

It's appraisal time and the focus is on the performance management system. That's outsourced -- Internet delivered and hosted somewhere in Florida.

The issue that was brought to me was concern that users might be saving their performance management password in the Internet Explorer credential cache. It's never something that's worried me very much -- if you lose control of your workstation session, you've lost a lot more than the right to express an opinion on that annoying support guy with the awkward questions....

But it tied up some ideas that have been rather weakly formed in my mind.

We're outsourcing more and more, and the result is that our users do their jobs with accounts on this system and accounts on that, and I have no real confidence that there's even a consistent list. I'm certain that there are some systems a leaver will retain indefinite access to, simply because the whole service was set up by the business with no IT involvement and the helpdesk will never know to cease the account. This is pretty galling when we've recently put so much work into the Joiners/Leavers/Absentees process and the unused account purge. We're actually getting on top of this, but it's slipping away though a side door. There's certainly no hope of enforcing a consistent account name or password complexity policy.

At the same time, to deal with the many sites like Blogger, Delicious and others that I use all the time from loads of PCs, I've been looking at OpenID, a public authentication system, that allows the administrators of an Internet hosted application to securely trust a logon completed at a different site. I've gone so far as to set up an OpenID on the Verisign test site, even though I've nothing to log in to it with.

So I've been toying with the idea that authentication was a service we could outsource -- to Verisign or perhaps a two-factor supplier. In fact, I had that exactly wrong. Authentication is the one service we can always do better than anyone else because no-one can know better than we do, who works for us. This is true even if we don't know very well ourselves....

So we shouldn't outsource -- we should insource. We should provide an OpenID service as part of our infrastructure support for application outsourcing. Then we become the authority on who works for us, and what tests they have to pass to prove it:

• Log on from inside, and you just need a logged-on Windows session; log on from the Internet and it'll ask for your RSA token.
• The helpdesk can cease your OpenID when you leave, so terminating access to services they don't even know exist.
• The authenticator could decline to recognise remote applications completely or on a per user basis.
• Choices about access to the dodgier stuff like the password reset tool, or remote access can all be made here.

So it would all be fabulous. Just a couple of problems:

• There doesn't seem to be OpenID software with the flexibility and convenience I need, and
• The chances that application hosts can be persuaded to recognise their customers' OpenIDs seems close to zero.

So this frankly rather wonderful approach, which ought by rights be standard, is dead. But I think I'll put OpenID support on the qualification form just to watch them squirm.

Triple A

We have Authentication, Authorisation and Accounting. And the least of these is Accounting, because no-one bothers about computer time these days. But its presence in the triad reminds us that username and password authentication dates back to a time when the only reason to log on was to select the account to be billed for your FORTRAN session on the teletype.

Using a password to prove identity is a later loading of this basic idea. Which is why it doesn't work.

Why is X.509 so grim?

I've been intending to assemble some notes about the way I've been using an OpenSSL install to knock off some certification requirements. I was going to start with a round-up of the ways that X.509 was needlessly confusing, redundant and bizarre. And I was going to say that large-scale, public, multi-party PKIs are wrong-headed and dangerous.

There's still room for the OpenSSL cookbook -- I'll do that. For such a long-lived product, the documentation just doesn't say what a typical newbie user will want to know. And there's room for me to come clean (if no-one else will) and say that the worst initial obstacle was that I got confused with OpenSSH!

But the rest has been done a long time ago. I wish I'd found it earlier. It's sufficient to say:

• X.509 PKI solves the wrong problem. It's not you. It really is too hard to get right.
• The semantics of the trust and reliance which X.509 attempts to create between unrelated parties are much more tricky than they look, do not address vital issues like counterparties' management of private keys and do not correspond with the ordinary requirements of law and regulation
• X.509 PKI only makes sense between parties who have a pre-existing legal structure (perhaps they're part of the same organisation), and have a means to deal with cancelling authorisation that does not depend on certificate revocation

Why? Witness Peter Gutman's PKI Introduction. And while you're at it, check out his other stuff too. I found the Encryption and Security Tutorial was particularly helpful.

Desperate for a Wii

(This is my entrant for "most peurile reference to a Nintendo gaming console 2007".)

Now that the less mad son's eagerly desired birthday present has arrived from a reputable supplier (gamestation) I feel that it won't be tempting fate to describe what happens when you try and order from some other suppliers.

About ten days ago, Mrs U was desperately looking for a Wii. It launched months ago -- how could it possibly be in short supply now? The LMS was on a promise but there were none to be found with a fixed delivery date anywhere in the UK. Until she came across a site that magically was promising a five day delivery. Just time! So she shopped, waved her credit card, and waited.

No confirmation email: that's odd. Five days later, no Wii: that's a nightmare. Check the bank account: £2,500 debited by a restaurant in Surrey. Oooh.

Now I'm not naming the site because it's just possible that the cause of the trouble is actually this. But I don't think so.

The point to this sad story is that Mrs U is a competent shopper and competent security consumer. She declines to speak to the bank when they ring her up and ask her to confirm her identity. She knows what the padlock means. But as soon as she was a little bit needy, she was willing to deal with a site she'd never used before, without doing research that could have shown the slagging it got on Yahoo answers, she was willing to ignore the absence of a phone number, and she clicked straight through the warning from the self-signed certificate that was pointing to a "commerce" site hosted the Dear knows where. Education and common sense swept aside by need and "experience" of good shopping outcomes in the past.

It's worse for the restaurant: they've accepted a bad card without a PIN and that'll mean a monster charge back straight off their margin. Grief all round.

Education is supposed to be the key security tool, but it seems to me that the only education that works is to screw up.

That Google Account

Has anyone noticed how useful Google Docs has got lately? Obviously it's not Office 2003, nor Open Office 2, nor even Office 97. But I'm more and more finding it to be the natural home for my reference documents, drafts and other oddments. The collaboration features look interesting, and probably work well for all I know, but for me what counts is the accessibility from any of about half a dozen computers. Content search and tagging isn't a huge deal at the moment, but I know it'll save my bacon when the volume goes up, or when I upload all that stuff I used to keep on my Palm.

The limitations and problems are more and more obviously the consequence of hosting it in HTML. The tables reek (I do a lot of things in tables) but HTML tables do reek. Layout for paper is actually useless -- but I'm blaming the browsers.

And really, I find that there's a large slice of what I do where rough and ready is OK -- almost anything is OK -- if I can rely on getting at it from the computer I'm working on. That plan I'm working on in odd moments can only be a Google spreadsheet. I don't need a fair printable version of my CV, but I do need to be able to keep the copy up to date. And Blogger is a terrible place to hold draft articles like this one.

The security angle ought to be obvious. I set up my Google account so I could customise my searches, or something, and the password was some old joe job. (It isn't UMACF24, but you get the idea). By stages, stealthily, that same rotten password now defends:

• My email, calendar, and the management of my domain (Google Apps for Your Domain)
• A bunch of documents and plans (Google Docs)
• My Blog
• And probably other stuff I've forgotten.

I can change that. I'll have to allocate a "public site -- reputation/convenience" password now -- that's just one stage short of Paypal/banking. But, unfortunately, it's still just a password. And If I want to get the full benefit from Google, I'll have to use it on untrusted, bugged machines.

So, "Hey Google: It's time for a second factor!".

The Userid Con

Activity logs are good. We grant all sorts of access to staff "merely" because they can't do their jobs without it, and trust them not to abuse it. The way Ronald Reagan put this was "trust, but verify," and he was right. Audit logs are our verification. My first security effort here was to replace a shared admin userid with personal IDs, simply to make the logs mean something, and it's probably the most useful single thing I've done.

So, we configure the systems to generate logs, and we squirrel them away safely and the auditors and investigators are profoundly happy. But if we ever want to use them as evidence there's a little con trick we have to carry off first. That trick is called "User equals userID".

It's a con because it's untrue, and we depend on users not knowing it's untrue. Ask yourself, where you work, which has the worst career outcome a) "yes, I sent those emails" or b) "everyone knows I leave my password on a note under my keyboard"? If you're like my employers, admitting password sloppiness is going to go a lot better, especially if you've been doing the sort of thing people get investigated for. I sometimes wonder how many people have lost their jobs or reputation after assuming that logs with their name on were irrefutable evidence, when they could have hung on by saying that someone else was on their account. It must be a lot. I've seen this benign con work in environments where no-one even pretends to have a secret password.

Perhaps it's not totally grim. A single event may be deniable, but a pattern or a sequence of offending behaviours is much harder to walk away from. And a good evidence recovery can cause people to collapse when they are shown exact texts, pictures, times.

We can deal with this:

1. Let's look again at the rules on password sharing in the AUP. And,
2. I think it's time to dust off that plan for smartcard tokens -- they are hard to share accidentally.

But in the meantime, well now, I think we'd better keep this to ourselves. Otherwise, there'll be a password under every keyboard in your firm.

How Security Policies Fail (1)

Policy: Users must choose a new secret complex password every thirty days.

Failure: Users create passwords in sequence, or write them down, or wangle exemptions to the requirement...

This one is robust -- the compliance situation doesn't get any worse as time goes on, and correcting it is relatively simple, but it's not lazy -- it's easier to ignore than to obey.

To make this one work, we would have to

• Crack passwords 24x7 and disable any that didn't reach some bar.
• Patrol the floors destroying dodgy-looking Post-It (tm) notes.
• Report the list of exempt users, and require them to re-certify their exemption every week.

That would give an incentive to pick gooduns and keep them secret. Of course, we would piss off the 50% of users -- some bright, some not -- for whom picking and remembering a good password is totally alien. So while it's enforceable, it's still a bad policy.