Author: admin

No posts for the whole of December – because of several reasons. One being the festive season I spent less time at the computer so there’re less stuff to write. Second and more importantly I registered new domains and was busy migrating stuff over. Currently the forum and blog migration is complete, I’ll need to move the wiki stuff into this system as well.

Will be writing more about the new stuff after migration. In the meantime, have a happy 2007!

To reduce cases of phishing and sniffing of passwords in Internet Banking, banks are now introducing 2-factor authentication using a little security device. You press the only button and a 6 or 8 digit passcode appears, which you have to enter after your username/password.

In this way hackers not only must know your username and password, they need to gain physical access to your device to complete the stunt. Similarly only getting your device doesn’t give the hacker access to the account.

But how does the device work? How does it generate the number? Is it unique across so many devices in circulation? Can the algorithm be reproduced?

Little information has been provided, probably in hope of less attempts to break it. However, as history shows, security by obscurity will never work. From the information gathered, the device contains a clock, a unique serial number and the algorithm. When the button is pressed, the algorithm takes the serial number and clock as input to generate the number. Since the server knows the time and your serial number (based on your username/password) the server is able to perform the same calculation to verify the numbers entered.

What I felt intelligent in this algorithm is the use of time as input. This means the numbers are only valid for probably the minute the button was pressed – you cannot just remember 1 set of digits and use it every time you login. Instead you are forced to press that button every time.

[1] http://in.answers.yahoo.com/question/in … 355AAe8u8T
[2] http://www.hsbc.co.nz/nz/security/osd/default.htm
[3] http://www.hangseng.com/hsb/eng/onl/sec … x01.html#1
[4] http://computerworld.com.sg/ShowPage.as … issueid=91

On this blog [5] the author feels the device is an overkill. He compares it to another secure account that he has that does not require the security device.

However I feel that despite user education, not all may be able to maintain the rules of thumb. Users who change passwords frequently do not remember their passwords (I have a perfect example for that). With the increasing number of internet applications and passwords to maintain, if every application forces users to change their passwords so regularly, users end up wasting time changing system passwords every other day, and forgetting that password soon after.

Layman users may also not know if they are on a secured or unsecured connection, or if any part of their connection is unsecure. Even if the system is his personal desktop that no one else has access to, it is not guaranteed to be free from keyloggers. With the security device the account is more protected since keyloggers are no longer effective.

[5] http://technobiography.edongskey.com/ne … ty-device/

This tool allows you to change your Windows XP registration key:

http://www.magicaljellybean.com/keyfinder.shtml

A “tutorial” or introduction can be found at:

http://www.shivaranjan.com/2006/09/18/h … formation/

Based on information on:

http://support.microsoft.com/default.as … us;Q328874

According to the 2nd link, it is legal to use the tool in the 1st link, since the method has been publicly describied on the 3rd link. The tool simply implement the method described.

The past week happened to be sort of a Security Week. On separate ocassions I was working with symmetric key cryptography and PKI using certificates with digital signatures.

Symmetric keys were more straightforward. Create a cipher, throw in the secret key and data – viola – you have the encrypted data. What’s left is just to keep the secret key safe. DON’T overwrite it yourself!

PKI with Java needed more effort. As usual it was the confusion between the terms: keystore, certificate, signature, CA, keytool, etc. Despite understanding it before, the knowledge just got lost somewhere at the back of my brain.

So what I’ve figured out AGAIN today was: Certificates were invented as an attempt to solve the problem of public key distribution, through a trusted Root Certification Authority. A certificate contains a public key, information about the certified entity, and a signature.

The signature is created by encrypting the HASH of the certificate information and public key using the private key of the certificate issuer. Therefore the signature algorithm is described using a hash algo WITH an encrytion algo, e.g. SHA1withDSA. To verify the signature, calculate the hash using the hash algo on the certificate. Use the issuer’s public key to “decrypt” the signature to get the original hash. If both hashes match, its a valid signature. You do not have to calculate the hash yourself, Java has Signature classes that will compute the hash internally; you just supply it with the relevant data.

A keystore is a database of key pairs and certificates. Certificates may also be contained in independant files. The keystore is protected by a password, and individual key pairs within the keystore is protected by another separate password, each key pair has its unique password.

The keystore can be manipulated using the keytool command line tool. My preferred method is using Windows tools such as KeyToolGUI to help manage and generate keys. Of course if you’re on Unix then too bad. Using keytool you will be able to generate key pairs, export public keys to certificates and import other certificates. A Java application can also read from the keystore (with appropriate passwords) to access key pairs and certificates for the corresponding public/private keys. The keys can then be used in code to encrypt, decrypt, sign, verify signatures, etc.

