Code Away

In a hurried attempt for “increased security”, portal developers are coming up with really wierd ways to ensure that users don’t keep simple passwords which can be broken with dictionary attack. For example, our very own State Bank of India, recommends (imposes) this:

• 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

While posting about usability of alert, I was chatting with a friend who saw it not just as a minor nuisance, but a greater threat. Since alerts interfere in user activity in other tabs, we have a basic case of client side DoS, he said.

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.

“Use plastic money” is supposedly the advice floating around. Safe, secure, instant transactions – all marinated, cooked and ready to eat. Facilitates the banks, vendor and client. All in one. Fantastic.

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!