What is credentials in android

Keys, Credentials and Storage on Android

In the previous post on Android user data security, we looked at encrypting data via a user-supplied passcode. This tutorial will shift the focus to credential and key storage. I’ll begin by introducing account credentials and end with an example of protecting data using the KeyStore.

Often, when working with a third-party service, there will be some form of authentication required. This may be as simple as a /login endpoint that accepts a username and password.

It would seem at first that a simple solution is to build a UI that asks the user to log in, and then capture and store their login credentials. However, this isn’t the best practice because our app shouldn’t need to know the credentials for a third-party account. Instead, we can use the Account Manager, which delegates handling that sensitive information for us.

Account Manager

The Account Manager is a centralized helper for user account credentials so that your app does not have to deal with passwords directly. It often provides a token in place of the real username and password that can be used to make authenticated requests to a service. An example is when requesting an OAuth2 token.

Sometimes, all the required information is already stored on the device, and other times the Account Manager will need to call a server for a refreshed token. You may have seen the Accounts section in your device’s Settings for various apps. We can get that list of available accounts like this:

The code will require the android.permission.GET_ACCOUNTS permission. If you’re looking for a specific account, you can find it like this:

Once you have the account, a token for the account can be retrieved by calling the getAuthToken(Account, String, Bundle, Activity, AccountManagerCallback, Handler) method. The token can then be used to make authenticated API requests to a service. This could be a RESTful API where you pass in a token parameter during an HTTPS request, without ever having to know the user’s private account details.

Because each service will have a different way of authenticating and storing the private credentials, the Account Manager provides authenticator modules for a third-party service to implement. While Android has implementations for many popular services, it means you can write your own authenticator to handle your app’s account authentication and credential storage. This allows you to make sure the credentials are encrypted. Keep in mind, this also means that credentials in the Account Manager that are used by other services may be stored in clear text, making them visible to anyone who has rooted their device.

Instead of simple credentials, there are times when you will need to deal with a key or a certificate for an individual or entity—for example, when a third party sends you a certificate file which you need to keep. The most common scenario is when an app needs to authenticate to a private organization’s server.

In the next tutorial, we will be looking at using certificates for authentication and secure communications, but I still want to address how to store these items in the meantime. The Keychain API was originally built for that very specific use—installing a private key or certificate pair from a PKCS#12 file.

The Keychain

Introduced in Android 4.0 (API Level 14), the Keychain API deals with key management. Specifically, it works with PrivateKey and X509Certificate objects and provides a more secure container than using your app’s data storage. That’s because permissions for private keys only allow for your own app to access the keys, and only after user authorization. This means that a lock screen must be set up on the device before you can make use of the credential storage. Also, the objects in the keychain may be bound to secure hardware, if available.

The code to install a certificate is as follows:

The user will be prompted for a password to access the private key and an option to name the certificate. To retrieve the key, the following code presents a UI that lets the user choose from the list of installed keys.

Once the choice is made, a string alias name is returned in the alias(final String alias) callback where you can access the private key or certificate chain directly.

Armed with that knowledge, let’s now see how we can use the credential storage to save your own sensitive data.

The KeyStore

In the previous tutorial, we looked at protecting data via a user-supplied passcode. This kind of setup is good, but app requirements often steer away from having users log in each time and remember an additional passcode.

That’s where the KeyStore API can be used. Since API 1, the KeyStore has been used by the system to store WiFi and VPN credentials. As of 4.3 (API 18), it allows you to work with your own app-specific asymmetric keys, and in Android M (API 23) it can store an AES symmetric key. So while the API doesn’t allow storing sensitive strings directly, these keys can be stored and then used to encrypt strings.

The benefit to storing a key in the KeyStore is that it allows keys to be operated on without exposing the secret content of that key; key data does not enter the app space. Remember that keys are protected by permissions so that only your app can access them, and they may additionally be secure hardware-backed if the device is capable. This creates a container that makes it more difficult to extract keys from a device.

Generate a New Random Key

For this example, instead of generating an AES key from a user-supplied passcode, we can auto-generate a random key that will be protected in the KeyStore. We can do this by creating a KeyGenerator instance, set to the «AndroidKeyStore» provider.

Important parts to look at here are the .setUserAuthenticationRequired(true) and .setUserAuthenticationValidityDurationSeconds(120) specifications. These require a lock screen to be set up and the key to be locked until the user has authenticated.

Looking at the documentation for .setUserAuthenticationValidityDurationSeconds() , you will see that it means the key is only available a certain number of seconds from password authentication, and that passing in -1 requires fingerprint authentication every time you want to access the key. Enabling the requirement for authentication also has the effect of revoking the key when the user removes or changes the lock screen.

Because storing an unprotected key alongside the encrypted data is like putting a house key under the doormat, these options attempt to protect the key at rest in the event a device is compromised. An example might be an offline data dump of the device. Without the password being known for the device, that data is rendered useless.