Sample code are not provided as they can be readily found on the web and by referencing APIs.

Task: Play MobTV video on Creative Zen Vision W.

MobTV explicitly states Creative Zen Vision W cannot play their video. We realized the videos uses Microsoft’s Digital Rights Management (DRM), and requires a unique machine-dependant license file to play the video. This can be obtained by logging into MobTV as prompted when the video starts.

Although Zen specification states that it is using Windows Media Player (WMP), it seems unlikely that it will be able to establish an internet connection to MobTV to acquire the license.

Fortunately we were able to find a tool for removing the protection on the file. The site also provided a detailed description on the algorithm used by Microsoft for protecting the media.

Once the video has been unprotected, it can be converted into a Zen playable format and transferred to the device for viewing pleasure.

— Disclaimer —

This article is meant to be educational. I am not responsible for any damage to your device should you decide to try any of the steps mentioned in this article.

This article helps users with VALID MobTV licenses to view their video on a mobile device. Users are not supposed to share their non-protected content with others who do possess the necessary MobTV licenses.

Exactly a month since the last update! haven’t been experiencing much new things. However, I got my hands dirty on a Solaris machine on Friday, so here it is.

The OS was installed completely, but had no other users except root so I was denied telnet access. Soon I found out that user management in Solaris isn’t like Control Panel > User Accounts. Though somewhere someone said there was a UI user management tool in CDE, we were on the Java Desktop. So down we went into the Terminal.

We managed to finally create users after many trial and errors of different switches to find out what was required and how to fill in the options. We first created a group:

groupadd [groupName]
groupadd test

Simple enough. The useradd command was tougher:

useradd -d [homedir] -g [groupName] -s [shell] [loginID]
useradd -d /home1/test -g test -s /usr/bin/tcsh test

The example I found for the shell path was “/usr/local/bin/tcsh”. Yours could be somewhere else so do an intelligent search for shells with “ls *sh” as you traverse the “/usr” directory. Apparently even as root I had problems using “/home/test” as the home directory, with an error “Invalid Operation”. WTF?

To assign a password to that user, type the following and the shell will prompt you for the password.

passwd [loginID]
passwd test

Well I mentioned I had problems with the home directory so I was trying to adjust it by using “usermod”. Didn’t seem to work. Finally I resorted to “userdel” and redoing “useradd”… 🙁

Once the user was created, I was able to telnet, ssh and ftp into the machine remotely, even perform su to root for adminstrative access.

Stumbled upon the RSS on Microsoft Watch, which included instructions for using USM with RSS. USM allows you to automatically subscribe to the RSS simply by clicking on the RSS link.

Previously, the RSS links to the XML file when you click on it. It is required to copy the link and register it with your favourite RSS reader. With this mechanism, the instruction to register the RSS is embedded within the click using a specific MIME-type, which can be handled by a USM application. The application would interpret the RSS URL and register the feed with your favourite RSS reader that the USM application supports.

The protocol is fully specified at this location:

http://www.kbcafe.com/rss/usm.html

I was told by one of our users today, “This feature is very straightforward, very logical and intuitive one…”.

What I felt he meant was a nicer way of saying: “Use common sense and you’ll know la…”. Yet we know we don’t understand enough about that feature.

In reality, common sense isn’t so common after all. I mean, what I think is common sense, is based on my experience and what I think everyone should know. However, that is so not true. It is related to one’s experience and culture, and how he/she see things.

This common sense problem becomes more problematic when dealing with user requirements. The user feels that the requirements are complete, because the omitted details are so logical, sensible, and can be automatically and “inituitively” interpreted by anyone. And so he may choose not to go into the level of detail necessary to save time and saliva. That assumption may lead to incorrect implementation, due to domain ignorance of the developers, especially if they don’t make an effort to clarify the requirements.

Of course it’s unlikely you’ll get totally complete and totally unambiguous requirements, but you should try to understand as much as possible. On one extreme is believing there’s such thing as a “complete requirements”, and the other end is believing there’s no such thing so we can ignore requirements gathering.

Better be shot during requirements stage than to be strangled after development when the product don’t meet user expectations. The cost of change would be too high then.

XAMPP is a ready-built apache web server with the attached modules, all ready for it. Instructions say jus unzip and use!

Izit real?

http://www.apachefriends.org/en/xampp.html