13 April, 2012

18 Testing Challenges from Santhosh Tuppad - Part I

My friend cum colleague Santhosh Tuppad posted 18 testing challenges to the testing community on his blog a month ago. I have had lengthy conversations on security testing with Santhosh for a while now. The work that follows in this blog post is dedicated to him as I learned a lot about security and usability from him. I wasn't too happy when I asked him a lot of questions on his test challenges where the context was not clear. He clearly mentioned that he wants me to let my imagination free and work on the challenge. There you go.

1. What if you click on something (A hyperlink) and to process or navigate to that webpage you need to be signed in? Currently, you are not signed in. Should you be taken to Sign up form or Sign in form? What is the better solution that you can provide?

Why take the user to Sign In page?
I always face this problem on FashionandYou :-). If I had to click on a hyperlink which required me to Sign in, I expect to be taken to the Sign In page where a message “This requires you to be logged in” is displayed to me. This solution offers 2 benefits - one, it tells me why I am taken to Sign In page. Two, it takes me to the correct page.

Why not take the user to Sign Up page?
It’s incorrect to assume that all users who are not logged in are new users. There could be few existing users who are interested to browse without logging in. Taking existing users to the Sign Up page might offend the users.

Why display a message while taking the user to Sign In Page?
Some users won’t understand why clicking on a hyperlink is taking them to the Sign In page. It’s better to display a short and crisp message to the user about the need to login to view that page. Please note that forcing users to login to view the content on retail websites is a bad idea. Users must be allowed to login if they need to make a payment or save something to their cart. Eg. Flipkart.

Why not display a dialog with a message while taking the user to Sign In Page?
A dialog just to convey a message is an overhead. Expecting the user to perform an additional step to click ‘Ok’ or whatsoever is a bad usability expectation.

2. Using “Close” naming convention to go back to the homepage is good or it should be named as “Cancel” or it is not really required because there is a “Home” link which is accessible. What are your thoughts?

Since the question talks about going back to the Home Page, a “Back” button is apt. Browser’s “Back” button perfectly serves this purpose.

Providing a “Home” link on every page of the website makes the website more usable across all pages. The website design must be such that “Home” link is placed in a location that is clearly visible. User must be able to go to Home page no matter which part of the website he is on.

Having “Close” or “Cancel” option adds to user confusion. “Close” is generally attributed to closing the currently open page or dialog. “Cancel” is meant to cancel ‘In Progress’ operations. Using these terms will deviate the user from what he intends to do on the website. Hence, it’s better not to use these words to switch to Home page on websites.

3. Logout should be placed on top right hand side? What if it is on the top left hand side or in the left hand sidebar which is menu widget like “My Profile”, “Change Password” etc. – Is it a problem or what is your thought process?

I am used to “Log out” option on right hand top corner of the page. I was fuming when Google and Linked In made it a 2-step process where user needs to click on his “” hyperlink, click on “Log out” to log out successfully. Why accomplish the same task in 2 steps when it can be done in 1 step.

We need to optimize the number of clicks used to access any feature on user facing applications. Top class CRM companies follow a guideline as follows: “User must be able to access any feature on the application with 4 clicks or less”.

If I happen to use sites where Log out feature is on top left hand side or left hand sidebar, I would struggle initially to learn where the Log out option is. Once I learn, I would go back to the same place the next time I log in. Please note that this is where learnability and memorability comes into picture. Log out option must be placed such that it is easy for a user to learn quickly. Also, The Log out button design and position must be memorable and easy to recall. It must be good enough for users to be able to remember where it was the next time they login to differently designed websites.

4. Current design of forgot password asks for username and security answer and then sends a link to e-mail inbox to set new password. How does “security answer” increase the cost of operations? Also, what questions do you frame for security questions?

I often forget my security answer. Where do I go? I would call the support team ;). This means the organization running the website needs to have a toll free number or a 24/7 support line. This also means that there need to be support personnel to support the calls 24/7. This also means appropriate office infrastructure needs to be in place to setup a place for support folks. This is huge cost. Any organization professing for security without having above system in place could lose credibility with users.

The regular questions of “What is the name of your first pet?”, “Which school did your grandma go to?” are way too easy to guess for an amateur hacker using social engineering attacks. It would be a good idea to allow the user to frame his questions. This way, there is some amount of confidentiality involved.

