Gollum, the Wikipedia Browser

Ajax powered browser for wikipedia.

read more | digg story


Need to decipher .mil speak?

Here's a handy site from the same folks who brought your acronymfinder.com

read more | digg story

Good bit about RSA SecurID tokens

I found this on: http://www.sans.org/newsletters/newsbites/vol3_3.php?printer=Y

Ask The Editors: Is SecurID Safe?
William Hugh Murray, Executive Consultant to Deloitte & Touche
Let me get my biases on the table. First, I subscribe to Courtney's
First Law: "Nothing useful can be said about the security of a
mechanism except in the context of a specific application and
environment." Everything that I say here must be taken in the context
of that disclaimer.
Second, for more than a decade I have been a strong advocate for strong
authentication*. Security Dynamics/RSA Security has a significant share
of the market for strong authentication. They have always advocated
what they have called "two factor" authentication, i.e., that the
SecurID token be used only in the context of a second form of evidence,
usually a shared secret.
Third, for the last five or six years I have advocated client-side
authentication, i.e., the evidence of strong authentication be
reconciled on the client and only a nonce be passed to the server.
Fourth, Ken Weiss, the founder of Security Dynamics, and Chuck Stuckey,
Chairman of the Board of RSA Security are friends of more than a decade.
- From time to time over the last decade one or the other has engaged me
for small consulting engagements, one of which involved the SecurID Soft
Token. In my consulting practice I often recommend strong
authentication and have, on some engagements, recommended solutions that
included SecurID.
By modern standards SecurID is mature, not to say old, technology. It
was developed in a different era for a different environment. For
example, it was developed for use over a point-to-point connection and
to be reconciled by a closed system. It is now used over broadcast
networks and reconciled by a separate server. While it has served us
very well, it is timely and useful to re-examine it. Such
re-examination is prompted in part by a recent publication of the source
code for a functional equivalent of the algorithm and by a talk about
a man-in-the-middle attack.
For those of you not familiar with SecurID, it is a small
tamper-resistant token with a clock, a hash function, a 64 bit identity
vector, and a display. Periodically the 64 bit identity and the time
are put through the hash and the result is displayed. The number in
the display is used to demonstrate to a distant process that one
possesses the token. Since each token has a unique identity, it
displays a unique number each minute. If the distant system has the
algorithm, the same time, and the identity vector, it knows what number
the token is displaying. By sending the current number, the user
demonstrates that he possesses the token.
Depending upon the model of the token, the number displayed may be 6 or
8 digits in length. The former is the easiest to use while the latter
is more difficult to guess. With six digits one has a one in a million
(10^-6) chance of choosing the number at random while with eight it is
one in a hundred million chance. Since the number changes once a minute
one does not have much time to find the right number. Notice that this
number, as large as it is, is much smaller than the input. (2^64 is
larger than 10^8; take my word for this.) The hash is a compression of
the input. It is not possible to go from the hash back to the time and
the identity any more than one could go from a 128 bit hash of a 10K
file back to the file. Neither is it possible to go from the time and
the display back to the identity.
This leaves the question of whether or not it might be possible to go
from many hashes and the corresponding times back to the identity or
how many such hashes one might have to use in order to do it. The
number is far more than the total amount of information that the token
will put out in millennia, much less in its short life. By the time
you have enough data to derive the identity, we are all long dead.
So, not only does the system not depend upon the secrecy of the hash
algorithm it does not even depend much upon the algorithm used. While
it must be a good hash, the real strength of the system is in how much
information about the identity is lost in generating the output.
However to say that the algorithm, the time, and all the numbers that
the token will display in many times its life is not enough information
to predict what it will say at any point in the future, is not to say
that it is safe. It is only to say that an attack against the token
numbers is not the way to go.
How about an attack against the token itself? The engineers tell me
that the token is tamper-resistant, i.e., it is so constructed that any
attempt to breech the token to get at the identity is more likely to
destroy it. I have no more evidence to support the engineers than their
testimony. On the other hand, I do not have any evidence against them.
But it does not make any difference. It is sufficient for the token to
be tamper-evident. In order for it to be useful to me to get the
identity vector, I must do it without leaving evidence that I have done
so. If I leave evidence that I have done so, then the legitimate owner
will simply replace it.
How about an attack against the network? We have already noted that
the whole purpose of the system is to ensure that replays will not work.
What one might do is wait until the user has logged on and steal the
session. While we have no reports of this, we know that in a
packet-switched network it is at least theoretically possible. This is
really not an attack against a vulnerability of SecurID so much as
against a vulnerability of the network. Given the network in which
session stealing will work, it will work regardless of the
authentication mechanism used. We also know the defense against session
stealing: end-to-end encryption. The man-in-the-middle must be denied
sufficient information to steal the session. We know how to do that.
[Historically there was a race attack in which the attacker stole the
whole number and used it before the owner. The owner would get a
failure and would simply re-authenticate. Often this attack failed;
however, often it worked. The defense is for the server to wait before
acknowledging a success until it knows that no second attempt to use
the number occurs. If the number is received twice it fails both. This
adds security at the expense of latency.]
That leaves an attack against the server. An attack against the server
is more likely to be successful and less likely to leave evidence than
one against the token. In practice, most administrators save the
original seed identifiers on the shipping media as backup. This is
another point of attack. In other words the whole system is no more
secure than the server and its backup. A successful attack against the
network, while easier to defend against, might work against a lot of
While Courtney's law tells me that I cannot tell you whether SecurID is
safe, what I can tell you is that neither the numbers nor the token are
the weak points in the system. The weak points are the network, the
server, and the people.
In order to strengthen both the network and the server we should move
to client-side reconciliation and end-to-end encryption. But that is
a story for another day.
* Strong Authentication uses at least two kinds of evidence, at least
one of which is resistant to replay.

Free Cisco CCNP classes in flash!

This is a really good set of free CCNP tutorials done in flash.

read more | digg story


RFDump: Hacking RFID!

Also has a link to a great RFID slideshow from last year's Blackhat conference.

read more | digg story


Haskell: A purely functional programming language.

A free, easy, natural programming language

read more | digg story


An Huge List of Free Proxy Bypassers

The majority of the users are people trying to bypass their school or business's filters. Also used to surf the web anonymously.

read more | digg story

NOR: Nuby On Rails

Lots of good Ruby on Rails info.

read more | digg story


Root this box!

Go on and try! Ever wonder if these things are setup by _them_?

read more | digg story

Nice little programmers cheat sheet!

Handy little ascii chart and calculator.

read more | digg story


The most dangerous man alive!

A little harsh; but he makes some points.
(ps yeah it's a little dated, consider it a quick flashback, but it's as relevant today)

read more | digg story


Hacking BIOS Passwords!

Good article on the many ways of getting past BIOS passwords.

read more | digg story


This is an awesome gear review site for anyone who uses the big room much.

Many solid reviews of all sorts of out doors gear. It's the most thorough review contribution site I've seen yet.

read more | digg story


High speed, easy password cracking!

These guys deliever a massive table of hashes with corresponding passwords. They're planning on selling it; but I'm sure it'll be availble on torrent in no time.

read more | digg story


Leo Laporte quits World of Warcraft!!

He mentioned it on the recent TWiT podcast. It got me wondering how many other people have _HAD_ to do this because it was chewing up way to much of their real life. PS: link goes to story about Blizzard opening new Asian regions.

read more | digg story


Make your own alcohol; cheap, easy and safe.

This is a great variation on the plastic bucket still. Make four litres of cheap, clean, 40-55% alcohol hooch in under a week. Party on.

read more | digg story