Para proteger seu sistema de autenticação no Android, considere abandonar modelo baseado em senha, especialmente para contas confidenciais, como a margem e contas de e-mail. Lembre-se de que alguns aplicativos que os usuários instalam podem não ter a que têm boas intenções e podem tentar aplicar phishing aos usuários.
Além disso, não presuma que apenas usuários autorizados vão usar o dispositivo. Roubo de smartphones é um problema comum e os atacantes visam dispositivos desbloqueados para lucrar diretamente de dados do usuário ou apps financeiros. Sugerimos que todos os apps confidenciais implementem uma tempo limite razoável de autenticação (15 minutos) com verificação biométrica e exigem autenticação extra antes de ações sensíveis, como dinheiro transferências de dados.
Caixa de diálogo de autenticação biométrica
A biblioteca Biometrics oferece um conjunto de funções para exibir um comando solicitando autenticação biométrica, como reconhecimento facial ou de impressão digital. No entanto, os comandos biométricos podem ser configurados para usar o LSKF, que tem riscos conhecidos de acostamento. Para apps sensíveis, recomendamos não ter a biometria usada novamente no PIN e, depois de muitas tentativas biométricas esgotadas, os usuários podem aguardar ou fazer login novamente com a senha ou redefinir as contas. Redefinição de conta exigir fatores que não são facilmente acessíveis 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 seu app antes de uma transação. Quando seus usuários quiser fazer uma transação financeira, a caixa de diálogo de biometria será mostrada para verificar se é realmente o usuário pretendido que está fazendo a transação. Isso prática recomendada protegeria contra o roubo de um dispositivo, independentemente o invasor conhecendo ou não o LSKF, porque precisará verificar se está o proprietário do dispositivo.
Para ter mais níveis de segurança, recomendamos que os desenvolvedores de apps solicitem a Classe 3
Autenticação biométrica e usar CryptoObject para serviços bancários e
transações financeiras.
Implementação
- Inclua a biblioteca androidx.biometric.
- Incluir a caixa de diálogo de login biométrico na atividade ou no fragmento que contém a lógica 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 biometria Caixa de diálogo com ação explícita do usuário para cada transação. Entendemos que a adição de autenticação pode gerar atrito na UX, mas devido à natureza as informações em uma transação bancária e a biometria autenticação é mais fácil do que outros métodos de autenticação, achamos que é necessário para 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. Uso de chaves de acesso a 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 rosto e reconhecimento de objetos. Assim, o usuário não precisa lembrar e gerenciar senhas, o que aumenta significativamente a segurança.
As chaves de acesso podem atender aos requisitos de autenticação multifator em uma única etapa. a substituição de senhas e códigos OTP para oferecer uma proteção robusta contra ataques de phishing e evitar a experiência do usuário com o uso de SMS ou apps senhas. Como as chaves de acesso são padronizadas, uma única implementação permite uma sem senha em todos os dispositivos, navegadores sistemas operacionais.
No Android, as chaves de acesso têm suporte usando o 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 só funcionam no seu e sites registrados.
O componente principal de uma chave de acesso é uma chave privada criptográfica. Normalmente, isso a chave privada reside exclusivamente nos seus dispositivos, como laptops ou smartphones, e é sincronizada entre elas por provedores de credenciais (também conhecidos como senhas de apps), 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 se originam de um dos seus dispositivos. Além disso, para que isso ocorra, você deve desbloquear o 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 ser associadas a uma janela de tempo limite de autenticação razoável. Um um invasor que rouba um dispositivo não poderia usar um aplicativo porque o usuário anterior tinha feito login. Em vez disso, as credenciais devem expiram em intervalos regulares (por exemplo, a cada 15 minutos), e os usuários devem necessárias para 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 senhas para uso 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 forem roubados, você pode fazer login na sua Conta do Google Conta de outro dispositivo (como um computador) e logout remotamente do e roubado. Isso torna o Gerenciador de senhas do Google no smartphone roubado inutilizáveis, incluindo chaves de acesso salvas.
Na pior das hipóteses, se o dispositivo roubado não for recuperado, as chaves de acesso serão sincronizado 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 acessá-la em um novo dispositivo assinando à Conta do Google e fornecer o bloqueio de tela da dispositivo.
Saiba mais na Artigo Segurança de 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 Digital Asset Links.
Consulte nossa documentação para desenvolvedores e saiba como criar, registrar e se autenticar com chaves de acesso.
Redefinição de conta segura
um invasor não autorizado com acesso a um dispositivo desbloqueado (como um smartphone é roubado) vai tentar acessar apps sensíveis, especialmente apps de bancos ou de dinheiro. Se o app implementar a verificação biométrica, o invasor vai tentar redefinir a conta para entrar. É essencial que o fluxo de redefinição de conta não dependa apenas em informações que podem ser facilmente acessadas no dispositivo, como OTP por e-mail ou SMS redefinir links.
Confira práticas recomendadas comuns que podem ser incorporadas à redefinição do app fluxo:
- Reconhecimento facial e OTP
- Perguntas de segurança
- Fator de conhecimento, como o nome de solteira da mãe, cidade de nascimento ou local favorito música)
- confirmação de identidade com documento
API SMS Retriever
A API SMS Retriever permite que você faça a verificação de usuários com base em SMS no seu
app Android automaticamente. Dessa forma, o usuário não terá que
manualmente os códigos de verificação. Além disso, essa API não solicita ao usuário
para 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
contra acesso local não autorizado ao dispositivo.
Como isso ajuda a reduzir fraudes
Alguns usuários utilizam códigos SMS como o único fator de autenticação que fornece uma um ponto de entrada fácil para evitar fraudes.
A API SMS Retriever permite que o app recupere diretamente o código SMS sem interação do usuário, além de 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 for integrado e o número de telefone do usuário for verificado com a API SMS Retriever, ele tenta receber a OTP. Se tiver sucesso, essa será uma forte sinalizar que o SMS foi recebido no dispositivo automaticamente. Se não funcionar e o usuário precisar digitar a OTP manualmente, isso pode ser um sinal de alerta que o usuário pode estar sofrendo fraude.
O SMS não deve ser usado como o único mecanismo de verificação do usuário, porque isso deixa espaço disponível a ataques locais, como um invasor que rouba um dispositivo desbloqueado; ou chip ataques de clonagem. É recomendável usar biometria sempre que possível. Ativado dispositivos em que os sensores biométricos não estejam disponíveis, a autenticação do usuário precisa dependem de pelo menos um fator que não é facilmente obtido 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