The .setRandomizedEncryptionRequired(true) option enables the requirement that there is enough randomization (a new random IV each time) so that if the same data is encrypted a second time around, that encrypted output will still be different. This prevents an attacker from gaining clues about the ciphertext based on feeding in the same data.

Another option to note is setUserAuthenticationValidWhileOnBody(boolean remainsValid) , which locks the key once the device has detected it is no longer on the person.

Encrypting Data

Now that the key is stored in the KeyStore, we can create a method that encrypts data using the Cipher object, given the SecretKey . It will return a HashMap containing the encrypted data and a randomized IV that will be needed to decrypt the data. The encrypted data, along with the IV, can then be saved to a file or into the shared preferences.

Decrypting to a Byte Array

For decryption, the reverse is applied. The Cipher object is initialized using the DECRYPT_MODE constant, and a decrypted byte[] array is returned.

Testing the Example

We can now test our example!

Using RSA Asymmetric Keys for Older Devices

This is a good solution to store data for versions M and higher, but what if your app supports earlier versions? While AES symmetric keys are not supported under M, RSA asymmetric keys are. That means we can use RSA keys and encryption to accomplish the same thing.

The main difference here is that an asymmetric keypair contains two keys, a private and a public key, where the public key encrypts the data and the private key decrypts it. A KeyPairGeneratorSpec is passed into the KeyPairGenerator that is initialized with KEY_ALGORITHM_RSA and the «AndroidKeyStore» provider.

To encrypt, we get the RSAPublicKey from the keypair and use it with the Cipher object.

Decryption is done using the RSAPrivateKey object.

One thing about RSA is that encryption is slower than it is in AES. This is usually fine for small amounts of information, such as when you’re securing shared preference strings. If you find there is a performance problem encrypting large amounts of data, however, you can instead use this example to encrypt and store just an AES key. Then, use that faster AES encryption that was discussed in the previous tutorial for the rest of your data. You can generate a new AES key and convert it to a byte[] array that is compatible with this example.

To get the key back from the bytes, do this:

That was a lot of code! To keep all of the examples simple, I have omitted thorough exception handling. But remember that for your production code, it’s not recommended to simply catch all Throwable cases in one catch statement.

Conclusion

This completes the tutorial on working with credentials and keys. Much of the confusion around keys and storage has to do with the evolution of the Android OS, but you can choose which solution to use given the API level your app supports.

Now that we have covered the best practices for securing data at rest, the next tutorial will focus on securing data in transit.

Источник

Авторизация через Google в Android и проверка токена на сервере

Недавно мне захотелось создать личный проект на андроиде, и основной вопрос был такой: как однозначно идентифицировать пользователя заставляя его делать как можно меньше телодвижений? Конечно же это аккаунт Google. Я пытался пробовать множество примеров в сети — однако API несколько раз обновилось за время своего существования, многие методы не работали, мои вопросы в Google+ по этому поводу либо были вообще никак не восприняты окружением, либо были вроде «Никогда такое не делал».
В этой статье я постараюсь как можно более просто для новичков (вроде меня) описать мой метод авторизации в Google на андроид, получения токена и проверке этого самого токена на сервере.

Небольшая подготовка

Для начала — у вас должны быть установлены Google Play Services в SDK. После их установки можно будет импортировать все необходимые библиотеки. Статья пишется с расчетом на Android Studio — он сам подсказывает, что необходимо импортировать.
У вас должно быть создано активити с кнопкой.
Чтобы было привычнее пользователю можете создать стандартную кнопку Google+ Sing-In
Выглядеть она будет вот так:

Просто добавьте в ваш Layout:

Добавляем действие на кнопку

Пишем в нашем активити:

Собственно присвоим кнопке действие — вызов интенда выбора аккаунта. Если вы работаете в Android Studio он сам вам подскажет, какие библиотеки нужно импортировать, так что это подробно тут я расписывать не буду.
startActivityForResult(intent, 123); — задает код с которым произойдет возврат. 123 это код возврата, он может быть каким угодно. Это необходимо, когда вы делаете несколько интендов, и вам надо обработать их по разному.

Необходимые области доступа

Обьявите эти переменные в классе. Это необходимые нам области доступа. Первый написано в google: «Позволяет определить аутентифицированного пользователя. Для этого при вызове API необходимо указать me вместо идентификатора пользователя Google+. » Второе разрешение нам необходимо для получения личных данных пользователя (Имя, Фамилия, адрес G+ страницы, аватар), и последнее для получения E-mail. Я посчитал это важным, ведь это вполне неизменный идентификатор для записи в бд.

Регистрация нашего приложения.

