Tuesday, May 24, 2005

Project Honeynet reveals how phishing attacks are carried out

CircleID reports on how project Honeynet has revealed how phishers build and use their infrastructure to carry out phishing attacks. Here is the paper: Know your enemy that details the complete study.

Here is one of my earlier entries describing what Phishing is.

Saturday, May 21, 2005

See I.D.

While standing at the checkout lane this afternoon, I noticed that the cashier refused to accept the credit card from the guy who was standing ahead of me. He had not signed the back of his credit card yet. Instead he has written "See I.D." on the little white stripey thingy on the back of the card. The intention being, I presume, that the cashier/checkout guy would ask for an ID and as the ID contains both the photo and signature it makes the whole process more secure. Right? Wrong.

He asked the cashier why she was refusing to take the card. He said that the ID (drivers licence in this case) contained the signature also and the cashier could verify his signature on the receipt with the one on the drivers licence. She said that if the card is signed and if that guy refutes the transaction then it Visa/Mastercard/ or whoever issued the card has to pay-up. But if the card is not signed and if she relies on the ID then the liability shifts onto the them.

Look guys, I am no lawyer... but is this true? I know people who write "See ID" on the back of their cards and get away with it (atleast so far). Did she BS him or is that a factual thing?

Wednesday, May 18, 2005

How to crack WiFi networks that use WEP

Check out a two part article on Tom's networking that gives a detailed how-to on breaking WEP keys - Part-I and Part-II. These articles dont just talk fluff, they lead you through the steps needed to break the WEP keys. It took them less then 5 minutes to break a 64 bit WEP key which includes the time to scan using airodump and cracking with aircrack and simulating traffic.

At an ISSA (Information Systems Security Association) meeting in Los Angeles, a team of FBI agents demonstrated current WEP-cracking techniques and broke a 128 bit WEP key in about three minutes. So even the 128 bit key is not safe enough.

Here is what The Feds suggested to protect your WiFi network:
You should use either WPA (WiFi Protected Access) or WPA-2 (with a strong password) or turning off wireless altogether until you can.

Securing Web-application state stored on the client-side

In a typical J2EE application there are various ways of of storing session state which include client-side cookies, the HttpSession object, database, an EJB, or even the POJO. Another place you can store the application state, in an encrypted form, is in the HTML page itself. Interesting read. Check it out here and here.

According to the article these are the pros and the cons of storing the state in the HTML itself:
Storing state on the client has the following benefits:

* Scalability - A single server can support more clients. An increase in clients does not require more memory or database resources on the server.
* Back Button is not a Problem - All state is saved in the page making the back button no longer an issue. What you see in the HTML page is the Java object used to generate that page.
* Session Time-Outs not an Issue - HttpSession time outs are not a problem.

Saving state on the client does not come for free. Here are some of the drawbacks:

* Computing Resources - There is a CPU cost associated with encoding/decoding and encrypting/decrypting of state for each interaction.
* Bandwidth - Since all the state related to a page is sent back to the server on each request there will be more data sent.
* Navigation must be from a form - The state is kept as HTML form hidden variables requiring page to page navigation to be from a form though links could use JavaScript to performs a form submits.
* Browser Crashes - If the browser that contains the state crashes the state is lost.

Tuesday, May 17, 2005

Why is data on laptops not encrypted

So laptops get stolen all the time. Some are stolen from cars, some from apartments/homes etc. With the laptop storage increasing, we tend to store all kinds of stuff on it. If the laptop is gone so is all the data that resides on it. Why isnt the data on a laptop stored in an encrypted state, so that even if the laptop is stolen, the thief, or who ever bought it from the thief, has no way to retrieve the data? Yes, you have to enter you login/password when the laptop boots up but that can be bypassed with some booting up tricks (this is used by specialists who retrieve data from crashed hard-disks).

Encryption on laptops should be done by the O/S itself. Although the Windows O/S gives you an option to encrypt files and folders, it doesnt let you encrypt the entire hard disk. I am not sure about the other operating systems like Linux/Solaris. Let me know if they provide encryption capabilities across the board for all the data on your hard-drive on a laptop or even on the desktop.

Update: On my flight to San Francisco, I came across an article in the in-flight magazine which said "4425 number of laptops left in the cabs of one taxi in chicago in 6 consecutive months in 2004 - according to a survey of taxi drivers by security firm Pointsec. 21460 handheld computers and 85619 mobile phones get left behind." As we store more and more data on our mobile devices we need a way protect it even more.

Monday, May 16, 2005

How to request a server SSL certificate

Lets say you need to order a server side SSL certificate from Verisign or Thwate or some other Certification Authority (CA). Here is how you can use Java's in-built keytool to create a CSR, request a certificate and then import it in the keystore database.:

Create your key. Always use the full state name, no abbreviations. CN (Common name) should be domain of your site. This will also create a keystore if it doesnt already exist.
keytool -v -genkey -keyalg RSA -keystore keystore -dname "cn=www.mysite.com, ou=None, L=Redmond, ST=Washington, o=MyCompany, c=US"

Now generate the Certificate Signing Request known as a CSR. This process should create a file called "www.mysite.com.csr" in your current directory.
keytool -certreq -sigalg MD5withRSA -file www.mysite.com.csr -keystore keystore -storepass password
Go to Verisign's (or any CA's) site and submit the CSR file. There are two kinds of certificates that you can order. Either the 40-bit or the 128-bit. If you anticipate people outside of the US coming to your site (and using SSL, obviously) then you should go for a 40-bit certificate. If this is needed for a machine-to-machine or for a US only site, then you can go for a 128-bit certificate. 128-bit encryption offers 288 times as many possible combinations as 40-bit encryption. That is over a trillion times a trillion times stronger. But not all the browsers world-wide have the capability to decrypt 128 bit encrypted stuff (because of US export regulations) and so you might have to settle with the 40-bit certificate.

