Technical Changes In Aptoide Accounts (RFC)

Cláudio Luís -

We, Aptoide, are reworking our authentication system into something new; in order to provide a far more secure way to protect all our users. Let us know what you think of these changes in this Request For Comments (RFC) post.

In this new system, no passwords will ever be used. This means that no passwords will be stored, reason being that passwords have many vulnerabilities to them – regardless of the used encryption and hashing algorithms.

Good passwords are hard to come up with and can be difficult to remember, and generally require a third-party application to help come up with them.

Instead, users will be able to use their email address only. Here's how it works:

  1. The user inputs the email address;
  2. A link or code is sent to the given email address;
  3. The user clicks on the received link or uses the received code in the Aptoide app authentication form;
  4. The user is now logged in.

There will be no difference between a login and a new registration since new accounts will be created seamlessly for new emails.

Authentication using a Google or Facebook account will also continue to be possible and work similarly as before.

No real names, birth dates or any other previously stored personal data will be stored anymore, except user data strictly used for authentication purposes in the future, namely the email address, which will be stored securely as follows:

  1. A salt will be generated as a SHA-256 HMAC from the email address with a secret key stored securely;
  2. A bcrypt hash will then be generated and stored from the SHA-256 hash of the email address with the salt above.

Hash Salt

As it is commonly known, when storing passwords securely, a salt is usually randomly generated and stored for each one individually. This is so that even if two or more users share the same password, they generate distinct unique hashes so they cannot be easily reversed using pre-computed hashes from known passwords (rainbow tables).

During authentication, the given password is then hashed using the previously generated random salt for that specific user. It is then compared against the password saved in the database, which must perfectly match in order to allow the login.

However, when storing user data securely –such as email addresses– this salt cannot be randomly generated. This is because the email address is used to identify the user during authentication and "who's" logging in, rather than "what" the user is logging in with.

Although a random salt is generally considered to be more secure than a non-random salt, the random salt is stored in clear text in the database, meaning that it is a known value that an attacker will have access to. The generation of a truly random value makes it unpredictable - it implies that it must be stored. This means that its randomness may also be used as a ‘weakness’ against brute-force attacks, which is then compensated by the hashing algorithm itself.

Therefore, by generating a non-random salt (using HMAC) over an email address with a secret key to keep the salt unique to each user –and then removing it from the final bcrypt hash to keep the salt unknown– we are able to ensure about the same level of security (or even more) than a random salt a password is generally given.

In order to revert a hash back to its original value (an email address), an attacker would have to brute-force their way into the salt first, then brute-force into the secret key used, and then generate email hashes to compare it with. In theory, this would require breaking bcrypt, SHA-256 and HMAC at the same time – which is currently impossible to do.

In essence, the only information kept in the database is the hashed email, as explained above, both for native or Facebook/Google logins.