Smartphone unique identifiers as password/login credentials?

Question

My intent

1. App allows only one account per smartphone (like Telegram/Whatsapp)
2. Smartphone unique identifiers act together as password/login credentials and ensure point 1.
3. Token-based login returns a 48h valid token, so that the login procedure doesn't eat too much server-side resources

Research so far

The popular posts about android unique identifiers here on SO already suggest, what identifiers to use.

Searching for 'passwordless login' leads to results but they have nothing to do with the way I want to do the account creation. The only topics I found of 'using smartphone as login credentials' just wrote about benefits and what ways/field of application are possible. Like using NFC to get authorization to enter a building.

Solution so far

• Storing the 4 unique identifiers build-serial, android_ID, SIM-serial and IMEI as salted hash in the database. On login the smartphone sends its identifiers and they are matched against the ones in the DB.

• Recovery option: email address

  +-----------------+------------+------------+----------------+------------+--------------+------------+----------+
  | INT unsigned AI | BINARY(16) | CHAR(255)  |   CHAR(255)    |  CHAR(20)  |   CHAR(20)   |  CHAR(20)  | CHAR(20) |
  +-----------------+------------+------------+----------------+------------+--------------+------------+----------+
  | player_id       | uuid       | playername | recovery_email | android_id | build_serial | sim_serial | imei     |
  +-----------------+------------+------------+----------------+------------+--------------+------------+----------+

  +-----------+--------------------------------------+------------+-----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
  | player_id |                 uuid                 | playername | recovery_email  |            android_id            |           build_serial           |            sim_serial            |               imei               |
  +-----------+--------------------------------------+------------+-----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
  |         1 | 6ccd780c-baba-1026-9564-0040f4311e29 | player1    | test@localhost  | dac9630aec642a428cd73f4be0a03569 | 7f40fb99caa4c44238514f645827448d | d41d8cd98f00b204e9800998ecf8427e | e4d909c290d0fb1ca068ffaddf22cbd0 |
  |         2 | 865234ad-6a92-11e7-8846-b05adad3f0ae | tester     | test2@localhost | e4d909c290d0fb1ca068ffaddf22cbd0 | d41d8cd98f00b204e9800998ecf8427e | 79054025255fb1a26e4bc422aef54eb4 | dac9630aec642a428cd73f4be0a03569 |
  +-----------+--------------------------------------+------------+-----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+

Problem

If someone disassembling/reverse engineering the app, building a desktop application simulator with the extracted client certificate (PKCS#12 file in the app), because server requires valid client cert, he can register accounts by making the smartphone unique identifier data up.

Questions

1. Since saving the already unique identifiers in cleartext is not an option, because it's sensitive userdata, does hashing them don't rise the danger of hash-collisions? Although the 4 unique values together create a new unique one, even if sometimes one or two of the values are identical to the ones in other records. So concerns about this are negligible small?
2. The problem prevents my intent of only 1 account per smartphone. Therefore, do I have no other choice as tie the account to the phone number and require a verification through SMS?
3. Other ways? (like only generate a unique password from the 4 unique identifiers?)
4. Still going for considered broken salty MD5 hash function? And if, are 20 chars sufficient, because of the 4 unique values aren't any longer, or should I go for the full 32 chars?
5. Does this approach can work with a token-based login?
6. Am I overlook something? Any further security aspects?