How to Enable Sign-in With iOS Biometric Authentication

When developing a CloudEver app, I learned about iOS biometric authentication technologies, including Face ID and Touch ID. Then, I reviewed some apps with fingerprint sign-in features and found that many of them did not fully take advantages of iOS security capabilities. I would like to share my knowledge I've gained with the community, and I hope that the apps we use will be more and more secure.

Why Do We Need Authentication?

Most of the early Internet services mainly provided static content for everyone without login. Later, there were some dynamic services, such as forums, chat rooms, and so on. At that time, passwords were required for identity authentication. Since then, password authentication have been widely adopted by many Internet services.

You may also like: Authentication and Authorization: Mastering Security.

Security Issues of Password Authentication

However, it is not easy to ensure the security of password authentication. If username and password are cracked by others, it may disclose user information or even result in money loss. So, what are common mistakes of implementing password authentication?

1. Use HTTP Instead of HTTPS for Password Authentication

In the past, some well-known Internet companies designed their own methods to encrypt passwords in the browser. They then submitted them to their servers for authentication over HTTP. Later, they found that this was wrong. Now, almost all big companies have switched to HTTPS.

We must use HTTPS to authenticate username and password.

2. Use HTTPS for Password Authentication, but Show the Sign-In Box Over HTTP

Some developers believe that username and password will not be disclosed as long as they're transported over HTTPS. So, they serve the sign-in page over HTTP to save server resources. However, that is a very common mistake. Hackers may embed malicious JavaScript into the sign-in page over HTTP, i.e. MITM JavaScript injection. The username and password may be collected by the malicious JavaScript code.

From Comcast still uses MITM javascript injection to serve unwanted ads and messages

The sign-in box must be served over HTTPS

3. Username Does Not Exist

I found that when logging in to some websites, there are two different error messages for non-exist username and incorrect passwords. Is there any problem with this?

Definitely! After knowing that username exists in this way, the hacker just needs to crack the password. In this breach-of-billions world, our mobile phone number and email address are free of any secret.

4. Store Passwords in Plain Text

How do developers store user passwords? Yep, some just insert it into their database. Many inexperienced developers usually save user information into the database without a second thought when building a website and then use SQL to authenticate user password.

So easy, but so insecure!

Keeping passwords in plain text means that:

• Developers, operations engineers, and even other staff of the company can directly access user password!
• Hackers get to know the passwords of massive when there is a data breach.
• All accounts of users who reuse passwords in different platforms are also in danger!

5. Store Passwords in a Hash

Some developers believe that one-way hash is a good method for encrypting passwords and hackers cannot restore the original password. That is a wrong idea. Although the secure hash algorithm is irreversible, PASSWORD HASH IS REVERSIBLE.

This is because hash algorithms, such as MD5, SHA1, always calculate the same result for the same password. Take a look at the “MySQL.users” table; are hashes the same for the same passwords?

You may or may not know, but there are some people who are calculating all the password hashes and put them on the Internet for free downloading. Up to now, the passwords of all alphanumeric combinations within 9 symbols have been calculated, for a total of 1TB of data. So, how many symbols does your password have?

Maybe you will think that it is not easy to find the password by the hash within such a huge database. You are correct when there is no such rainbow table technique.

6. Hash Combination

If one hash does not work, how about hash combinations?

• md5(sha1(password)).
• sha1(sha1(password)).
• md5(sha1(md5(md5(password) + sha1(password)) + md5(password))).

Don’t do that. Actually, hash combinations usually make the password weaker, not stronger. For example, combining MD5 which has been proven to be unsafe with SHA1 which is relatively safer, might be less secure than SHA1 only.

7. The Correct Way to Store Passwords

So, what is the right way to store passwords?

Hashing with salt. Add salt into the password first, then calculate the hash. This is a sample code.

First, generate a secure random salt, then calculate the hash of  salt+password, and finally save the salt and hash. Yes, the salt is stored in plain text with the hash.

When authenticating a user, we get the salt and calculate the hash in the same way, and then compare the result with the hash stored in the database.

But, is this secure? Still no, if you do it improperly. There are some common mistakes,

1. Reuse the salt: Write a random number in the program as a salt to unload the burden of reading database. This does not work as a salt! Same passwords still share the same hash. Not only each user must have a unique salt, but also each time a user resets his/her password, the salt must be regenerated.

2. Use a short salt: Let’s think like this. If the salt has only one bit, the calculated hash will only have 2 possible results. If the salt has two bits, there are four possible results. That means, the longer the salt is, the more secure the hash will be.
   
   Nowadays, the rainbow table has been calculated to 10-symbol passwords. It is recommended that salt should be at least 128 and 256 bits long. Does that mean 1024 bit will much better? Not really. Because the hash of SHA256 is only 256 bits. The salt does not need to be longer than the hash.

8. To Be Much More Secure

If you don’t mind consuming more CPU/memory on authenticating passwords, you can replace the normal hash function with a very resource-consuming hash algorithm, such as PDKDF2, bcrypt, etc. It will cost much more to crack a password hased by those algorithms.

9. Dealing With “Password Reuse Attack” and Weak Passwords?

From https://www.thesun.co.uk/tech/7978489/worst-passwords-most-common-2018/

