Month: June 2004

The sheer volume of security problems with Internet Explorer has
prompted TurboTas to consider a new strategy for protecting businesses.
It’s simply to install two browsers. Bear with me because it’s not as
daft as it sounds. I began this train when I read yet another
vulnerability with IE. The otherwise respectable security website
provided as a fix ‘Change Browser’.It may have been flippant, it may have smart, but it’s not helpful.
Now, I have to say that I don’t actually like IE. I only use it when I
have no choice like on a machine that’s not mine or where policy
dictates I must use it. That having been said, there are some important
points to make about it.

IE’s main problem stem from the high level of integration that it
has with other of Microsoft core components. Firstly, it ties in very
closely with the OS. Secondly, it uses some poorly secured technologies
like ActiveX and Active scripting.

And herein lies the rub: Businesses do like IE because
it lets them deliver rich applications to their employees in a
controlled environment: they make use of these enabling technologies.
Application development time is reduced as the app vendors can write
big chunks of code that live on the users PC: Kind of like treating the
Browser as the delivery vessel for the App rather than the container
the App runs in.

All this makes it really hard for a business to stop using IE. Things like Oracle eBusiness suite would stop working.

The fix becomes obvious: Use IE for internal websites and use Mozilla or better still Firefox for Internet traffic.

The stunningly obvious step here is to remove the choice
from the user: make sure that technical controls separate the two:
Firefox is unable to contact internal sites and IE is unable to contact
external ones.

Firefox is doing you a great favour here: It runs on enough
platforms that it can’t afford to be inextricably linked to the OS. It
displays HTML and runs Plugins. Period.

Don’t let’s get carried away here: Firefox still has bugs. It’s
also build to encounter security problems. Nevertheless, it’s a sight
better than surfing the net with IE: You take your PC’s life in your
hands at the moment.

Firefox has unexpected advantages to. The most noticeable is
speed: It loads fast. It has ‘tabbed’ browsing, and best of all if you,
like TurboTas run multiple OS’, you et the same browser look and feel
on all the OS’s you care to use.

TurboTas 04

TurboTas often looks longingly at those secure athenticators from the
likes of RSA or PassGo and thinks that they would massivly enhance
security for online transactions. The expenseof the authenticators puts
them way out of reach for off-the-shelf use though – typically the low
end devices start at £50.
As if that were not off-putting enough, the back end libraries are
proprietary, expensive and don’t necessarily interface very well with
backend systems.

It occurred to TurboTas in the present climate of Open Hardware
design, an open authenticator would not be that hard to design and
produce. More importantly, not that expensive to produce in volumes
either.

The logic goes that if the hardware specs and more importantly
the algorithms were public, then implementation could be left to
individual systems designers/programmers. Application programmers could
write their own code.

Let’s take as an example a hardware authenticator without a PIN
number. The device just cycles through a 6 digit nuber every minute or
so or on response to a button press on the outside of the authenticator

Okay, clearly I’m just making this up as I go along here….

The Authenticator has a reasonably accurate clock (This is
pretty fundamental!). Accurate clocks are not hard these days. Accuracy
to within 15 seconds over the expected 4 year battery life would be
fine.

The authenticator has an internal Identification number (Lets
say 6 bytes for now) and an externally visible serial number. The
numbers are unrelated but at supply time, the internal number and external number are listed

In software, the device runs a very simple (!) process every
minute: It takes the present date and time (dumping the seconds),
appends the internal serial number and produces a one-way hash. This
hash is then reduced using some algorithm to a user friendly 6 digit
number which is in turn displayed to the screen. Something like
28/06/2004 14:23:21 A56FB3A8C0
>2806200403A56FB3A8C0
>23AB76B5A69AD5E8C01BA9D4
>673633

This is passed to the server along with regular credentials in
whatever form are required by the application. At the server end, the
process is repeated (perhaps for 3 timeslices to allow for user
delays/timeslip) and the server can reproduce the 6 digit number that
the authenticatr displayed. Simple check against that provided and
bingo….

The key here is that it is left up to the systemdesigner to
decide how much security is needed: The designer may siply run all the
checks against all the registers tokens and allow the user in if there
is a match (or work out who they are the same way).

Perhaps a 4 digit pin appended to the authenticator number
would give single field signon: 6736331234. Allt hings are possible
once the standard is open.

Addendum: It _may_ be possible to brute the time against serial
numbers, particularly a known ciphertext attack where the time can be
worked out and the auth number is sniffed. To counter this there are
two techniques which occur.

Firstly, authenticator serial numbers should be assigned is a pseudo random fashion at construction time.

Secondly, to mitigate known time attacks it may be pudent to
ship the units in an unpowered state. Time that the unit is activated
would be recorded and the unit internally uses a count from zero timer.
This adds a further stage of lookup on the server (The process has to
have available the time the authenticator was powered).

To give system or organizational security, it may be possible
to set an internal secret string in all tokens which is also used at
Hash calc time.

Althoughy by no means perfect, this approach at least has the
benefit of being open and extensible. The key security tennet is that
it’s hard (Hopefully)( to reduce a hash back to the numbers used to
generate it).

Authentication processes – of course – must take the burden of lockout etc, but the scope is better

Users could purchase their own token and supply relevant credentials to application providers (Serial number, Activation Time)

Further development could see token with 4 buttons: Each button uses a different key.

I Think it’s pretty smart…

Relevant hashing algorithms are: MD5 and SHA although less computationally intnsive ones could be used if necessary.

A second hashing function is needed to reduce the 160 bits down to 6 decimal digits

TurboTas 2004