---------- Forwarded message ---------- From: Kevin Veroneau <[email protected]> Date: Sat, Oct 22, 2011 at 1:27 PM Subject: Re: [android-security-discuss] Re: NTT Docomo (Japanese mobile career0 send IMEI always in video/audio player. To: Chris Palmer <[email protected]>
Salt would be added obviously as with most hashing, the secret salt(which should be very complex) would be appended to both sides of the IMEI halves, or for example: last IMEI half+complex salt+first IMEI half. The salt can either be a static application salt(such as what some web app frameworks like django do), or built from the user's name/information. Salt is must when using hashes, or yes, it will make the hash rather easy to reverse. For a even more complex hash: salt1+last IMEI half+salt2+first IMEI half+salt3. If these salts are at least 256 bits, it will increase the security by a large number. I'd like someone to try cracking a random string from /dev/urandom combined with the IMEI. All in all, the person doing the brute force attack will need to know how it was hashed in the first place, and there are many ways to add to salt to a hash, be creative. :) On Sat, Oct 22, 2011 at 12:12 PM, Chris Palmer <[email protected]>wrote: > On Oct 22, 2011, at 6:36 AM, Kevin Veroneau wrote: > > > Wouldn't it be more secure if they hashed the imei before placing it into > the header? This way a unique hash can be used as an authentication key. > Hashes are more difficult to match. Or to make it more difficult, slit the > imei into 2, hash both parts, and combine them together in the same string. > An md5 hash for example is 33 bytes long, if using that method, the > app/site would send a long 66 byte hashed imei to the server to uniquely > identify itself. If I built an android app, I'd use this method to secure > each apps license and in-app purchases. > > An MD5 is 128 bits, or 16 bytes. When represented in hexadecimal, it is 32 > characters. > > "Reversing" a hash is never more difficult than brute-force guessing the > space of the inputs. For example, if you know the input was a 5-letter > English word, guessing that the input that resulted in > 5d41402abc4b2a76b9719d911017c592 was "hello" is very easy. > > That is why hashing IMEIs is a terrible way to make an authenticator, and > it is also useless for obscuring the IMEI. IEMIs are structured, > low-complexity strings. > > Worse, when you split them in half, they are even shorter, even > lower-complexity. Splitting an input and hashing each half of the input is a > classic weakness: > > http://en.wikipedia.org/wiki/LM_hash#Security_weaknesses > > Say we use a new-style 16-digit IMEI. The complexity of that space should > be 10^16; due to the structure of IMEIs it is actually way, way less than > that. > > But even if IMEIs were completely random and unstructured, your scheme is > trivially reversible. When you split the IMEI in half, the complexity is > 10^8 (so low as to be trivially brute-forceable). 10^8 + 10^8 is, alas, > nowhere near 10^16. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
