Borrowing

In my office, there is a security constraint. Only the drivers who have been appointed by the Administration department are allowed to enter the office premises. This constraint is implemented by issuing an ID card. This allows unauthorized persons to be restricted.

There may be a few situations where in the driver may not be able to attend the duty. This makes the logistics company that is under a contract from my office to provide transport facilities will be under a loss as an alternate driver cannot be sent at the spur of the moment. However, as with many other security systems, there is always a workaround. Cab drivers never wear it on themselves. Instead they hang it to the rear view mirror. A security guard makes a note of the cab number and checks from a distance if there is an ID card. The cab will be then allowed to enter!

This security lapse is not just in my office. It was a part of many of the Software applications. The Software manufactures used to think that all the Customers were honest and will buy the Software (just like the security guards in our office).

Just like one driver used to share his ID card with his fellow driver, general people used to share their Serial code with others. The Software was designed in the good old days when there were very few computers and security was not a big issue.

There was a simple algorithm that was run during the Software registration. It is similar to a Checksum algorigthm. The serial code entered is processed and a string is generated. If the string is similar to the string generated by the security algorithm with the same inputs, the "Thank you for registering" greeting is generated. Although this system is outdated, a few software still uses the same technique.

After the Software companies noted this flaw, they started using the Username based serial key. In this version, the serial code is not a single line key. Instead, based on the username, a registration key is generated. Borrowing of course, by-passes even this.