Sunday, November 13, 2005

How secure is your password against RainbowCrack Online?

We all know that password is not very secure, but we always tell ourselves that it's still ok if we would choose strong password. The fundamental assumption to password security is that passwords stored and authenticated as hashs won't be easily recovered back to plain text. This assumption is guaranteed by the one-way property of hash algorithms.

While when you read in depth about the hash algorithms, there is one "clause" remarking that hash algorithms are attackable by using a Rainbow Table, which is a huge table of hashs correspoding to all possible plain text. Of course you will be told that this is impractical because it will took too much resources. So it seems passwords are still in a pretty safe situation.

But now you need to think twice about it. There are such people that are willing to put in the "impractical" resources, and they managed to compile a 500GB Rainbow Table. What makes it worse is that these group of people put it online as a subscription based service. (http://www.rainbowcrack-online.com/)

So you can use whatever means to get the password hashs (there are thousands hacking methods to do so), submit it to this online service, wait for a while and you will get the plain text password! With the traditional brute force cracking methods, it will take you "forever" to crack a password like "$FT%_3^," . But according to the news report, with this Rainbow Table, it's just about looking up a huge table. It will take much much less time compare to "forever".

We know that perfectly protecting password hashs is impossible. We used to think that thanks to password hash bad guys can do nothing better than brute force or dictionary cracking. But now with this ready rainbow table , how much good can the hash do?

And the bigger question is, "whether passwords are still secure?"


(News link: http://www.theregister.co.uk/2005/11/10/password_hashes/)

Monday, September 12, 2005

Althought this is not a recent news, but it is an excellent example about the rule of "weakest link" in the practical security world.

How difficult to open a electronic lock using 128-bit encryption? Merely putting a strong magnet near the lock will do. It will pull a pin inside the lock, which mechanically block the lock from opening.

http://www.schneier.com/blog/archives/2005/03/flaw_in_winkhau.html

Further more, it's a ironical coincidence to my post about "128-bit encryption inside" days ago.

Friday, September 09, 2005

Admit or not, all systems will have failures, those happened or those still are hidden. There is no exception for security system. Being a complex system, there are too many links involved in, from algorithms to implementation. Failures are just buried here and there in these links, and any such failure can be the weakest link of the whole system.

Ok, failure is something we have to live with. But how to minimize the catastrophic effects created by these failures?

I would think that the emerging design philosophy, Designing for Failure, might be one solution.

The way we are used to in software development is designing to Work, which is focusing on how to get things done and trying to minimize the errors along the way. This traditional way is deeply implanted in our mind. We always tend to think in one track, the track that the softwares suppose to work. How about the side tracks? Just pop up a error message box? Or throw an exception? Anything better than a Blue Screen can be considered as appropriate. Anyway in this philosophy failures are not expected, and if they do happen, too bad.

But in the security world, things are very different. Security systems are dealing with serious problems, so serious that anything must be handled. If you don't handle the failures, the adversaries will gain and you will have loss.

So in the paradigm of Designing for Failure, we must first pessimisticly evaluate all the possible failures. We have to admit the chances that such failures might be there, even when we are very confident on our design and implementation. Then we need to answer the question, "if this failure happened, what should the system to react?" We should design the capability of identifying failures and responding to failures into the security system. With such capabilities designed in, at least we should know that something bad happened. It will be even better if we can respond to the bad things to minimize the damage.

To use an analogy, you should put cushion barriers here and there when you design a F1 racing track. The more you put, the more possible you will save a life.

Wednesday, September 07, 2005

On our computers, we always see "Intel Inside" logo, which used to be a sign of quality and does not mean alot nowadays.

Similarly, it will never be rare for us to see see statements about security products like "128-bit encryption inside (so it is unbreakable)" in the security world. This is actually an interesting phenomenon, and in most of cases it should raise our alertness on the products marked such. It's rather a sign of warning than a sign of "quality".

Algorithms, protocols, architecture, implementation and procedures. A security system has to be a whole with these elements. Any failure of these elements can be fatal to the whole system. As any other practical systems, the rule of "weakest link" can always be applied to the security system.

But in reality, as other complex systems, security system is always too complicated to be understood. Due to whatever reasons, some may be historical, poeple always tend to put their focus on Cryptography Algorithms. The picture of whole security system becomes fuzzy, and Cryptography Algorithms start representing everything.

-"Tell me about your security system."
-"It's 1024-bit RSA and 128-bit 3DES."

Unfortunately, if there is any weaker links in elements other than the algoritms, the whole security system is still as weak as the weakest link. 1024-bit RSA is good, but what if you use the same private key for both encryption and signing? 128-bit 3DES is good, but what if you store the plaintext key just besides the encrypted data?

According to my personal observation, vendors of quite some "xxx-bit encryption inside" products do not bother to think about other critical elements such as protocols. This observation is also linked with the nature of marketing hype. Modern marketing strategy is always to hype the "strongest link". If the vendor have an advanced mindset and think more on systematic security, they would rather to make statements like "Audited by xxx" or "FIPS 140-x/Level x Validated".

It's luckly for us that most smart card modules, which will be used on credit cards and eventually e-passports, are marked as "FIPS 140-2/Level 3 Validated" but not merely "ECC inside".

Tuesday, September 06, 2005

Nobody will doubt that it will be good to use Cryptosystem implemented in a right way, which means appropriate algorithm, enough key length, proper key management, well-designed protocols and etc.

Then how about using Cryptosystem implemented in a wrong way? Reduced key length, careless key management or poorly-designed protocols? Some people will say, "at least they are better than nothing, right?"

But I would say, "they are worse than nothing!" If people know that there are no encryption protecting their information, at least they will very caution on the information leakage as per the good old way. So very little information will be leaked out.

While as long as people start knowing that there is some encryption in place, no matter implemented in the right or wrong way, people will relax and assume information will be secured in any condition. So poorly encrypted information will be leaked out without setting people's alarms, and such encryption can barely be a challenge to adversaries.

Now people are smart enough and will not send their credit card number as plaintext in email. But there are some people, more than you can imagine, comfortably email highly confidential information using "PKZIP encryption" with 123456 as password. Guess how long will it take Eve to bruteforce the password?

In a word, the most dangerous thing is the false secruity brought by poorly implemented Crypto. It is NOT better than nothing. It is worse than nothing.

Monday, September 05, 2005

Once upon a time, Cryptography was more or less like a gimmick. Nowadays, nobody will doubt the seriousness of Cryptography as the cornerstone of digital security. This evolution was a long way, not only about the long history but also about the paradigm shift.

Cryptography's biggest change from gimmick to cornerstone is the formalizing of methodologies. In the early days of Cryptography, way back to Caesar's time, it was about bright ideas. There were many bright ideas of transforming text into some obscure forms, and they looked secure. At that time, people just tended to believe that such ideas were secure, because the transformed text appeared impossible to be understood.

While with the extensive use of Cryptography, especially since WWII, "believe to be secure" was no longer acceptable. In order to make sure that the critical information was safely transmitted, scientists started using Maths as the tools to design and analyze Cryptography. Since then Cryptography was not gimmick any more, it became a Science.

But the story is not over. For quite some years, although Cryptography itself was formalized, the methods of using Encryption were like gimmicks. People created so many "creative" ways to use Cryptography, most of the time despite some scientific natures of Cryptography. As a consequence, many of such systems failed.

In order to prevent our digital security from failure, people started applying Formal Methods, which were maturely used in Software Engineering, to the design of Cryptography system. Althought it's an ongoing effort, at least we can see the light of a promising future of security system as a whole.

While look at the physical security industry, the good old industry I am familiar with, although there are blooming of new technologies, it seems some of them are still in Caesar's time.