An alternative to hashing is to use and persist a secure random value.
You can use SecureRandom, if you seed it well, or you can use /dev/
random. I don't know the quality of the Android implementation of /dev/
random, but given its ancestry, I'd expect it to be reasonably strong.
You're not looking to defend against an attack, just avoid collision.
Or at least, you should be defending against attack with more than a
static identity token.

Another approach is to use a public key/private key pair, rather than
an explicit unique ID. You package up the public key as a X509 cert,
and pass it as your identification. You prove your identity by
encrypting a unique challenge with your private key, which can then be
decrypted with the public key and verified.

Physical access to the device will negate any security. An advantage
of a certificate-based system is that there's support available for
revocation lists, allowing you to revoke any certs you believe may
have been compromised. They also have expiration dates, so you can
require periodic replacement. If you're going to do that and maintain
stable identity, then you either need to track the certs on the other
side, or couple it with a secure random identity token.

If you require a strong password (or other strong second factor) in
addition to these tokens, and prompt for it as part of producing a new
certificate, you can limit the lifetime of any clone of your device.
(Or at least ones that don't involve the cooperation of the keeper of
the password).

Contrast these approaches to ANDROID_ID or the IMEI, which are fixed,
static values, fairly easily copied.


On Mar 15, 8:55 am, Guillaume Perrot <guillaume.p...@gmail.com> wrote:
> I guess we'll have to use some hashing technique of many values like
> explained on another thread, but I don't like this solution...
> Thanks for the answer anyway.
>
> 2010/3/15 Mark Murphy <mmur...@commonsware.com>
>
>
>
> > Guillaume Perrot wrote:
> > > In my job, I have to use a unique device ID that is not the IMEI or any
> > > other info provided by the TelephonyManager (for some privacy reasons)
> > > so I would like to rely on ANDROID_ID.
> > > But people I work for don't trust the ANDROID_ID because they don't know
> > > exactly what it is and we don't have the guarantee that it's globally
> > > unique (since this is set only by device manufacturers' will).
> > > Anyone have any idea on how these IDs are built ? I need more info to
> > > convince them to use that damn id...
>
> > Bear in mind that this ID is stored in a SQLite database and can be
> > modified on rooted phones.
>
> > Also bear in mind that there is only modest coordination on ANDROID_ID.
> > For example, ARCHOS shipped their first Internet table where the
> > ANDROID_ID value did not correspond to the API documentation (wasn't a
> > hex string). This may be because they do not have the Android Market,
> > and so get to invent their own strings. Reputedly, the ANDROID_ID value
> > comes from the Market on first use.
>
> > ANDROID_ID is fine for casual use, but it's not exactly the Rock of
> > Gibraltar, if you know what I mean.
>
> > --
> > Mark Murphy (a Commons Guy)
> >http://commonsware.com|http://twitter.com/commonsguy
>
> > _Beginning Android_ from Apress Now Available!
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs 
> > cr...@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to