Para proteger seu sistema de autenticação no Android, considere deixar de usar um modelo baseado em senha, especialmente para contas confidenciais, como contas bancárias e de e-mail dos usuários. Lembre-se de que alguns apps instalados talvez não tenham as melhores intenções e tentem aplicar phishing.
Além disso, não presuma que apenas usuários autorizados vão usar o dispositivo. O roubo de smartphones é um problema comum, e os invasores visam dispositivos desbloqueados para lucrar diretamente com dados do usuário ou apps financeiros. Sugerimos que todos os apps sensíveis implementem um tempo limite de autenticação razoável (15 minutos?) com verificação biométrica e exijam autenticação extra antes de ações sensíveis, como transferências de dinheiro.
Caixa de diálogo de autenticação biométrica
A biblioteca Biometrics oferece um conjunto de funções para mostrar um comando solicitando autenticação biométrica, como reconhecimento facial ou de impressão digital. No entanto, as solicitações biométricas podem ser configuradas para usar o LSKF, que tem riscos de acostamento conhecidos. No caso de apps confidenciais, recomendamos que a biometria não volte a usar o PIN e, após o tempo limite das novas tentativas biométricas, os usuários podem aguardar, fazer login novamente com a senha ou redefinir as contas. A redefinição de conta precisa exigir fatores que não podem ser acessados facilmente no dispositivo (prática recomendada abaixo).
Como isso ajuda a reduzir fraudes e roubo de smartphones
Um caso de uso específico que pode ser útil para evitar fraudes é solicitar autenticação biométrica no app antes de uma transação. Quando os usuários querem fazer uma transação financeira, a caixa de diálogo biométrica é exibida para verificar se é realmente o usuário pretendido que está fazendo a transação. Essa prática recomendada protegeria contra o roubo de um dispositivo, mesmo que o invasor conheça ou não o LSKF, já que ele precisará verificar se é o proprietário do dispositivo.
Para ter mais níveis de segurança, recomendamos que os desenvolvedores de apps solicitem a autenticação biométrica de classe 3
e usem o CryptoObject para transações bancárias e
financeiras.
Implementação
- Inclua a biblioteca androidx.biometric.
- Inclua a caixa de diálogo de login biométrico na atividade ou no fragmento que contém a lógica de que você quer que o usuário seja autenticado.
Kotlin
private var executor: Executor? = null
private var biometricPrompt: BiometricPrompt? = null
private var promptInfo: BiometricPrompt.PromptInfo? = null
fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_login)
executor = ContextCompat.getMainExecutor(this)
biometricPrompt = BiometricPrompt(this@MainActivity,
executor, object : AuthenticationCallback() {
fun onAuthenticationError(
errorCode: Int,
@NonNull errString: CharSequence
) {
super.onAuthenticationError(errorCode, errString)
Toast.makeText(
getApplicationContext(),
"Authentication error: $errString", Toast.LENGTH_SHORT
)
.show()
}
fun onAuthenticationSucceeded(
@NonNull result: BiometricPrompt.AuthenticationResult?
) {
super.onAuthenticationSucceeded(result)
Toast.makeText(
getApplicationContext(),
"Authentication succeeded!", Toast.LENGTH_SHORT
).show()
}
fun onAuthenticationFailed() {
super.onAuthenticationFailed()
Toast.makeText(
getApplicationContext(), "Authentication failed",
Toast.LENGTH_SHORT
)
.show()
}
})
promptInfo = Builder()
.setTitle("Biometric login for my app")
.setSubtitle("Log in using your biometric credential")
.setNegativeButtonText("Use account password")
.build()
// Prompt appears when user clicks "Log in".
// Consider integrating with the keystore to unlock cryptographic operations,
// if needed by your app.
val biometricLoginButton: Button = findViewById(R.id.biometric_login)
biometricLoginButton.setOnClickListener { view ->
biometricPrompt.authenticate(
promptInfo
)
}
}
Java
private Executor executor;
private BiometricPrompt biometricPrompt;
private BiometricPrompt.PromptInfo promptInfo;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_login);
executor = ContextCompat.getMainExecutor(this);
biometricPrompt = new BiometricPrompt(MainActivity.this,
executor, new BiometricPrompt.AuthenticationCallback() {
@Override
public void onAuthenticationError(int errorCode,
@NonNull CharSequence errString) {
super.onAuthenticationError(errorCode, errString);
Toast.makeText(getApplicationContext(),
"Authentication error: " + errString, Toast.LENGTH_SHORT)
.show();
}
@Override
public void onAuthenticationSucceeded(
@NonNull BiometricPrompt.AuthenticationResult result) {
super.onAuthenticationSucceeded(result);
Toast.makeText(getApplicationContext(),
"Authentication succeeded!", Toast.LENGTH_SHORT).show();
}
@Override
public void onAuthenticationFailed() {
super.onAuthenticationFailed();
Toast.makeText(getApplicationContext(), "Authentication failed",
Toast.LENGTH_SHORT)
.show();
}
});
promptInfo = new BiometricPrompt.PromptInfo.Builder()
.setTitle("Biometric login for my app")
.setSubtitle("Log in using your biometric credential")
.setNegativeButtonText("Use account password")
.build();
// Prompt appears when the user clicks "Log in".
// Consider integrating with the keystore to unlock cryptographic operations,
// if needed by your app.
Button biometricLoginButton = findViewById(R.id.biometric_login);
biometricLoginButton.setOnClickListener(view -> {
biometricPrompt.authenticate(promptInfo);
});
}
Práticas recomendadas
Recomendamos que você comece pelo codelab para saber mais sobre biometria.
Dependendo dos casos de uso, é possível implementar a caixa de diálogo com ou sem uma ação explícita do usuário. Para evitar fraudes, recomendamos que você adicione a caixa de diálogo biométrica com ação explícita do usuário para cada transação. Entendemos que adicionar autenticação pode gerar atrito na UX, mas devido à natureza das informações que estão sendo processadas em uma transação bancária e que a autenticação biométrica é mais suave do que outros métodos de autenticação, achamos que é necessário adicionar esse nível de navegação.
Saiba mais sobre a autenticação biométrica.
Chaves de acesso
As chaves de acesso são uma alternativa mais segura e fácil às senhas. As chaves de acesso usam criptografia de chave pública para permitir que os usuários façam login em apps e sites usando o mecanismo de bloqueio de tela do dispositivo, como impressão digital ou reconhecimento facial. Isso libera o usuário de ter que lembrar e gerenciar senhas e fornece segurança significativamente aprimorada.
As chaves de acesso podem atender aos requisitos de autenticação multifator em uma única etapa, substituindo uma senha e códigos OTP para oferecer uma proteção robusta contra ataques de phishing e evitar a dificuldade do usuário com senhas únicas baseadas em apps ou SMS. Como as chaves de acesso são padronizadas, uma única implementação permite uma experiência sem senha em todos os dispositivos, navegadores e sistemas operacionais dos usuários.
No Android, as chaves de acesso têm suporte da biblioteca do Gerenciador de credenciais do Jetpack, que unifica os principais métodos de autenticação, incluindo chaves de acesso, senhas e login federado (como o recurso Fazer login com o Google).
Como isso ajuda a reduzir fraudes
As chaves de acesso protegem você contra ataques de phishing porque funcionam apenas nos apps e sites registrados.
O componente principal de uma chave de acesso é uma chave privada criptográfica. Normalmente, essa chave privada fica somente nos seus dispositivos, como laptops ou smartphones, e é sincronizada entre eles por provedores de credenciais (também conhecidos como gerenciadores de senhas), como o Gerenciador de senhas do Google. Somente a chave pública correspondente é salva pelo serviço on-line quando uma chave de acesso é criada. Durante o login, o serviço usa a chave privada para assinar um desafio na chave pública. Isso só pode ser originado de um dos seus dispositivos. Além disso, para que isso ocorra, você precisa desbloquear seu dispositivo ou armazenamento de credenciais, o que impede logins não autorizados (por exemplo, de um smartphone roubado).
Para impedir o acesso não autorizado em caso de um dispositivo desbloqueado e roubado, as chaves de acesso precisam estar associadas a uma janela de tempo limite de autenticação. Um invasor que rouba um dispositivo não pode usar um aplicativo apenas porque o usuário anterior estava conectado. Em vez disso, as credenciais precisam expirar em intervalos regulares (por exemplo, a cada 15 minutos), e os usuários precisam verificar a identidade com a reautenticação do bloqueio de tela.
Se o smartphone for roubado, as chaves de acesso vão proteger você, porque ladrões não podem roubar suas senhas para usar em outros dispositivos. As chaves de acesso são específicas do dispositivo. Se você usar o Gerenciador de senhas do Google e seu smartphone for roubado, faça login na sua Conta do Google em outro dispositivo (como um computador) e saia remotamente do smartphone roubado. Isso inutiliza o Gerenciador de senhas do Google no smartphone roubado, incluindo chaves de acesso salvas.
Na pior das hipóteses, se o dispositivo roubado não for recuperado, as chaves de acesso serão sincronizadas com o novo dispositivo pelo provedor de credenciais que criou e sincronizou a chave de acesso. Por exemplo, o usuário pode ter escolhido o Gerenciador de senhas do Google para criar a chave de acesso e pode acessá-la em um novo dispositivo fazendo login novamente na Conta do Google e fornecendo o bloqueio de tela no dispositivo anterior.
Saiba mais no artigo Segurança das chaves de acesso no Gerenciador de senhas do Google.
Implementação
As chaves de acesso são compatíveis com dispositivos que executam o Android 9 (nível 28 da API) ou versões mais recentes. Senhas e Fazer login com o Google são compatíveis a partir do Android 4.4. Para começar a usar chaves de acesso, siga estas etapas:
- Siga o codelab do Gerenciador de credenciais para entender melhor como implementar chaves de acesso.
- Leia as diretrizes de design para a experiência do usuário de chaves de acesso. Neste documento, mostramos quais fluxos são recomendados para seu caso de uso.
- Estude o Gerenciador de credenciais seguindo o guia.
- Planeje a implementação do Gerenciador de credenciais e das chaves de acesso para o app. Planeje adicionar suporte para os Digital Asset Links.
Consulte nossa documentação para desenvolvedores para ver mais detalhes sobre como criar, registrar e autenticar com chaves de acesso.
Redefinição de conta segura
Um invasor não autorizado com acesso a um dispositivo desbloqueado (por exemplo, quando um smartphone é roubado) tentará acessar apps sensíveis, especialmente apps bancários ou de dinheiro. Se o app implementar a verificação biométrica, o invasor vai tentar redefinir a conta para acessar. É essencial que o fluxo de redefinição de conta não dependa apenas de informações facilmente acessíveis no dispositivo, como links de redefinição de OTP por e-mail ou SMS.
Aqui estão práticas recomendadas comuns que podem ser incorporadas ao fluxo de redefinição do app:
- Reconhecimento facial e OTP
- Perguntas de segurança
- Fator de conhecimento, como o nome de solteira de uma mãe, cidade de nascimento ou música favorita
- confirmação de identidade com documento
API SMS Retriever
A API SMS Retriever permite realizar a verificação de usuários por SMS no
app Android automaticamente. Dessa forma, o usuário não vai precisar
digitar manualmente os códigos de verificação. Além disso, essa API não solicita ao usuário
permissões de app adicionais e potencialmente perigosas, como RECEIVE_SMS ou
READ_SMS. No entanto, o SMS não deve ser usado como a única verificação do usuário para
proteger o dispositivo contra acesso local não autorizado.
Como isso ajuda a reduzir fraudes
Alguns usuários usam códigos SMS como o único fator de autenticação, que fornece um ponto de entrada fácil para fraudes.
A API SMS Retriever permite que o app recupere diretamente o código SMS sem interação do usuário e pode fornecer um nível de proteção contra fraudes.
Implementação
A implementação da API SMS Retriever é dividida em duas partes: Android e Server.
Android: (guia)
- Encontre o número de telefone do usuário.
- Inicie o cliente da recuperação de SMS.
- Envie o número de telefone para seu servidor.
- Receber mensagens de verificação.
- Envie a OTP ao seu servidor.
Servidor: (guia)
- Criar uma mensagem de verificação.
- Envie a mensagem de verificação por SMS.
- Verifique a OTP quando ela for retornada.
Práticas recomendadas
Depois que o app é integrado e o número de telefone do usuário está sendo verificado com a API SMS Retriever, ele tenta receber a OTP. Se funcionar, isso será um forte sinal de que o SMS foi recebido no dispositivo automaticamente. Se não for bem-sucedido, e o usuário precisar digitar manualmente a OTP, isso pode ser um sinal de alerta de que o usuário pode estar sofrendo fraude.
O SMS não pode ser usado como o único mecanismo de verificação de usuário, porque ele deixa espaço para ataques locais, como um invasor que rouba um dispositivo desbloqueado ou ataques de clonagem de chip. É recomendável usar biometria sempre que possível. Em dispositivos em que os sensores biométricos não estão disponíveis, a autenticação do usuário precisa contar com pelo menos um fator que não é facilmente recebido do dispositivo atual.
Saiba mais
Para ler mais sobre as práticas recomendadas, confira os seguintes recursos:
- Documentação do Android sobre segurança
- Documentação da API Play Integrity
- Mudanças no Android 15
- Práticas recomendadas do Monzo Bank para evitar golpes