FIDO / Fast Identity Online

 

Take a moment to consider the number of online accounts that you have. It does not matter whether they are social media accounts, news sites, blogs or enterprise accounts. The answer would be quite a lot. And that’s fairly common for anybody. Also it’s pretty safe to say that pretty much all these accounts are password protected. So any user at any given time is dealing with a lot of passwords and the complications associated with it. Such as while creating; specific character combinations, meeting minimum length restrictions, specific character properties like case sensitivity, maximum length restrictions, special characters, complexity, periodic changes(90 days etc) and many more.

Problems

Passwords are complex in maintaining and creating. But they are the best line of defence when it comes to secure data access. Since it’s easy to set up, it breeds a sense of complacency when it comes to security. Set a password once and we are done, right? But the truth is passwords need to be maintained consistently. With good and strong characteristics. Also passwords are susceptible to a wide variety of attacks. Brute Force, Phishing, Credential Stuffing etc. Survey after survey shows depressing statistics when it comes to password usage in the context of security. Consider this

https://services.google.com/fh/files/blogs/google_security_infographic.pdf

According to an online survey conducted by Google

52% of people reuse the same password for many (but not all) accounts

Only a minor 13% Use a different password for all accounts

A whooping 35% reuse the same password for all their accounts

https://digitalguardian.com/blog/uncovering-password-habits-are-users-password-security-habits-improving-infographic#:~:text=In%20fact%2C%20a%20Dashlane%20analysis,to%20a%20single%20email%20address.

A detailed survey conducted by digital guardian showed that

Only about 31.3% of respondents changed their passwords one to two times

Only about one-fifth (22.4%) changed their passwords more than five times per year

Almost half of the respondents, 49.3%, said they reuse passwords

https://dataprot.net/statistics/password-statistics/

In a survey conducted by Data prot,

53% of people rely on their memory to manage passwords.

51% of people use the same passwords for both work and personal accounts.

57% of people who have already been scammed in phishing attacks still haven’t changed their passwords.

Passwords are mostly in a “data at rest” state. Data or password which is stored or in the state of rest is not as vulnerable as data in transit over the network. But data in the state of rest is usually more critical.

Passwords or passcodes are as old as computing itself. MITs Compatible Time-Sharing System built way back in 1961, featured the first passcode. Computing has evolved from clunky, giant devices to nimble mobile devices. Password unfortunately has remained the same. Also, in the modern digital age with plenty of devices the problem of maintaining and managing many accounts and passwords. So why hasn’t the world moved on from passwords?

Two Factor authentication

To a large extent, 2FA or two factor authentication makes an account safer. By having another level of security to a user’s account risks are reduced. 2FA can be enabled in conjunction with passwords with

Something that a user knows — Password, PIN, Swipe gesture etc

Something that a user has — Mobile device, compatible security key etc

Something that a user is — Biometrics

2FA makes accounts secure. But 2FA is a bad experience from a user perspective. The time taken to authenticate is more with 2FA. and in certain cases, like loss, corruption of compatible devices, even more problematic. Ultimately 2FA is an “Extra” level of security on top of passwords. So the password problem is always there. It hasn’t gone away even with 2FA

FIDO Alliance

The problem is quite simply, how to get rid of passwords and in its place have a system which is more secure. How to change a timeless way of login i.e using passwords. That’s exactly what FIDO or Fast Identity Online seeks to achieve. FIDO Authentication aims to replace password-only logins.

Genesis

FIDO Alliance was founded by Industry leaders. PayPal, Lenovo, Nok Nok Labs, Validity Sensors, Infineon, and Agnitio etc. Other Tech Giants like Google, Paypal and Samsung also lent their support to the FIDO alliance later on. Thereby increasing its credibility. At its heart, FIDO uses the robust, proven technique of PKI or public key infrastructure. A public/private key is generated at the time of registration. The public key resides in the server and the private key never leaves the user. The data which is encrypted with a public key can only be decrypted with a private key

Passwordless and Multifactor : FIDO version one

The first FIDO standards, launched back in 2014 had two major components. The Universal Authentication Framework (UAF) and the Universal 2nd Factor (U2F).

UAF is the backbone for authentication by means of multi factor security. UAF enables the app or service to present different mechanisms for logging in. Such as fingerprint scan, face scan, voice recognition, PIN etc while registering. Instead of the usual id/password flow, users follow the authentication they chose while registering.

U2F as the name suggests deals with the standards associated with USB based physical security keys such as NFC and Bluetooth. These devices serve as the secondary factor for authentication or form the basis of 2 Factor authentication. 2AF is a familiar authentication technique. Similar to that FIDO too has a secondary factor authentication standard i.e U2F

So in other words UAF + U2F offers higher levels of authentication and security as in passwords, but without the hassles of passwords

Version FIDO 2

FIDO 2 was launched in 2018 and it was the updated and upgraded version of version one. FIDO 2 introduced Web Authentication (WebAuthn) in conjunction with the World Wide Web Consortium (W3C). FIDO 2 extends the power of UAF and U2F to third party apps and services. FIDO-based authentication is made available on supported browsers and platforms. By virtue of Web Authentication component, standards and web application programming interfaces (APIs). At the time of writing this, WebAuth is supported in pretty much all the major browsers like Chrome, Firefox, Edge and Safari

Conclusion

FIDO alliance or specifically WebAuthn is a win-win for all as there are tangible benefits to replacing passwords. WebAuth offers a good experience plus the security offered by having a password less, PKI based infrastructure. Service providers also don’t have to worry about the complexity of maintaining, developing and updating complex secure authentication solutions.

Source: FIDO / Fast Identity Online

Advanced testing strategy for apps - Security Checklist 1

Agile methodologies and DevOps are widely adopted by many software service providers and consulting companies. The primary driver for this adoption being, faster delivery of products, independent teams, and generally better all-around synergy between the engineering and operations team.

In this DevOps and Agile world, the traditional modes of quality assurance, like manual testing, are not as effective when it comes to quality assurance. Granted, risk analysis, test planning, and test management are still important, but to ensure the same level of quality in an Agile world as before, or even better, organizations are using new skills such as test automation, data analytics, and AI technologies amongst others.

In this two-part blog(IInd part coming soon), we provide an example of such an advanced testing strategy via a checklist for mobile app testing on the two most popular platforms, iOS and Android. We cover a wide spectrum of categories ranging from tests related to how and where to store data, testing the entire authentication flow, code quality, platform interaction scenarios, and many more. You can download the entire checklist here, or for a detailed explanation, read on.

1) Data storage and privacy

Mobile devices are a constant companion in the digital era. They are used for various purposes such as entertainment, work, personal, professional, etc. Users interact a lot with mobile devices and invariably enter or store details about themselves. Contacts, bank account, health information, habits and preferences, travel logs, etc. Hence it’s no surprise that the number one priority while testing is data storage and privacy, i.e., to ensure that the app does not “leak” any confidential information.

For Android

1. No Sensitive information is stored in AndroidManifest.xml file
2. No Sensitive information is stored in Gradle.properties file
3. No Sensitive information is stored in any strings.xml folders in apk package
4. [Shared Preferences Check] Install apk on Android phone (or emulator) and navigate to /data/data/<package-name>/shared-prefs/keys.xml. Verify no sensitive data is being stored there.
5. [SQLite Databases Check] Install apk on Android phone (or emulator) and navigate to /data/data/<package-name>/databases/. Verify no sensitive information is stored in sqlite dbs
6. [Encrypted Database] Install apk on android phone (or emulator) and navigate to /data/data/<package-name>/databases and verify databases which have sensitive data are encrypted.
7. Verify that debug logs are disabled on production build. Connect device to your machine , run the following command adb logcat | grep “$(adb shell ps | grep <package-name> | awk ‘{print $2}’)” and verify the logs when app is running
8. Verify input fields that ask for sensitive data for e.g. “Password” are masked
9. Verify input fields that ask for sensitive data for e.g. “Password” does not display auto suggestions by default.
10. Verify input fields that ask for sensitive data for e.g. “Password” , Cut, Copy, Paste options should not work on these fields
11. By Default Backups should be disabled. In Androidmanifest.xml, verify android:allowBackup is set as false.
12. If Backup is a requirement, then check that no sensitive data is backed up.

Then run a backup from adb, adb backup -apk -nosystem <package-name>

ADB should respond now with “Now unlock your device and confirm the backup operation” and you should be asked on the Android phone for a password. Approve the backup from your device by selecting the Back up my data option. After the backup process is finished, the file .ab will be in your working directory.

Run the following command to convert the

.ab file to tar. dd if=mybackup.ab bs=24 skip=1|openssl zlib -d > mybackup.tar

Analyse the backup and check if there is any sensitive data stored.

For iOS

Verify no sensitive data Is stored in App Bundles DB. Run a simulator build, and navigate to

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/var/mobile/Containers/Data/Application/$APP_ID/. read .db files

and verify no sensitive data is saved here.

Verify Keychain

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/data/Library/Keychains/keychain-2-debug.db.

Data stored here should be encrypted

Logs should not have any sensitive data.

Verify input fields that ask for sensitive data for

e.g. “Password” are masked

Verify input fields that ask for sensitive data for

e.g. “Password” does not display auto suggestions by default.

Verify input fields that ask for sensitive data for

e.g. “Password” , Cut, Copy, Paste options should not work on these fields

2) Cryptography Requirements

While it’s important to test if data is stored securely, it’s equally important to verify if data is stored securely, i.e., is it encrypted. This can be defined as “How is data stored” compared to testing “Where is data stored.” Confidential information like passwords, secret questions, and answers, keys should never be stored in a human-readable format. Both Android and iOS use the AES 256 Keys algorithm to encrypt confidential information, and app developers must leverage this.

For Android

1. Verify sensitive data is encrypted when stored in the device. Encryption keys used should be saved in Android. Keystore

For iOS

1. Verify sensitive data is encrypted when stored in the device. Encryption keys used should be saved in Secure Keychain

3) Authentication and Session Management

Apps usually have a sign in, signup, and authentication mechanism. Authentication identifies a user. Depending on authentication, certain resources are authorized. A user logs in, consumes services, and eventually logs out. This is known as a session. The critical thing in this flow is to ensure that the user is correctly authenticated most safely, and only those resources are allocated to him for which he is authorized.

For Android

1. Passwords should have a strong Password Policy. Comprising of Minimum password length should be 8 characters. Password should contain the combination of following characters as mentioned below

a. Lower Case (a-z)

b. Numeric (0–9)

c. Upper Case (A-Z)

d. Non-Alphanumeric (e.g.!, @, etc.)

2. If needed 2FA Authentication should be present

3. When a password is entered multiple times, then app lockout should be implemented

4. Session IDs are always exchanged over secure connections

(e.g. HTTPS).

5. Verify The server verifies the session whenever a user tries to access privileged application elements,

(a session ID must be valid and must correspond to the proper authorization level).

6. Verify The session is terminated on the server side and session information deleted within the mobile app after it times out or the user logs out.

For iOS

1. Verify no sensitive data Is stored in App Bundles DB. Run a simulator build, and navigate to

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/var/mobile/Containers/Data/Application/$APP_ID/. read .db files and verify no sensitive data is saved here.

2. Verify Keychain

/Library/Developer/CoreSimulator/Devices/<Simulator ID>/data/Library/Keychains/keychain-2-debug.db.

Data stored here should be encrypted

3. No sensitive data should be printed in Logs.

4. Verify input fields that ask for sensitive data for

e.g. “Password” are masked

5. Verify input fields that ask for sensitive data for

e.g. “Password” does not display auto suggestions by default.

6. Verify input fields that ask for sensitive data for

e.g. “Password” , Cut, Copy, Paste options should not work on these fields

Conclusion

This concludes the first part of this series, where we presented a checklist for testing mobile apps in the data storage & privacy category, cryptography requirements categories, and Authentication and session management category. In the next part, we will examine the test cases for the Network communications category, Platform Interaction, Code Quality and Build setting, and Resiliency category.