I recently updated my Facebook password because my password was reset by Facebook for some unknown reason. This incident alerted me of security levels of my passwords. I was pretty much using the same passwords for many of my most important emails but also on some doubtable websites, even though they all claim they will not share registration information with anyone else.

Risks

• Increasing number of phishing sites. Phishing refers to websites which mimic designs of some popular website and asks users of the authentic website to “log-in” to the site. They would then store the credential and use them for malicious purposes;
• Increasing risk of cross-domain scripting attack. Along with the exposure of Ajax, cross-domain-scripting has gained more power and browsers can be tricked to send cookies of some domain to illegitimate domains, exposing important information in cookies to third parties;
• Reusing same id name across all websites. In the past few years many specialized web applications have been built and the Internet has become more heterogeneous. These new web apps offers service like no others. Even though they all provide APIs for other people to access their function, up to now, users still need to have register at all places. Keeping user names consistent is certainly what most people would like to do during registration. Therefore, if someone has gained the username and password pair of someone from one site it uses, it can be reused, sooner or later, on some others, or at least, as a great heuristic guess.

Schema

To guide myself in choosing password during registrations, I’ve created the following diagram to show the level of seriousness in selecting password strength for different accounts on the web.

Highest Level - Frequently Used Emails

We shall use the most complex passwords for these services and never give them to anyone else. These are fundamental online identifications which may help you reset passwords of other services in the case of password breaks.

Second Highest Level - Essential Favorite Web Apps

For some of famous and well-respected web services, we may use a looser password, but still contains variations of cases and character sets.

Second Lowest Level - Not-So-Trustworthy Websites

Some blogs ask users to register before they can post comments. This is okay since they may be victims of spam themselves. Many blogs are well-respected and they offer great contents. The authors don’t really care about your password but simply want to block unfriendly visitors. But the problem is some of those bloggers may not be able to take care of their user info, especially for those non-technical bloggers. If someone hacks through their database and get all the information about you, the damage can be significant. It will happen sooner or later, on some of the blogs. So it’s good to be prepared before hand.

Lowest Level - All Other Websites

If you are visiting some websites with crappy designs, you may need to think carefully before you give away your common password to them. Or any other websites which claim you’ve won a great fortune, stay alerted and calm. Everyone knows they are malicious and deceptive, when they are thinking about it clear-minded.

Misc

A strong password is usually at least 8 character long and would consists of letters in lower or upper cases, numbers, and even punctuation.

Story Telling

I am designing a simple web app that can possibly improve people’s productivity. Even though it’s supposed to be a fast, light-weight web app, it’s still going to be more complex than most projects I’ve done before. So to get a good start on it, I wanted to try out some PHP frameworks to get started and reuse some common features.

Some of the frameworks that came to my vision was CakePHP, Zend Framework, and Symfony, a PHP-Ajax framework that I came across last year. I chose to give CakePHP a try simply because its homepage looked cute. It’s probably not the best but my product is in prototype phase anyways. I don’t see the possibility of making my app available to general public in any recent future (ie. in 6 months or so, but 6 months is probably enough time to upgrade a small website like this onto a production environment).

MVC-The Essential Design

CakePHP follows MVC design pattern and this might be the design of other frameworks I considered too. It’s still one of the most popular and tangible design patterns among enterprise systems.

Model

One confusion I’ve had with the pattern was that I thought the database was the model, but it turns out that there’s another layer between controllers and database, ie. the models, that wrap up complex SQL into meaningful function calls. And this is where the framework comes in handy. Most basic database operations are implemented in a super class Model. Simply implementing this class will allow model objects to interact with database easily, as member functions such as add, del, and some other helper queries like findAll, and findId etc. I am not very precise on the names but the stuffs are there.

Controller

Classes that implements Controller usually contains handling functions. The framework maps actions extracted from url to functions in corresponding classes. The rule is like this: domain/model/action will map to function action in model_controller. “_controller” is the standard postfix that represents controller of model with name “model”. A typical use, adapted from CakePHP manual, domain/posts/add calls posts_controller->add to add new post.

View

In CakePHP, the view layer are partial html files with file extension .thtml. There’s a overload here between controller and view. For example, in the above section, we know domain/posts/add can handle POST/GET requests to store new post in database, but the url domain/posts/add is also used to access the add new post interface/form. I guess the framework detects POST/GET field in HTTP requests and handle actions before displaying the view.

*I need to check the above statement as I gain more knowledge of the framework.