CIS326: 2010/11 Assignment 1 Postmortem

I felt that for a take home assignment, the quality should have been much better. Unfortunately, that is generally not the case.

Q1.
+ Most students are able to list key points such as:
- The weakness of the system generated password (same as username, dictionary word, too short, etc)
- The fact that the system should have placed the onus of password creation on the user, rather than to try to create a password for them
- The lack of system mandated password change upon account recovery
- The lack of system notification to the user of an attempt to change password or after the password is successfully changed
- The ease by which the password reset request was made could have opened the reset function to abuse: anyone knowing the user email address could have sabotaged the user by issuing password resets.
- The use of one-time and time-limited tokens, passwords or links to reduce the risk of exposure should users' email accounts be compromised.
- Use of CAPTCHA's to defeat robot attacks on password reset function.

+ Lots of students keep harping on the Subject Line being labeled as "New Password" as being poor. Is labeling the subject to some innocuous such as "Psst." or "Blank subject" more secure than a clear statement of intent? The fact is, hackers do NOT need to use an email client just to hack an account. By placing devices in-line with routers or mail servers, hackers already have the full context of the email. Whether you place the word "Password" in the subject line or body makes no difference to the hacker. Mislabeling or not labeling the subject of the post can cause other problems as users may miss the emails themselves! I will not penalise anyone for using this as a point, but you don't get credit for it either.

+ Only a few students focused on the concept of encryption for emails. The fact is, if the email has been encrypted using PKI (ie. S/MIME or PGP), it really does not matter what the content of the mail is. Hackers can intercept the packets, but cannot read them.

Q2.
+ Most students were about to use good examples to compare, ie. bank/Paypal vs gaming sites
+ Most students were about to talk about the key points:
- Use of 2nd factor authentication for high security apps
- Use of OOB channels for passwords
- The use of one-time and time-limited tokens, passwords or links to reduce the risk of exposure should users' email accounts be compromised.
- Use of CAPTCHA's to defeat robot attacks on password reset function.
- Forcing users to change password on first login.

+ There were some cases where students simply lifted off literature from other people's papers without value-adding on the answers. This is a VERY DANGEROUS thing to do especially since the question did not suggest you could do so.

+ While students were able to describe their observations, most unfortunately could not do proper critical analysis of the difference between the high and low security applications.

+ Few students talked about the need to balance level of security against the value of the information system being protected. High security does not come for free: it has investment costs and productivity costs. High security makes systems harder to use. It could increase the barrier to entry for mass-market industries such as games, social networking sites, etc, making it unattractive for people to want to try out the system. Security that is too high can KILL such businesses! Financial institutions, however, have to comply with government regulations to protect its customers. They have to put in place sufficient security to satisfy the authorities, and to protect their own reputation by reducing their vulnerability to hackers.

+ Few students talked about the implication of email-verified accounts. The fact is, just because Mr Smith has access to the smith email account by providing the correct password, it doesn't necessarily mean that Mr Smith is indeed who he claims to be. It is well known that you can be a dog on the Internet and no one will know the difference. This is an important point when discussing Q2 because a high security application will require more than just email-verified accounts. Students who chose a financial (bank) example should have talked about this point. Students who chose Paypal as the high security example has less scope, but should have noted that Paypal also requires additional levels of authentication (eg. proof of ownership of credit cards, physical ID checks when transfers exceed a certain amount, etc) to increase the "trust" level granted for his Paypal account.

Q3
+ Most students were able to at least provide rudimentary descriptions of rainbow tables. Some simply cut and paste answers from the web and books without value-adding.
+ A number of students merely described the Rainbow tables without doing any critical analysis. Essentially, the Rainbow Table is a solution to reduce the size of hash tables for reverse engineering plaintext passwords hashed with one-way functions, replacing brute force attacks (of complexity O(b^n)) with simple look-up tables (of complexity O(1)). However, due to the sheer size of hash tables needed to store all the possible passwords in the password space, it is not practical to create, store and use hash tables just to hack passwords.

Rainbow tables allow us to store just a small subset of these hashes, and generate all other hashes from this subset of hashes. The initial subset of hashes act as the head of a linear list of hashes that can be created on the fly using a series of hash-reduce functions. The hash function is the same one-way function that converts plaintext passwords to their hashes. Each of these hashes are then passed through a "reduction" function which maps it into ANOTHER possible plaintext password. Important note is that the Reduction function does NOT decrypt hashes back into their original plaintext passwords - they create a totally different plaintext password which can then be used to generate another hash.

Important point to discuss is that the length of the hash-reduce chains directly impacts memory and speed of the algorithms. Long chains make the attack slower, while short chains use more memory.

You can also talk about the possibility of collisions happening in the reduction function, causing 2 different chains to produce the same values. To prevent this, multiple reduction functions are used for different chains.

It is also important for students to point out that an effective way to defeat rainbow table attacks is by using password salts, so that password hashes are now based on "plaintext password + salt" instead of simply "plaintext password". So there is no longer a one-to-one mapping of a plaintext password to a hash.