Saturday, January 08, 2011

UnixCrypt produces same values for different passwords

This is interesting. Learnt something new today.

I've been using the UnixCrypt class from Jetty and if the first eight characters of the password to be encrypted are the same for two passwords, the resulting encrypted (hashed) value is the same.

I was trying to reproduce an error message in my program by providing the wrong password and creating the wrong password by simply modifying the last character of the password. However, inspite of supplying the wrong password, the system was successfully authenticating.

The problem was that two different passwords like John1234$ and John1234b#, were producing the same value from UnixCrypt which was leading the system to think that it was the correct password. BTW, notice that one could potentially call these passwords quite strong given they have an Uppercase, lowercase, numbers, a special character and are greater than 8 characters.

The only way to get different values is to use completely different salts. But even there is a catch. Salts like '12abc$1' and '12gfd#2345' though completely different, produce the same value.

I've been using the class as part of a program that saves passwords and was using a salt of format - "constant + random". This was resulting in same value even though the salt was technically different. Here is a test program and the resulting output - (some boilerplate code omitted for brevity)

Code

String password = "John1234$";

String salt = "12abc$1";

String val = UnixCrypt.crypt(password,salt);

System.out.println("(" + password + "," + salt + ")" + " = " + val);

password = "John1234b#";

salt = "12gfd#2345";

val = UnixCrypt.crypt(password, salt);

System.out.println("(" + password + "," + salt + ")" + " = " + val);


Output

(John1234$,12abc$1) = 12FH7.yEd/XWI

(John1234b#,12gfd#2345) = 12FH7.yEd/XWI


Why is this happening even when the salts are completely different? The problem is again the prefix. Looks like if the first two characters of the salt are same, the same value is produced. Simply altering the second character of the salts, '12abc$1' and '13gfd#2345' , results in different values.

New Output with second character of the salt changed -

(John1234$,12abc$1) = 12FH7.yEd/XWI

(John1234b#,13gfd#2345) = 13uN.eBnCs5io



Ideally, the salts should be dynamically generated. However, even if that is done, likelihood of a collision is quite high due to the small size of the salt prefix.

At this point the only certain way around that I can think of is to ensure that two passwords don't have the same first 8 characters.

When I get time it will be good to look into why this is happening. A little bit of browsing around the web told me that this might have something to do with the MD5 hashing algo but that is an exploration for another day.

Thursday, January 06, 2011

How about a Java app store?

Thought Process


The Apple Mac store is a very interesting development. Apple is trying to bring the iPhone like experience to the Mac - the traditional "desktop".


One of my iOS apps has a desktop component and it got me thinking that if I had to make the desktop component available in the Mac App store it would need to be re-coded in Objective C and Cocoa and then again in .NET for Windows. Based on the downloads, my audience for the desktop app is about evenly split between the two platforms - OSX and Windows. That makes it impossible for me to ignore either of the platforms.


Right now the app is an Eclipse-based RCP app, which solves my issue of coding for multiple platforms - OSX and Windows. I write the code once and just create two native builds. Being a stripped down RCP app with minimal plugins and inspite of being a Java app, I think it performs quite well on the desktop.


My next thought was that it would have been great if there was an consumer focussed "App-store" for Java apps that brought the same experience the iOS devices bring to mobile. Java does take the pain out of coding the app logic twice. While there are some compatibility issues, it cannot be as bad as writing code twice and trying to ensure coherency in the logic between two lines of code.


What is required?


A thin operating layer on the desktop that simply provided access to the lower filesystem, provided a security sandbox and allowed for extensions.


Here are some of the characteristics that I can think of -

  • An "App Store" app to find apps natively from within the desktop and do a one-click install.
  • Standard features in App Stores - ability to rate and review, feature, popular, ….
  • Ability to view all running apps, switch between them, kill them, …
  • Support for different kinds of apps types - widgets, full-blown apps, …
  • Preferably a unified app store instead of the user having to search multiple sources (i.e. preferably the iPhone experience vs Android experience)
  • Integrated eCommerce to sell apps and their features - An idea would be to integrate the plugin store with providers like PayPal, who have already solved this issue. Making a user go to multiple sites to make payments would not be a good experience. This is something Apple does well with iTunes - they make it easy to buy and install something immediately. Amazon does this well for various sellers on the web.
  • Other good features would be - in-App purchasing APIs, recurring payments, app sandboxing.
  • Developer guidelines with a focus on user experience and good looking apps.


How to set this up?


Make it Eclipse-based or Eclipse-like or OSGI-based

Eclipse already has a few good things going for it

- A solid plugin model. Plugins would be similar to Apps

- A fairly decent update mechanism

- There is already an Eclipse Marketplace. However, it is too IDE and developer focussed (it prompts to login with my "Bugzilla" ID :))


However, other than the IDE, Eclipse does not have a killer app that users will want to download and install on their desktops. The IDE is certainly not a killer app for consumers. Thus, Eclipse will need a killer app that will put the App control layer and marketplace apps on a users desktop.


Use JRE to distribute this Eclipse-based control layer and marketplace app

Integrate this operating app and the marketplace store app inside the JRE itself. With every download of JRE, users also get the ability to extend their JRE experience with plugins. However, the UI component will need to be SWT-based and not Swing based. Eclipse, in my opinion owes a lot of its success to SWT and JFace. There were free IDEs before Eclipse but reason I (and probably a lot of people) switched to it was due to its native look n feel and performance.


Who could make this happen?

Probably Oracle in cooperation with other Java supporters such as IBM, Google, Eclipse ...


In Summary


- Great to have a Java-based consumer focussed app store platform

- Borrow features from mobile devices such as sandboxing, integrated eCommerce.

- Eclipse-like plugin model except absolutely no IDE components

- Integrated with the JRE download


  DB Reading BASE: An Acid Alternative: In partitioned databases, trading some consistency for availability can lead to dramatic improvement...