Linux Kernel has surpassed 10M lines of code including comments, blank lines etc.
What does that really mean ? Wouldn't adding or deleting blank lines, comments and other irrelevant text/characters skew the metrices ?
Is number of lines really a meaningful measure of the largeness (size, complexity etc) of a software ?
Counting the number of language statements may not be perfect but would be a far more accurate measure of size/complexity, esp. compared to raw lines of text.
e.g. Conditional statements can be counted as sum of "if" and "else" block counts, and similarly for looping statements.
The same may apply to scripting languages.
Food for thought: But what about assembly code in large projects like the Linux Kernel ?
Wednesday, October 22, 2008
Saturday, February 24, 2007
Can New York Times cause Identity Thefts ?
Can New York Times cause Identity Thefts ? Sure.
Today I ran into an interesting New York Times article on Identify Thefts/Frauds. Here is a link to that article - Think Your Social Security Number Is Secure? Think Again.
This article informs users about the threats of identity theft and has a link to a search page developed by a company called TrustedID, where people can test if they could be a potential victim to identify fraud. Do not enter your social security number here. Here is the link to the site the article mentions - StolenIDSearch.
It is ironical that the search site violates all principles of online security which can lead to identity thefts as millions of New York Times readers who trust New York Times lose their social security numbers just to check if they have already been stolen.
New York Times should have respected user privacy, and ensured that this site used secured hash functions such as MD5 or SHA1 to verify the social security numbers instead of making users send the number unhashed to this internet site. Here is the safe way to do this -
How can such search sites verify Social Security Numbers without revealing them -
One way to do it is - to include a Java Script hash function (such as MD5 or SHA1) in the search page. At the minimum, they should hash the social security number entered on the search page before sending it to the site, and then compare it against the database of hashed social security numbers. Of course - Ideally, Web browsers should provide secured hashing functions so that users don't have to trust the web sites implementation, based on universal web standards.
Lastly, the scheme can be made more secured by including a nonce (non-repeating random number with a monotonically increasing 32 bit counter) to hash the SSN with first and last name, and then sent to the site for comparing against the database of hashed SSN entries. While this is more secure, it is more compute-intensive, since pre-generation of hashed entries cannot be done due to the use of the random key.
In conclusion, New York Times did a great job describing the threats of Identity frauds but it should have been more responsible and respected user privacy by not directing them to sites that can potentially steal social security numbers while verifying if the SSN is already stolen, by not following basic security principles (such as - using hashing to verify without revealing).
Vishal.
Today I ran into an interesting New York Times article on Identify Thefts/Frauds. Here is a link to that article - Think Your Social Security Number Is Secure? Think Again.
This article informs users about the threats of identity theft and has a link to a search page developed by a company called TrustedID, where people can test if they could be a potential victim to identify fraud. Do not enter your social security number here. Here is the link to the site the article mentions - StolenIDSearch.
It is ironical that the search site violates all principles of online security which can lead to identity thefts as millions of New York Times readers who trust New York Times lose their social security numbers just to check if they have already been stolen.
New York Times should have respected user privacy, and ensured that this site used secured hash functions such as MD5 or SHA1 to verify the social security numbers instead of making users send the number unhashed to this internet site. Here is the safe way to do this -
How can such search sites verify Social Security Numbers without revealing them -
One way to do it is - to include a Java Script hash function (such as MD5 or SHA1) in the search page. At the minimum, they should hash the social security number entered on the search page before sending it to the site, and then compare it against the database of hashed social security numbers. Of course - Ideally, Web browsers should provide secured hashing functions so that users don't have to trust the web sites implementation, based on universal web standards.
Lastly, the scheme can be made more secured by including a nonce (non-repeating random number with a monotonically increasing 32 bit counter) to hash the SSN with first and last name, and then sent to the site for comparing against the database of hashed SSN entries. While this is more secure, it is more compute-intensive, since pre-generation of hashed entries cannot be done due to the use of the random key.
In conclusion, New York Times did a great job describing the threats of Identity frauds but it should have been more responsible and respected user privacy by not directing them to sites that can potentially steal social security numbers while verifying if the SSN is already stolen, by not following basic security principles (such as - using hashing to verify without revealing).
Vishal.
Monday, February 5, 2007
Security: Great Ideas with Bad Implementation (BoA SiteKey)
Recently, I came across a New York Times article on a study conducted by Harvard and MIT researchers about the SiteKey security technology implemented by the Bank of America.
The key idea of the technology is that human beings remember pictures and images much better than text. As a result, the site complements the use of text based passwords (instead of eliminating them) with a configurable image identifying the bank account. The users of the bank account can choose an image from thousands of images and later make sure that when logging into their bank account - they enter their password only upon seeing the right image on the login page. The selection and delivery of the image happens over SSL (secured encrypted channel) and is account specific, making it hard for fraudulent sites to randomly guess the right image from the huge list for each account.
Great Idea. But does is actually work ?
Read the details about the Harvard/MIT joint study here -
Study Finds Web Anti-fraud Measure Ineffective
During the study, people simply ignored the image and continued to log into the (fraudulent) site. The study concludes that the idea of such image based authentication is flawed, and that such schemes are completely ineffective. This is not a valid conclusion.
The idea is great, but the implementation sucks. The login page of Bank of America is very badly designed from security perspective. The page is so cluttered with information (sometimes - ads, text and images) that the Harvard/MIT researchers were easily able to create a matching login page with missing SiteKey images, and people were not able to spot this critical difference.
The solution is to completely simplify the login page (look at Google to understand what is simplicity) so that users associate entering the passcode with the SiteKey image, and no text or graphics around the login page can distract their attention into believing anything otherwise while entering their passcode.
Conclusion: The implementation of a security solution is as important as the idea itself.
Vishal.
The key idea of the technology is that human beings remember pictures and images much better than text. As a result, the site complements the use of text based passwords (instead of eliminating them) with a configurable image identifying the bank account. The users of the bank account can choose an image from thousands of images and later make sure that when logging into their bank account - they enter their password only upon seeing the right image on the login page. The selection and delivery of the image happens over SSL (secured encrypted channel) and is account specific, making it hard for fraudulent sites to randomly guess the right image from the huge list for each account.
Great Idea. But does is actually work ?
Read the details about the Harvard/MIT joint study here -
Study Finds Web Anti-fraud Measure Ineffective
During the study, people simply ignored the image and continued to log into the (fraudulent) site. The study concludes that the idea of such image based authentication is flawed, and that such schemes are completely ineffective. This is not a valid conclusion.
The idea is great, but the implementation sucks. The login page of Bank of America is very badly designed from security perspective. The page is so cluttered with information (sometimes - ads, text and images) that the Harvard/MIT researchers were easily able to create a matching login page with missing SiteKey images, and people were not able to spot this critical difference.
The solution is to completely simplify the login page (look at Google to understand what is simplicity) so that users associate entering the passcode with the SiteKey image, and no text or graphics around the login page can distract their attention into believing anything otherwise while entering their passcode.
Conclusion: The implementation of a security solution is as important as the idea itself.
Vishal.
Friday, December 22, 2006
Sun releases Java sources
Sun has released the Java source codes for J2ME under the project code name phoneME.
This has been released under GPLv2. For the sources - Check out -
https://phoneme.dev.java.net/downloads_page.html
Vishal.
This has been released under GPLv2. For the sources - Check out -
https://phoneme.dev.java.net/downloads_page.html
Vishal.
Subscribe to:
Posts (Atom)