The general solution for “password reuse attack” is 2FA, such as SMS verification code, email verification code, and TOTP (time-based one-time password). But techniques like cell phone number cloning, cracking email accounts, etc. have also developed, and TOTP cannot prevent data breaches by hackers or employee theft. Phishing attacks have proven to be able to break the protection of Google’s 2FA.

Passwords Are not the Source for Authentication

For a long time, Internet services have adopted password authentication. Many people know that the password is not secure for authentication, but don’t know that it is not the only way.

Public Key Authentication

Backend developers and Github users usually use SSH keys to sign in to the server or update the code, which is very convenient and secure.

If you still use a password to login Linux server, you should switch to SSH key. We turned off password authentication on all Linux servers and used keys only in my previous company.

In short, it takes the advantages of the public key algorithm.

1. Put a user’s public key on the server.

2. When logging in, the user uses his private key to encrypt (or sign) a random piece of data.

3. The server decrypts the data (or verify the signature) with the user’s public key and checks whether the decrypted result matches.

Public key authentication has a great advantage over password authentication and TOTP. Even if hackers dump the database, they can only obtain the public keys which can only be used to authenticate users, not for sign-in, but cannot use them to sign in or attack other platforms sharing the same password.

Login Authentication of iOS Apps

One of the biggest advantages of iPhone is its security. The App sandbox mechanism ensures that the data stored internally is also secure.

From https://www.cse.wustl.edu/~jain/cse571-14/ftp/ios_security/index.html.

Therefore, many app developers use UserDefaults to save the password in plain text in the Preferences plist file, or simply write in a file.

There are two security issues to be aware of:

1. iPhone or iOS is just more but not always secure. Many users still use the old iOS, which may have many security vulnerabilities. A few years ago, the FBI cracked iPhone 5C of a terrorist by utilizing a vulnerability in iOS 9.

2. The files stored in the iOS app are automatically backed up via iCloud by default. The iCloud service does not have a good history of security. We read news about iCloud data breaches every year. So, sensitive files must be prohibited from backing up by the

The Correct Way to Store Passwords on iOS

If you want to store sensitive information like passwords, you should use Keychain Services for iOS. Keychain Services for iOS is different from the iCloud keychain. The former is a service that stores important data for apps and does not synchronize via iCloud. The latter is a feature that iCloud provides to apple users. People may get confused due to the similar names.

Like SQL, you need to create a Query first and then call the API, which is not complicated by Ctrl-C and Ctrl-V.

iOS Biometric Authentication

The iPhone 5S launched in 2013 supports fingerprint payment, which implements a much higher security standard of biometric authentication. The following is the iPhone security architecture from Apple.

When using Touch ID for authentication, the Touch ID sensor scans the fingerprint and sends the image data to Secure Enclave for authentication directly without sending through the iOS operating system. Then, Secure Enclave sends the authentication result to the app via the iOS operating system.

During the entire process, fingerprint data is transmitted directly to the Secure Enclave in the connected hardware circuit. So, it is impossible for the app to obtain fingerprint data. Face ID works like this too, except that it scans the 3D data of face.

In addition, in order to improve the security of iPhone, Apple pairs the fingerprint sensor chip with the security chip inside the iPhone in the production process to ensure that it’s impossible to access data in the Secure Enclave by replacing fingerprint sensor chip. The replaced Home button cannot be paired with the original Secure Enclave. Because of this pairing, Touch ID might be unavailable on some second-hand iPhones.

Biometric Authentication Login

Secure Enclave for iOS can securely create a key pair and uses a private key to sign the data. The private key created by Secure Enclave is only stored inside, and no program is allowed to read it.

So how do we use the hardware public key feature of iOS to achieve secure login?

Sign Up Process

When the app asks Secure Enclave to create a key pair, iOS prompts the user for authorization. The user can authorize by Touch ID or Face ID authentication. Then, the app sends the public key to the server. The private key is stored inside the Secure Enclave and cannot be obtained by the app.

Sign In Process

Sign-in is simple. When a user touches the Sign-in button, the app asks Secure Enclave to create a signature for the sign-in request and iOS prompts for authorization. Once the user confirms the authorization, the signature is sent to the app. Then, the app sends it along with the sign-in request to the server for authentication.

Sign-in With Biometric Authentication Advantages

If the app takes full advantage of the security capabilities of iOS, it is more secure to create a signature with the private key in Secure Enclave by biometric authentication locally and then verify the signature with public key remotely, compared with using the password stored in Keychain Services.

1. The private key is only stored inside Secure Enclave and never exposed to the app or even iOS. That means, even if the app has vulnerabilities or the iOS sandbox is broken, hackers still cannot get the private key to steal user identity. In contrast, password saved in Keychain Services is vulnerable when the app or iOS is compromised.

2. If the server side gets hacked, the user identity is still safe with public key authentication, while not only the user identity of this app/service is unsafe with password authentication, but also user identities on other platforms sharing the same password are all in danger too.

Some apps can enable fingerprint sign-in without prompting for user authorization. So, obviously, they do not utilize the iPhone’s powerful hardware signature feature.

The Security of Secure Enclave

Secure Enclave is probably the safest technology available today, but it is not 100%. In fact, Apple reserves the ability to read data from Secure Enclave, and they can also modify the OS in Secure Enclave via system updates.

Further Reading

• TLS Security: TLS/SSL Explained.