Once Verisign is done with their verification process they will sign and issue you a certificate. They might email it to you. Some CA's like Thwate provide the facility of login/password and ask you to download the certificate.

Once you save the certificate file locally lets say as "www.mysite.com.cert", you will need to import it into your keystore.
keytool -import -keystore keystore -keyalg RSA -import -trustcacerts -file www.mysite.com.cert

A server side certificate contains the name of the site/domain it is intended for and cannot be shared across domains. It is valid only for a particular domain, unlike client side SSL certificates which can be shared.

You can follow this link on keytool, if you need more information about using it.

Tuesday, May 10, 2005

Password generator for a simple Single Sign-on solution

Per my previous rant about how yucky passwords are, here is something that shows how to have a unique password for every site/service that you have signed up for without remembering it like Shakuntala Devi or writing it down on a post-it under your keyboard.

The concept is simple, but brilliant and effective. You create a personal master password. I recommend creating it with all the standard tricks ~ alphanumeric, minimum length 10 chars and includes a special character or two. This password is then mashed up with the name of the site that you are visiting to create a unique MD5 hash that can be used as a password for that site. Now each time the hashed up key would be different, giving you the ability to create a unique password for each site without having to remember it.

A password generator Greasemonkey script simplifies life even further. Greasemonkey is a Firefox extension which lets you to add bits of DHTML ("user scripts") to any web page to change its behavior. Check out Jon Udell's 2.75 minute screencast demonstrating how easy it is to use this concept. You just have to remember a single personal master password giving you a kind of Single Sign-on effect.

This solution works best in Firefox with Greasemonkey installed, though it is not needed (check Nic's website below). It even works with IE and Safari.

Nick Wolff's Password generator
Johannes la Poutré's Password composer
Jon Udell's entry talking about the single sign-on solution

Monday, May 09, 2005

Identity Theft

While waiting at the DMV for my wife's written test to complete, I picked up one of the leaflets they had put in there along with a bunch of other stuff. The leaflet was about how to avoid Identity theft and what to do incase you became a victim of identity theft. Here is what it stated:

How to avoid becoming an Identity Theft victim:
What to do if you become a victim of Identity theft:
It is scary to have your identity stolen. Hopefully, with the above precautions you should never have to face this scenario.

Saturday, May 07, 2005

Passwords are passe

So when was the last time you changed your password? Maybe the company you work for requires you to change your work password every 60 or 90 days or something like that. They might have stricter rules about not reusing any of the previous 5-6 passwords or how they have to be alpha numeric with a special character blah blah.

But how about your personal passwords? Lets say your hotmail password. Did you *ever* change it since you created it? I have only changed my hotmail password once since I created my account in 1998. Thats not just me, that is a typical user behavior. There are a gazillion issues with passwords and managing them. Here are a few:
Its time the password became passe. We could use biometrics to start with. How about fingerprints?

Computer manufacturers need to ship keyboards and/or mice with inbuilt fingerprint scanners. Browsers like IE and Firefox should be able to scan your index finger and send it to a website whenever it asks for you to sign-up or sign-in. Ofcourse the whole process of sending across fingerprints should be encrypted end-to-end. Mobile phones need to be equipped with fingerprint scanners as well, that let you sign-in into your email account.

The password issue is going to become messier as we move ahead with putting stuff like videos, photos, blogs, music on the network. The network could be a home network or something like a file store online. Everything needs a password these days: phones, wireless routers, voicemail accounts, websites, TV's etc. Our reliance on digital stuff is increasing. We need to rely on the digit (aka finger ~ pun intended) to make the digitization of our lives simpler.

Thursday, May 05, 2005

Mitigating a DOS attack

A few days ago, I had written about what a DOS attack is. DOS attacks are usually targetted towards ISPs or websites of large corporations. Home users might get affected by a DOS attack, such that if their ISP is attacked then they might face connectivity issues. As a home user, you dont have too many options. But as a sys-admin incharge of a large corporation's website or if you are working for an ISP, you might be wondering what your options are.

So what can be done when a DOS attack occurs? Can it be stopped or its effect mitigated? Well, lets look at a few options:
These are just the preliminary starting points. Preventing a DOS or a DDOS attack is a huge topic in itself. In a future post, I'll describe the various types of DOS attacks like smurf, fraggle etc.

Sunday, May 01, 2005

SSL - a false sense of security

SSL is used to encrypt transmission of data between a browser and a webserver. So if a website out there uses SSL to encrypt sensitive information then everything is secure and perfect and nobody needs to worry about anything. Right? Well no.

SSL works only at the transport layer. Let me explain. What SSL can do is protect data exchanged between a browser and a server. What it cannot do is protect the server which stores the data from other kinds of attacks.

The data inside the server's database is NOT protected by SSL. It lies there in plain text unless the server uses some sort of encryption while storing data inside the database. SSL does not protect against operating system vulnerabilities. If someone out there can exploit a known vulnerability about the operating system, then the server and potentially the data might be exposed.

It is difficult to track down what was sent in as data via SSL (because everything is encrypted) and infact hackers prefer SSL to exploit application level vulnerabilities. Often hackers use a combination of outbound proxy servers and SSL so that their activities cannot be traced back to their computer.

This page is powered by Blogger. Isn't yours?

Copyright Anand Jain 2004, 2005. All rights reserved.