Sam Granger posted last week that WhasApp, a popular and free smartphone messenger app, used the phone’s IMEI number as a password (more specifically, the app uses the phone’s IMEI inverse and unsalted MD5 hashing). An update to the post shows that WhatsApp’s developers are tinkering with the security, so I expect that better protection will be incorporated. When one thinks of BYOD security, one generally doesn’t expect to philosophize on the state of an app’s inner workings.
The Story So Far
WhatsApp is a smartphone application. According to their iTunes download page, it is “a cross-platform smartphone messenger currently available for iPhone and all other smartphones. The application utilizes push notifications … Switch from SMS to exchange messages, pictures, audio notes and video messages.”
I’ve never used the app, but it sounds a lot like a popular messaging app in Korea, KakaoTalk, which has its own privacy problems.
What Sam Granger has found is that,
If you installed WhatsApp on an Android device for example, your password is likely to be an inverse of your phones IMEI number with an MD5 cryptographic hash thrown on top of it (without salt). [samgranger.com]
A commentator on the same blog noted that,
WhatsApp is a no-configuration app, so they need to use something that any app can have access to as authentication.
Kind of makes sense, if you think about it. If you don’t have to configure the app for use, then some form of identifier has to be used to ensure that messages reach the intended destination. Many apps in the Apple iOS environment used to use (and still do) UDIDs, but their use are being phased out by Apple; in fact, they banned their use not too long ago. I guess an IMEI number could work in a pinch, since it’s a phone’s unique identifier.
The problem is that that particular piece of information can be used as a vector for further attacks. Granger notes some ways the information could be used to upend one’s life.
What’s with the Unsalted Hashing? Plus, Flashes of SSN Abuse
Honestly, what’s with the unsalted hashing? I mean, granted that the use of MD5 hashing doesn’t really represent security anymore. This is especially true when you consider that IMEI numbers are fixed in length, so it wouldn’t be too big a chore for a hacker to run a full set of 14 or 16 digit numbers and compute their hashed equivalent.
(The concept of security as it pertains to hashing is that different inputs will not result in the same output, and that it’s impossible to figure out the input from the output. That’s why hackers spend a lot of time creating rainbow tables, databases with a list of inputs and their corresponding outputs. If you can find the hashed result on the rainbow table, you know what the input was, be it a password or an IMEI number. Because the exercise is computationally expensive, hashes used to provide mediocre to adequate security. However, security is severely hamstringed if hackers know they’re looking for a particular input, such as a 14-digit number: they know they don’t have to check for 15-digit numbers or 13-digit numbers, allowing them to look in a smaller pool of possibilities).
You know, this story reminds me of the problems the US is facing with the use of forged SSNs. Social Security numbers were never meant to be used as identifiers. Regardless, it was a convenient way of keeping track of individuals in a country without a universal identifier. Today, it’s kind of hard to live in the US without one. But, because SSNs were never designed as identifiers, it’s proving to be problematic to fraud, forgery, etc.
It seems the problem is also spreading, if you take into account the problems associated with UDIDs and IMEIs. There’s a lesson to be learned somewhere in there.
Related Articles and Sites: