Securing User Credentials On Mobile Devices

Cross-posted from the McAfee Security Connected blog

Your mobile device is an interface into systems that can store potentially sensitive information about you, your company or your employer.  Given its ease of use and portability, one would expect to find unique, strong credentials to guard against unauthorized access to these resources.  In practice, however, credentials tend to be reused – increasing the odds of account compromise.  According to a University of Cambridge survey, more than 45% of the users surveyed chose to use the same password for multiple web sites.

OWASP cites credential harvesting as a major threat to web application users, including those with mobile interfaces.  The use of Spyware, malware, User Interface impersonation attacks are among the tools used by miscreants to gather user name and passwords.  According to a Trusteer study, nearly 50% of phishing victims revealed their credentials to one site within an hour of receiving the attacker’s email.  Of the passwords gathered, over 75% were used on more than one web site.

The controls discussed in this article reduce the risk of credential harvesting via application reverse engineering and signal sniffing.  However, they do nothing to enforce proper password composition, frequency of change, and distribution of use.  OWASP recommends that unique, complex passwords be used for each resource being accessed with a mobile device.

Authorization Tokens

OWASP recommends the use of authorization tokens as an alternative to passwords.  These tokens are associated with a user and eliminate the need for credentials to be transmitted when authenticating to a server.  Encryption of these tokens is recommended both at rest and in transit, minimizing the risk of meaningful information retrieval if the tokens are intercepted.

Token implementation will vary depending on the requirements of the service or the mobile connectivity management solution.  For example, a service could issue an authorization token after verifying the user’s credentials.  The tokens and service could also be bound for a specific period of time, preventing a persistent connection from which session information may be sniffed.

Regardless of implementation strategy, OWASP recommends that the latest version of an authorization standard such as OAuth be used.  Additionally, tokens should remain active after a session is terminated.  Such sessions may be targets for harvesting.  All tokens should be set to expire after a delay appropriate to the classification of the service or application.  For example, the expiration delay may be longer for Facebook than with a financial application.

Password Encryption

There are valid business use-cases wherein authorization tokens are not ideal.  Strong encryption such as AES should be used to ensure the confidentiality of user credentials.  OWASP also recommends that long-term session IDs be encrypted if they are to be stored on a mobile device.  Cryptographic hashes should also be used to detect unauthorized changes to user credentials.

Keep credentials and application binaries separate

From a purely developmental standpoint, it seems expedient to hard-code credentials into application binaries.  However, few programmers are aware of how the password policy will affect their development requirements.  This policy requires that passwords be changed regularly, requiring the recompilation of all applications with hard-coded credentials.  Additionally, Change Management procedures would impact the speed at which the updated applications could be pushed to staff members.

OWASP recommends that encrypted credentials be passed to an application securely.  This eliminates the need to redeploy applications whenever a password is changed.  This practice also prevents attackers from extracting hard-coded credentials via reverse engineering.

Secure Element Chips

Some mobile devices implement tamper proof smart cards that contain chips called Secure Elements to store credentials securely.  These chips are accessible only by applications possessing specific cryptographic signatures. Google Wallet is an example of this solution, allowing a person to use their mobile device to make payments at specially configured Point of Service devices.  OWASP expects this technology to be implemented increasingly due to the security services it offers.

The next installment of this series will explore controls designed to secure data in transit.  The discussion will include the selection of SSL vs. TLS, the use of SSL proxy and SSL strip countermeasures to mitigate man-in-the-middle attacks, and the use of forged certificates to gain access to data. Until then, be sure to follow us on @McAfeeBusiness for regular updates on McAfee happenings and news.