Изначально забыл этот пункт — исправляюсь.
Нам необходимо зайти на code.google.com/apis/console создать там проект, зайти в Credentials и создать новый Client ID для OAuth выбрав пункт Installed Application -> Android. Там нам необходимо ввести название нашего пакета и SHA1 сумму нашего ключа.
С этим у меня на самом деле было много проблем решил достаточно костыльным способом.
Нашел debug.keystore в %USERPROFILE%\.android\debug.keystore поместил в папку с проектом и прописал в build.grandle:

После чего нам нужно выполнить команду:
keytool -exportcert -alias androiddebugkey -keystore

/.android/debug.keystore -v -list
Сам keytool можно найти в SDK. Из вывода копируем SHA1 в нужное поле.
Как я понимаю метод временный, и для нормальной работы надо создать нормальный ключ. Но для тестирования этого достаточно.

Код получения токена

Где 123 — ваш код, который вы указали ранее, где AcrivityName — название вашего актитивити. Грубо говоря — мы скармливаем функции получения токена необходимые разрешения и имя аккаунта. И заметьте — это все происходит в фоновом режиме, после чего полученный токен передается в написанную мною функцию reg. Она уже отправляет токен и все необходимые данные на сервер.
Так как разрабатываю недавно, с исключениями пока что беда, если есть предложение — напишите в личку или в комментарии.

Проверяем токен на сервере. (PHP)

Хочу обратить внимание, полученный нами токен имеет тип Online. И действует он лишь 10 минут. Для получения offline токена (чтобы дольше работать с ним с сервера) обратитесь к этой инструкции developers.google.com/accounts/docs/CrossClientAuth

Собственно скармливаем токен в googleapis и забираем полученный JSON ответ.

Источник

How to Store Credentials in Android Projects Using gradle.properties

Edit: Hi all. Lots of fellow developers commented that this is not the safest method out there. So I’m cutting the ‘safest’ part from the title of this post. The original title was ‘How to Safely Store Credentials in Android Projects Using gradle.properties.’ Let me clarify that my intention was to share this knowledge to beginner Android developers. Rather than investing their time on complex methods to keep sensitive information in the project, I thought they can use this method as a starting point and then take it from there. I’m also mentioning the same in the article as well. I realized that somehow it got overlooked. Hope I clarified the issue here.

Keeping sensitive information away from a third person in Android projects is a difficult task. If you are working on anything related to APIs, mostly, you will have to pass authentication credentials from the front end. Be it an API Key, Basic Authentication, or Bearer token you, must store those credentials in the front end in a constant value. The problem with this approach is that we are diminishing the safety of our project. We will then publish or share our project to a repository along with our sensitive data. You have to keep in mind that this information is enough for a third person to call your APIs and gather crucial knowledge from your system.

We can try using several methods to prevent this scenario. Such as client-side cryptography, keeping your credentials in the server, use Proguard to obfuscate your code, use Firebase remote config, etc. But truth be told, all these above methods are not effective in actually keeping your data safe. I would say it is not worth putting your time into something that is not foolproof. Even the method I’m suggesting is not infallible. But it is not time consuming and it is very easy to implement. There. I said it. 😋

gradle.properties

You are already familiar with the ‘Gradle’ files. If not the ‘gradle.properties’, you will be accustomed to the ‘build.gradle’ files of the app and project. They help us automate and manage the build processes, allowing you to define flexible custom build configurations, add third-party libraries to it and integrate them with our project, etc.

The gradle.properties is a good location for placing properties that control the build environment.

If you check the gradle.properties file now, you will be able to see that Android studio already added some default properties.

We can add more such properties if we want to. Please check this link to know more details about it.

Now, grab your API key or credentials or any sensitive information you want to store inside the project. Add a new property inside the gradle.properties file and name it as API_KEY. You can call it anything according to your wish.

Then go to your app’s build.gradle file and find the defaultConfig block and add the following item.

BuildConfig.java is a class that is automatically generated by the build system. It already includes default fields such as DEBUG and FLAVOR. But, we can add custom fields to it. Let me explain the parameters of this method.

1. String: This parameter explains the type of the custom field. In our case, it is a String.
2. APP_KEY: This is the name by which we will call our API_KEY in the gradle.properties file
3. API_KEY: The actual value of the API_KEY will be retrieved from the gradle.properties file during the build time. It doesn’t exist in runtime or inside your APK.

Finally, whenever you want to obtain the value of API_KEY in your project, do this.

One more thing. We almost forgot the most crucial part. Change the project structure from ‘Android’ to ‘Project.’ You will be able to find a file named ‘.gitignore.’

As you know, the gitignore file is a text file that tells git which files or folders to ignore in a project. By doing this, you will not send the gradle.properties file to any repository, and Android Studio will generate this file during the project building.

Your .gitignore file will look like this,

Like I said earlier, it is not the best method to secure your data. But it is an option that you can implement quickly and better than not implementing any steps related to security aspects. If you know any good alternatives do suggest them in the comments.

Article was original posted at clintpauldev.com

You may also want to read my recent articles on

Источник