Again, the security answer must be masked. What is the point doing something that could be seen by any person sneaking into your computer (Shoulder Surfing)? It’s important to maintain secrecy of secret questions and answers. Please note that there is always a risk of people forgetting secret questions and/or answers. In all probability, some people would write it in a sheet of paper or maintain a dairy of passwords ;-). I won’t dare to say women do this for fear of hate mails :-)

5. If you had to design “Forgot Password” working, how would you do it and why? You are free to give different many functional designs.

My design for Forgot Password would be a 3-step process as follows:

Step 1: Identify the user
There needs to be a clear cut mechanism to identify that the user who has initiated “Forgot Password” option is a genuine user of the system. I would implement a 3 step verification process to identify the user.
a. Firstly, I would ask for a valid username/email address.
b. Secondly, an additional step could be introduced to make Forgot Password feature a little more secure. I would include a step wherein a randomly generated security code could be emailed/messaged (sms) to the user (assuming email address/phone number is provided by the user during this step). User has to look up the security code received in email/sms and key in on this page to go to next step. Eg. security devices from HSBC bank or Security code in SBI for online transactions.
c. Thirdly, have a strong captcha to prevent spam bots from accessing Forgot Password feature. Captcha must not be simple enough to be cracked by hackers. It’s important to have a robust set of captchas so that there is no room for automating this step and get over it.

Warning
Username/email address field must not be sent as a form parameter when the user submits this page. This data must be stored on the server. If this gets retained in browser cache or gets sniffed over the network, it could be party time for hackers.

Some security evangelists suggest including a data gathering phase in Step 1 by asking details for any 3 data points from the following list - email address, account number, last name, customer number, date of birth, last 4 digits of social security number, zip code or others.

There is a serious threat to Forgot Password feature if above information is used to identify the user. With some amount of social engineering (http://curioustester.blogspot.in/2011/12/social-engineering-attacks.html)on the internet and at a personal level, hackers could get any of the above information easily. Let me give you an example - I need the email address of Sachin Bansal, CEO and co-founder of Flipkart. I know that the domain is flipkart.com as I get all of my Flipkart order information from cs@flipkart.com. The first part of the email address could be Sachin.Bansal or Sachin_Bansal or sbansal or sachinb or sachin or sb.I can start by attaching this to @flipkart.com and get the real email address in all probability. And then, we have Facebook, we have other social media sites to confirm if our research fetched the right result or not. Welcome to the insecure and public world of social media! Your security is at stake!

Step 2: Test if the user is a genuine user
If you happen to be on a few bank websites, there are a host of security questions posed to you to identify if you are a genuine user or not (second level check). Presenting the user with a ready-made security question like “What is the name of the school where you studied” or “What is the year of your graduation” are dangerously scary questions. As I mentioned in Step 1, social engineering attacks can help hackers find such information pretty easily.

Create your own security question
My implementation would mandate the user to create his/her question and provide a security answer. This way, there is some amount of confidentiality involved.

Mask your security answer
Again, the security answer must be masked. What is the point doing something that could be seen by any person sneaking into your computer (Shoulder Surfing)? It’s important to maintain secrecy of secret questions and answers.

Warnings
1. There is a support cost involved if Step 2 gets implemented. What if user forgets the security answer? What if user forgets the security question? This calls for a 24/7 customer support to fix user problems. Please note that there is always a risk of people forgetting secret questions and/or answers. In all probability, some people would write it in a sheet of paper or maintain a dairy of passwords ;-). I won’t dare to say women do this for fear of hate mails :-)
2. Another problem with this solution is the fact that users might set a weak security question. If users end up setting simple questions, it’s no better than ready-made questions already asked in many websites.

Step 3: Reset the password
If user clears Step 1 and Step 2 above, he must be taken to a simple page where New Password and Confirm New Password fields must be present. Ample password complexity must be enforced. Password strength indicator could be a good guide for users to set strong passwords. Once the user has changed the new password, the system should log out the user and ask him/her to return to login page and re-login.

Do’s and Don’ts while designing Forgot Password feature
Do’s

