Information Security Blog

Apple kicks Java out of browsers in OS X update

I actually support this. With more and more web applications making use of HTML5 and other new technologies like WebSockets etc, it makes sense to reduce attack surface by removing Java which is known to have bad history of security issues. 

Similarly, I will support removing Flash altogether from browsers

1 year ago - 1 -

: PayPal Bug Bounty - a lesson in not being a fuckup.

l8security:

PayPal started their bug bounty program on June 21st 2012. When I saw that, I decided that the race was on. A new market place had opened, and I was going to get in on it. I had my first opportunity to take my first shots at finding a flaw on June 29th. On first thought, I assumed that a company…

(via l8security-deactivated20130523)

1 year ago - 15 -
Identity management (usual xkcd goodness) 

Identity management (usual xkcd goodness) 

Did you back up?

Did you back up?

Inappropriate Use of Adobe Code Signing Certificate « Adobe Secure Software Engineering Team (ASSET) Blog

It is rather rare for Adobe to provide such insights into a breach. I am glad they are improving on their security communications. 

1 year ago -

phpMyAdmin backdoor on SourceForge mirror server.

I wonder why detecting these kind of issues isn’t automated? A simple md5/sha check every X hour should be able to detect if mirrors are serving the same file as intended. 

1 year ago -

Windows vs MAC security

1 year ago -

Password Hashing Salt- Should It Be Random?

Recently I had a discussion on whether password hashes salted with random bits are more secure than the one salted with guessable or known bits. Let’s see:

If the system storing password is compromised as well as the system which stores the salt, the attacker will have access to hash as well as salt, so whether the salt is random or not, doesn’t matter. The attacker can generate pre-computed rainbow tables to crack the hash. Here comes the interesting part- it is not so trivial to generate pre-computed tables. Let us take example of WPA security model. The WPA password is actually never sent to Wireless Access Point. Instead, it is hashed with your SSID (the network name- like Linksys, Dlink etc). A very good explanation of how this works is here. In order to retrieve password from hash, you will need to know the password as well as salt (network name). Church of Wifi has already pre-computed hash tables which has top 1000 SSIDs and about 1 million passwords. The size is of all tables is about 40 GB. As you can read on their site, someone used 15 FGPA arrays for 3 days to generate  these tables.

Assuming victim is using the SSID as “a387csf3” and password as “123456”, will it be cracked by those tables? No, it cannot. Even if the password is weak, the tables don’t have hashes for SSID a387csf3.  This is the benefit of having random salt. It will deter crackers who thrive upon pre-computed tables. Can it stop a determined hacker? Probably not. But using random salts does provide additional layer of defense.

While we are on this topic, let us discuss additional advantage of storingrandom salts on a separate system.

Scenario #1 : Password hashes are stored on system X and salt values used for hashing are stored on system Y. These salt values are guessable or known (e.g. username)

Scenario#2 : Password hashes are stored on system X and salt values used for hashing are stored on system Y. These salt values are random.

In case system X has been compromised, as you can guess, there is a huge advantage of using random salt on a separate system (Scenario #2) . The attacker will need to guess addition values to be able to crack hashes. If a 32 bit salt is used, 2^32= 4,294,967,296 (about 4.2 billion) iterations will be required for each salted password.

Hope you find this post useful, I truly appreciate your comments/feedback. Thanks!