Needless to say, its a pathetic experience as long as security is concerned. I could set my password during shopping (one would expect logging into a bank or CC account on the bank site for such stuff) with very little information provided for my identification.

My wife has an add on card. She had no idea I had kept any password, and was able to reset and override my password while she was shopping. What a waste!

And around August, these stupid, stupid norms of SecureCode and VBV were mandated for all online payments in India, instead of asking the companies to build something secure rather than just building a database and calling it “securiteeee!”

Fortunately, I don’t have to rant much more. Ross Anderson has published an awesome research paper on this mess that pretty much covers most if not all aspects of this pile of stink. Hope this will someday be read by RBI here in India

Your blog, like your email or your Facebook profile, is your online identity. Yes, that’s why we have an authentication system, but sending plaintext passwords to the server isn’t a great default setting. Well, going for a security certificate for something as basic as a blog will be too farfetched, but the nice CHAP protocol is good enough for all our secure login needs. And it is available as a WordPress plugin thanks to redsend.org. Yay!

So there you go. Not a single line of code written, and your wordpress login is secure, even when you go wireless. That wasn’t so hard!

The other security feature that we need is protection from comment spam. This is a more commonly known problem, as you can “see” your blog being misused, unlike in the situation explained above. There are a hell lot of spam protection plugins available. You can either go for a strong Captcha system like MyCaptcha, or prefer to go easy on people kind enough to comment on your post and filter out spam automatically, using Akismet or Defensio. I prefer the latter method and it has been pretty accurate till now.

That’s it. Your wordpress installation is secure from all the bad guys. Well, most of ‘em, anyway. There’s nothing like investing five more minutes after the five-minute install for a bit of security. Blog safe!

At first, a little introduction to the havoc wreaked by WebAccelerator: It sits with your browser, and “clicks” links intelligently on the page you have visited. This ensures that your next click opens the new page instantly. However, “intelligent” behavior started to trouble web applications where links happened to update/delete records in Admin Consoles.

Although the bigger question raised was regarding privacy concerns (Google indexes pages prefetched by WebAccelerator, which includes pages unreachable by its crawlers), lets keep that out for a moment and revisit the issues faced by web developers. As Web Accelerator is no longer active, you may wonder why we need to recap history. The reason is, you never know what plugin the users of your app have installed on their browsers. Yesterday, it was Google. Tomorrow, it may be something smaller, having auto-installed with another package, and no one will have an idea that your pages are being prefetched.

As always, information websites with links sprinkled around do not need to bother about prefetch. Its the websites with user authentication required that mostly fell prey to this activity.

I’ve not tried GWA, and there are comments stating that GWA doesn’t do a lot of things which have been alleged. However, our work here is not to discuss merits of Web Accelerators and their conformance to standards. All we want to do is strengthen our own website. So lets take a look at some problems faced, and graceful solutions or workarounds opined.

1. “Logout” link prefetched once the user logged in: This threw the user out before he did any other activity. Quite irritating. The “Best Practices” supporters came out in strong defense of Google here. Why would developers keep Logout as a link (GET) and not a POST, they asked. Except that Logout is really an idempotent operation! A user can logout once or ten times, and it is always the same result, in almost all cases. Our little tweak to the Best Practices helps in deciding that POST is better for Logout.

A safer deal is to have form method as GET when the application state does not change at all

2. “Delete” links prefetched in Admin consoles: Well, this is pretty straightforward. You cannot have “Delete” as a GET operation. But here’s where we get out of utopia. In the real world, navigation and look and feel of the application is largely decided by the UI team, and the developer has little say in the matter. If the designers feel that links alongside 10 items feel “cool” and buttons don’t, well, you need to keep a link. The workaround here is to have a href = "#" and code a form submit on the onclick event of the link.

3. Links which involved heavy database operations: …and thus increased server load were prefetched. A way out here is to limit the number of “heavy” operations performed by a user per minute. This seems like a fair balance between a hack to redirect to 403 and a puritan approach of removing links altogether, making pages accessible only through Javascript or POST operations.