a. Passwords must not be stored in plain text or using weak encryption methods in databases. It’s better to use hashing mechanism to store passwords, the standard being SHA-256
b. AutoComplete must be set to Off on all pages relating to Forgot Password feature. This way, valid usernames won’t be revealed to users who access the same website
c. If the user has reset the password, it is a good practice to send an email to the user indicating the password has changed. Email must not contain username or password information. This will facilitate non-repudiation
d. Sending sensitive information using HTTP GET method is not safe as such parameters get sent as part of the URL and recorded in server logs and browser history. Forgot password page data must be sent as HTTP POST data in http request body

Don’ts
a. Don’t Email the password (permanent or temporary) to user’s email address. Emailing the password means the emailed password is easily visible for hackers sniffing over the network traffic
b. Having a username in the same email will be a bonus for the hacker as he has username and password in the same email if he happens to receive any such email due to a flaw in Forgot Password feature
c. This mechanism could possibly mean password is stored in the backend database in unencrypted format or using a simple encryption algorithm that is easy to crack at database level
d. Shoulder surfing could be used by some folks around you at work or home and get your password easily
e. If a temporary password is emailed to the user, the user is expected to reset the password. Until the time user resets the password, the temporary password could become accessible for hackers in one way or another. If hackers have discovered a patter with temporary password, they could easily crack it. For eg, for one famous bug tracking system that I used in the past, ‘password’ is the temporary password. I can login in as anyone if I have their first name and last name :-)
f. If a temporary password is emailed to the user, there’ll be a hyperlink provided to the user to reset the password. The validity of this hyperlink needs to be handled. What if user doesn’t reset the password within designated time? What if the hyperlink is not limited to time use?

6. There is neither account lockout policy nor captcha for the login or security answer forms; what kind of problems do you see with the current implementation and what do you propose?

What if there is no account lockout policy?
Scenario 1
Assume there was no account lockout policy on your HDFC bank account. Suppose that you want to cause harm to a person whom you hate at work. Just steal his official correspondence from publicly accessible pigeonhole at office and get his customer id. Sometimes, his dustbin could have some torn bank paper which has confidential details. Once you get first part of the detail, you could exercise brute force attack or dictionary attack to crack the password. Since there is no account lockout policy, there is no fear of account getting locked and hence stopping the trials. If you apply a few social engineering principals and get to know his wife, kids, pet’s or hobbies, you could build a customized dictionary of passwords and execute them to access the bank account.

Scenario 2
Assume you are a proud owner of Gmail with unlimited access to emails and the space, of course! Assume Gmail did not have account lockout policy. Anyone could get your Gmail - email address and use it to crack your account.

Following is a short write-up of how anyone with a little sharp brain could hack your passwords and crack your email accounts:
1. Password has names of your family member's names, girlfriend, boyfriend, best friend, kids’ names, and gods’ names - LoveuJohn
2. Password has your Date of Birth information - Pooja81
3. Password is same as your username - Rob123
4. Password has your age information at the time of account registration - Amy18
5. Password has minimum number of characters starting from 1 and easy to attack using brute force method
6. Password allows alphabets (capital/small), numbers or special characters without mandating any rules
7. Password is a commonly used word like password, admin, administrator, test, user, guest, James etc
8. Using your nick name or your pet's name.
9. Using same password for personal, official, financial accounts
10. Using poor password validations that don't verify incorrect passwords
11. Using applications that don't validate passwords after 'n' number of attempts
12. Using numbers as password - 12345678
13. Using names of games/hobbies/interests - cricket, football, chess
14. Names of favourite animals
15. And many more easy options....

Here's a list of Most Popular passwords in 2011 courtesy - http://gizmodo.com/5861667/the-25-most-popular-passwords-of-2011
1. password
2. 123456
3.12345678
4. qwerty
5. abc123
6. monkey
7. 1234567
8. letmein
9. trustno1
10. dragon
11. baseball
12. 111111
13. iloveyou
14. master
15. sunshine
16. ashley
17. bailey
18. passw0rd
19. shadow
20. 12312 

21. 654321
22. superman
23. qazwsx
24. michael
25. football

Is your password same or close to one of the above?

Moral of the story
Never ever have an account on the website where account lockout policy is not implemented.

