Sunday 28 September 2008

Authentication tokens


Devices like hashing fobs or tamper-proof smart cards are technically the best solutions for secure authentication - but they have a number of drawbacks for proactical applications. By far the biggest one is that they are not universal - I can't use my Paypal fob to log onto my LAN, I have several smart cards in my wallet, but where do I get a reader? Even if I did, how would I get Google to support the use of the card for accessing my gmail account?


Instead we seem doomed to endure badly implemented wish-it-was-2-factor-authentication and Capchas which even those of us lucky enough not to be visually impaired, cannot read.


While kitten capchas are undoubtedly cute, do they really help solve the problem?


It occurred to me that not entering the same password more than once is a good way to avoid the risk of compromise (essentially this is the common factor in Capchas, smart cards and key fobs) and here is a simple way to achieve this:


When you create an account for your user, issue them with a grid of letters and digits, 6x6 seems about right.

























ABCDEF
1sar3cv
28teyp4
3qighwk
4fmzbi9
57djanp
6geu59w


Then, each time they log in, ask for, say 5 of the entries, the grid holds more than 8000 passwords.


Given say 32 possible keys (omitting the letter O and number 0, lower case L and digit 1) the chance of guessing the password are one in 33 million.


Someone's probably already thought of this. But I thought I'd write it down before it gets patented.

Monday 1 September 2008

Microsoft backdoor optimization?

I recently replied to a post on uk.comp.os.linux regarding squid - but on reflection, if the details supplied by the OP are correct, then this exposes some backdoor optimization by Microsoft in IIS

The post and replay are here.

Tim said that:

tim@feynman:~$ telnet www.plumbcenter.co.uk 80
Trying 89.207.160.30...
Connected to www.plumbcenter.co.uk.
Escape character is '^]'.
GET /plumb/index.html HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

HTTP/1.1 400 Bad Request
Date: Wed, 27 Aug 2008 21:44:51 GMT
Server: Microsoft-IIS/6.0
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
(404 body snipped)

Connection closed by foreign host.

This works if you drop the "; SV1" from the user agent. Or even replace
"; SV1" with "; SV2" or replace "5.1" with "5.0" but leave the "; SV1"
bit!

What's interesting here is that the request headers specify HTTP/1.0 but the response comes back from the server as HTTP/1.1

While maybe this is just sloppy programming by Microsoft, its worth bearing in mind that, by default MSIE degrades to HTTP/1.0 responses when it knows it's talking via a proxy. Also, HTTP/1.1 mainly addresses performance improvements.

Further - as Tim points out, the behaviour of the server changes when the user-agent changes.

Could it be that IIS is using the user-agent for purposes beyond what it should do according to spec? This could give Microsoft an unfair performance advantage over other browsers. Certainly in this case there is hard evidencethat the server is basing its response on the user-agent supplied in the request.

For the time being this is mostly conjecture and conspiracy theory. But it would be interesting to confirm whether IIS always responds to HTTP/1.0 requests with a HTTP/1.1 response, whether it will include HTTP/1.1 specific browser instructions - and to see if the browser then acts on these.