4. Links which retrieved data but also imposed exclusive locks on the data: The first user to come along could end up locking quite a bit of system data, thanks to prefetch operation. However, isn’t a lock on data change of application state? The change needn’t be in a database operation. Any change of state should require (scream) POST.

Well, that’s quite an interesting list of 4 points with repeated gyaan which has, no doubt, also been written  before by others. But, as long as reading this post helps at least one developer, I’m happy. Benefited developer, please post a comment so that I stay vindicated

• Password length should be greater than 8 and less than 20 characters
• Password should contain at least one digit [0-9], one alphabet [A-Z] [a-z] and one special character such as [@#&*!]
• Please avoid choosing a password that is generic in nature, guessable or inferable
• Avoid password from your personal data such name, date of birth, address, telephone number and car number
• It is good practice to commit your password to memory rather than to write it down somewhere

Perfect. My generally-used password is 7 characters. So now I have to think of another word, which should have all of the above restrictions, and in addition, shouldn’t be written down anywhere! (As if recovering that password is just a snap)

The problem with overly complicated passwords is this: There are simply too many good things in my life to remember, so in all probability, I am bound to forget this special-character-sprinkled alphanumeric password if I don’t use it within 10 days of its creation. As a result, I am going to be extra cautious and write it down somewhere, irrespective of what SBI recommends. And the moment I write it, my security is compromised.

As Jeff Atwood has rightly pointed out, having a pass phrase instead of a password increases the security in itself, without having to memorize garbled strings. This is because passphrases are far less likely to be broken with dictionary attacks.

We have to encourage users to stop thinking of passwords as single words, and start thinking of them as pass phrases. The worst imaginable pass phrase (eg, “this is my secret password”) is many times more secure than an average single word password (eg, “god123″). And it’s easier to remember.*

As a developer, you need to do your part, too:

1. Absolutely, positively make sure your applications support a password field length of at least 128 unicode characters.
2. In the user interface for defining the password, remind the user that password doesn’t literally mean a word. Give several examples of pass phrases directly alongside the entry field. It’s absolutely imperative that we educate the users– how else will they know there’s some other way to deal with that input box?

The greatest long term security threat isn’t hackers. It’s the perpetuation of the braindead 8-16 character password length limitation, and the idea that passwords are single words.

On a tangential note, if State Bank says “This is your account”, then I believe I’m supposed to understand that I own the account, and any problems in my account are a result of my clumsiness in protecting it (apart from a basic few things that the account provider should give, like encrypted password storage on server). So why am I not allowed to choose the password I’d prefer? I never heard of anyone selling a house with the clause that the buyer is supposed to use locks only from Company X.

Developers, please just concentrate on securing your server, and let the users decide how much security means for them. I might want to sign up for a jukebox website with the password “12″. So what? It’s just a jukebox, not some e-nuke. You want to encourage your users for better passwords? Have hints alongside password boxes, and provide password strength meters. Email them (say twice in a year) suggesting (and not imposing) password change if necessary. That’s good enough.

Give your users the freedom to decide for themselves.

Update: The perfect comic for this post

After thinking about it, I’m inclined to agree.

Older browsers didn’t have this problem: they were not multi-tabbed. And window switching is certainly not disabled by any modal pop-ups.

Browsers evolved, tabs arrived. Today I have 15 tabs opened in my browser. And then say someone sends me a nicely obfuscated script which simplifies to this:

javascript:eval("for(i=0;i<554;i++) alert(123)");

Works nicely in FireFox. Stops me from accessing other tabs altogether till I succumb to the pressure 554 times (and I might not even know the actual figure if its jumbled code)

And lets not forget that this error can be caused without malicious intent. Say some webpage gives out two or three alert messages in a loop, and the loop counter goes haywire because of a corner case which wasn’t tested. It still is a block on all activity in the browser, whether the user likes it or not.

I’m not saying this is some awesome loophole in browser security. But it certainly is more than an irritant if I’ve paid by credit card in another tab, and the site is waiting for me to perform the next step.

The graceful solution for this is to have dialog boxes modal with respect to their own tab. This satisfies all legacy requirements of an alert as well. Currently, browsers have just provided a knife to play with.

Update: This problem has been reported in Mozilla as a bug, verified as a FireFox DoS as early as November 2000.

I think this is really a common problem for web-developers. I’ve fallen into this trap several times myself (accidentally created an infite loop around my debugging alert()). But instead of aborting all scripts, I’d like to have something similar to the “A script on this page is causing Mozilla to run slow” message with the option to abort the script.

Another user writes:

The page in the URL (don’t open it unless you know what you’re doing!) “locks” the user in an endless stream of JavaScript alerts. There is no way out; closing the popup just opens a new one; UI is unresponsive in *any* place except the popup; you can’t cancel the loading of the page (or do something like ESC to stop the script) since the UI is blocked by the popup. The perfect anti-Mozilla DoS.

Yet, the security provided in CCs is pathetic. Let me start my rant with the “industry standard” security that ought to be provided for anything that costs you money, be it Re. 1 or Rs. 1 lakh.

Say you have a bank account and password which serves as identity proof as well as payment proof. How does the bank verify that someone has not stolen your password from password.txt conveniently stored in your notebook?

So the smart banks like ICICI develop a system wherein you need to enter some randomly requested numbers which can be seen at the back of your bank debit card.

The ICICI funds transfer requires you to login, then provide the transaction-specific password (2nd level of security) and in addition, some digits on the back of your debit card. This “some digits” security feature is really good, because the position of numbers requested changes for every transaction.

The security explained above is known as Multifactor Authentication (in this case, two-factor authentication).

Compare this against the current security provided in case of Credit Cards. What is the “password” you use for online transactions? Its the CVV number which is printed on the back of the CC. So anyone who has stolen a CC effectively has access to all the information he ever needed to perform an online transaction. And while we’re at it, why think of only thieves? We don’t even know whether websites retain your credit card information in their database or not. A response from ICICI CC help: “No sir, they cannot retain your CVV number, because it comes in password field, right? It is not displayed on screen, and thus they can’t even store it if they wanted to!”

I nearly died laughing.

Okay, so the security issue is present only for online transactions? Not really. What happened last time you paid for dinner at the restaurant? You slipped the CC, the waiter was kind enough to swipe the card, get the Merchant Copy, Customer Copy, and bring it back to you after a good 5 minutes.

Did he verify the signature you made on the bill against the one on Credit Card? If not, then anyone who finds your card (or steals it) can go to a restaurant and sign as per his will. Will the credit card company pay the restaurant if they see that the signature is incorrect? Of course they will! I discussed this with ICICI bank. The fellow at their helpcenter stressed that it is the duty of the vendor to verify your signature against the one on the back of the card! Well, I’ve never come across any such vendor in my four years with CCs.

Lets go back to the restaurant scenario. The waiter came back after quite a while. It takes around 10 seconds to note all the information on your CC onto a piece of paper. How do you know the waiter didn’t do it? Of course, if he performs any transaction with this information, he can be easily tracked, innit? Oh, but what if he sits in an internet cafe and pays to some shady porn site hosted in South East Asia? Transaction is over, bank has paid them in a few hours and only you stand to be the loser.

So, if CC security is really this screwed up, shouldn’t there be a lot of fraud already happening around here?

The cost of credit card fraud reaches into billions of dollars annually. In 2006, fraud in the United Kingdom alone was estimated at £428 million, or US$750-830 million at prevailing 2006 exchange rates.

After all this, you’d think that some CC provider would want to pep up security measures. Na-aa! In fact, if you try booking any flight via telephone today, the executive at the other end happily notes down all the information required, including your CVV number. This, according to banks, is wrong. Yet, I don’t see any action against this practice.

All in all, credit cards are hardly secure. What can we do in this case? Well there are a few basic measures for us

• Wherever you pay by credit card, ensure the credit card is never out of your sight.
• Never pay by credit card on phone.
• Write more about this on your blogs, spread the message
• Protect your wallet like crazy. If there’s hundred bucks, you would lose just hundred bucks. With cards, you lose a lot more than what you’d like to carry around with you
• Have emergency bank numbers in your phone, pocket, wadrobe, just about everywhere. In case of theft, don’t lose any time in contacting the bank.

Well, it would all be easier if credit card companies followed some more security measures. CC 2.0?

• Have some passwords or PIN numbers for us please!
• Have payment gateways for telephone payments. Use automated systems for users to press CC number and PIN from their telephone. Prevent human interaction.
• Stop printing the CVV on the card. Its not a secret if its on the card! Everyone knows where to find it!

ICICI bank’s website ensures security in several significant areas, where HDFC bank’s portal lags behind with a simple username-password authentication which although necessary, is not sufficient in my opinion. To justify my stand, I’ll run you through some simple scenarios.

Login

We’ll start with a simple one: You are out of town/not on computer/far from any ATM or branch. You need your friend to check up your bank balance. Now, ICICI bank has got 2 passwords. One for logging in and checking the account status and the other for performing any transaction through the account. Thus you can conveniently provide the login credentials to your friend and get details from him without letting him make any mischief through your account.

The multi-password scenario also means that anyone wanting to get into your account and siphon your savings requires more than just the initial login-password combination. We’ll get back to that shortly.

Payments

So lets move on to payments. Assume you are making a funds transfer to someone’s account. Your friend is sitting right beside you the whole time, probably having an eye on the keyboard.

The ICICI funds transfer requires you to login, then provide the transaction-specific password (2nd level of security) and in addition, some digits on the back of your debit card. This “some digits” security feature is really good, because the position of numbers requested changes for every transaction.

The security explained above is known as Multifactor Authentication (in this case, two-factor authentication). This means that the transaction can be completed only if the user inputs something

• He knows (passwords), and
• He has (digits on rear side of debit card)

Although one may argue that all this information can be retrieved easily by holding the account owner at gunpoint, the security for transaction against “stolen” information is increased considerably.

Add Payee

Again, lets assume that someone has been able to sneak into your account, and probably believes that your account deserves a few lakh rupees less. The only way to transfer funds into another account in ICICI is by the following process

1. Add a new “Payee”
2. Receive a notification about the new payee on your cell phone along with a confirmation code
3. Enter confirmation code on the website
4. Confirm payee
5. Transfer funds
6. Enter password and digits behind debit card for transaction authentication

The fun part here is point #2. No one can confirm a payee without having direct access to your mobile phone. In case the attacker attempts to change the mobile number associated with the host’s account, no new payee can be confirmed for the next 36 hours through the new mobile number. To confirm the payee anyway, one needs to call the customer care and provide them with full details, answer their verification questions and only then have the payee confirmed.

In all the three scenarios mentioned above, ICICI strives for the security of user accounts while all that HDFC does is rely on the same old single user-password authentication.

System Security: Verdict

ICICI Bank : 4 / 5

HDFC Bank : 2 / 5 (well atleast the username-password is present )

Update: While creating this post, chat with a friend brought up some interesting points in favor of HDFC bank

• Adding a beneficiary account through HDFC (equivalent to Payee account in ICICI) website takes 24 hours. You get an sms from HDFC Bank mentioning the “Add Beneficiary” action, in which case you can remove that account. This can be done with phone banking.
• Even if someone wants to change your mobile number, you will get a confirmation sms in which case you can notify bank immediately. You probably need to fill a form to activate mobile service and it can’t be altered online.

Although the points do bring up the security rating of HDFC bank to 2.5/5, it still so happens that HDFC bank survives in many situations by being a semi-automated system wherein half the stuff is done by submitting applications to banks (mobile number change, enabling third-party transfer, etc). ICICI bank manages to host their complete system online, yet achieves a fine balance in terms of security.

Thanks to Nishi and Visky for info and tweaks to the post