What if there is no captcha?
No Captcha on Registration forms
This is a wholesome option. I recently needed 50 valid email accounts to be created for testing a website. All I did is write a simple automated script using iMacros (FREE add-on) for account registration and creation. All I had to do is activate these email accounts manually (note that this step could have been automated too). At the end of the testing effort, these accounts were discarded. Now, if you are a company that allowed 50 email accounts for a single imposter, you lose an awful lot of revenue. Is this what you want? If you had a captcha in place, my script would have failed as captcha expects different data at each times which needs human intervention. Building a captcha on registration forms is a good design idea to snub away not-so-serious users or spammers.

No Captcha on Forgot Password forms
If there is no captcha on Forgot Password form, I would possibly write a script to feed in umpteen number of valid email addresses to the Forgot Password page. Why would any user do that? He could be a cranky user. He might draw fun in irritating fellow users. He might be an unethical hacker. He doesn’t know what to do with his life!

No Captcha on Comments forms on websites and blogs
As a blogger, I get a lot of spam comments advertising Viagra and Penis Enlargement. I wish spammers took segmentation and targeting seriously and routed their ads to appropriate audience :-). Without a captcha in place, spammers can write easy little scripts to post these *free ads* in the comments section of any website. Having a captcha would require human intervention which in turn might block spam.

What do I propose?
I propose account lockout policy with 5-10 re-attempts as required by the application based on the domain and the context. It’s very important to have captcha in place in scenarios described above.

7. Well, it is about context and there are no best practices in general. What are your thoughts on usage of captcha? Where should they be used and why?


Captcha is a program that protects websites from bots by presenting tests that humans can pass, but automated scripts or programs can’t. These days there is a rise in the number of bots that use websites in harmful (or rather spamful) ways.

  1.   Imagine a bot written to register on www.yahoo.com. The script would hit the registration page, fill in all fields as programmed from a data file and submit the registration page. If the bot repeated this for say a million customers that is a huge loss of revenue for Yahoo! Why would anyone do that? He may be frustrated with yahoo. He may want to frustrate Yahoo and get fun out of it. He may want to create a performance overhead on Yahoo servers etc. 
  2. Imagine a bot accessing Forgot Password page. Anyone could write a program to pump in all valid usernames/email addresses and try re-setting passwords for umpteen numbers of users. This not just clogs the server, but could result in millions of customers filing lawsuits against such a website for breaching trust.
  3. Imagine running a website where you receive millions of comments on your website or blog. A bot is usually at work posting all those scary ads on products you may not be interested in. What if your website ran out of energy to take any more comments? It would just crash. Your credibility is at stake.
In each of the above cases, it is important to restrict bots from causing unnecessary harm to the websites. Above actions might overload the server with too many requests hence bringing down the server due to performance overhead. To avoid this and other similar situations, its good to bring in a captcha. 

To be continued with Part 2 next week.............................


Regards,
Pari

6 comments:

Parimala Shankaraiah said...

Test comment from Firefox

sandhya said...

truly awesome post yar:) became great reader of ur blog now... small request, can u post a real time web application example and tell us some useful tips and tricks to perform end to end testing please

Santhosh Tuppad said...



Q1. <>

Q2. <>

I appreciate your thoughts on "Close" and "Cancel".

Q3. <>

Liked your point about "Learnability".

Q4. <>

Q5. <>

Q6. <>

<>

<>

Q7. <>

The solutions / answers / comments that you have provided might suit in some context but, not all. To me, it looked like these are straight-forward answers which you might want to change. May be you did not mean it but, the way you have framed the statements is making it look like that.

Re-working on this can help you in your learning. May be you could get better ideas.

While you won the challenge, you might want to be unbiased and make things much better :)

Looking forward for your response (May be as a comment here itself or we could take this up in person when we meet at our mutual availability).

Thanks,
Santhosh Tuppad
http://tuppad.com/blog/

Parimala Hariprasad said...

@Santhosh

Santhosh, Thanks so much for returning to this old blogpost and adding comments to it.

I understand what you mean when you wrote, "straight-forward answers". I agree to it partially. As a sporadic beginner in security testing, I can say these are the things that came straight to my mind which is also attributed to my limited knowledge in this area.

All I can tell you right now is that I can go back, study further and get back to you.

Does that make sense? I hope so.

Regards,
Parimala Hariprasad

Sree said...

Nice one!! you have covered almost every aspect to be seen for a secured login. Thanks for sharing it.

Ayush Kapoor said...

Q1. We can also user light box and not transfer the user to the main registration page instead open a light box on the same page and after login throw the user on the same page.