HurbMachine LearningTecnologiaUncategorized

Como o KAYAK reduziu o tempo de login em 50% e melhorou a segurança com chaves de acesso

14/11/2023

KAYAK é um dos principais mecanismos de pesquisa de viagens do mundo que ajuda os usuários a encontrar as melhores ofertas em voos, hotéis e aluguel de carros. Em 2023, o KAYAK integrou senhas – um novo tipo de autenticação sem senha – em seus aplicativos Android e web. Como resultado, o KAYAK reduziu em 50% o tempo médio que os usuários levam para se inscrever e fazer login e também observou uma diminuição nos tickets de suporte.

Este estudo de caso explica a implementação do KAYAK no Android com API Credential Manager e RxJava. Você pode usar este estudo de caso como modelo para implementar o Credential Manager para melhorar a segurança e a experiência do usuário em seus próprios aplicativos.

Problema

Como a maioria das empresas, o KAYAK dependia de senhas no passado para autenticar usuários. As senhas são um risco tanto para os usuários quanto para as empresas: muitas vezes são fracas, reutilizadas, adivinhadas, roubadas, vazadas ou hackeadas.

“Oferecer autenticação por senha exige muito esforço e riscos para os negócios. Os invasores estão constantemente tentando usar contas de força bruta, embora nem todos os usuários entendam a necessidade de senhas fortes. No entanto, mesmo senhas fortes não são totalmente seguras e ainda podem ser roubadas.” – Matthias Keller, cientista-chefe e vice-presidente sênior de tecnologia do

KAYAK

Para tornar a autenticação mais segura, o KAYAK enviou “links mágicos” por e-mail. Embora útil do ponto de vista de segurança, essa etapa extra introduziu mais atrito ao usuário, exigindo que os usuários mudassem para um aplicativo diferente para concluir o processo de login. Medidas adicionais precisavam ser introduzidas para mitigar o risco de ataques de phishing.

Solução

O aplicativo Android do KAYAK agora usa chaves de acesso para uma experiência de autenticação mais segura, fácil de usar e mais rápida. As chaves de acesso são tokens exclusivos e seguros armazenados no dispositivo do usuário e que podem ser sincronizados em vários dispositivos. Os usuários podem fazer login no KAYAK com uma senha, simplesmente usando o bloqueio de tela existente do dispositivo, tornando-o mais simples e seguro do que inserir uma senha.

“Adicionamos suporte para chaves de acesso ao nosso aplicativo Android para que mais usuários possam usar chaves de acesso em vez de senhas. Dentro desse trabalho, também substituímos nossa antiga implementação da API Smartlock pela API Sign in with Google suportada pela API Credential Manager. Agora, os usuários podem se inscrever e fazer login no KAYAK com senhas duas vezes mais rápido do que com um link de e-mail, o que também melhora a taxa de conclusão” – Matthias Keller,  cientista-chefe e vice-presidente sênior de tecnologia do KAYAK

 

Integração da API do Credential Manager

Para integrar chaves de acesso no Android, o KAYAK usou a API Credential Manager . O Credential Manager é uma biblioteca do Jetpack que unifica o suporte a chaves de acesso a partir do Android 9 (API de nível 28) e o suporte a métodos de login tradicionais, como senhas e autenticação federada, em uma única interface de usuário e API.

Imagem da tela de criação de senha do Credential Manager.

Figura 1: Telas de criação de senha do Credential Manager.

Projetar um fluxo de autenticação robusto para aplicativos é crucial para garantir a segurança e uma experiência confiável do usuário. O diagrama a seguir demonstra como o KAYAK integrou as chaves de acesso aos seus fluxos de registro e autenticação:

Diagrama de fluxo dos processos de registro e autenticação do KAYAK

Figura 2: Diagrama do KAYAK mostrando seus fluxos de cadastro e autenticação.

No momento do registro, os usuários têm a oportunidade de criar uma chave de acesso. Uma vez registrados, os usuários podem fazer login usando sua chave de acesso, faça login com o Google ou senha. Como o Credential Manager inicia a UI automaticamente, tome cuidado para não introduzir tempos de espera inesperados, como chamadas de rede. Sempre busque um desafio único e outras configurações de chaves de acesso (como ID de RP) no início de qualquer sessão do aplicativo.

Embora a equipe KAYAK agora esteja fortemente investida em corrotinas, sua integração inicial usou RxJava para integração com a API do Credential Manager. Eles agruparam chamadas do Credential Manager no RxJava da seguinte maneira:

override fun createCredential(request: CreateCredentialRequest, activity: Activity): Single<CreateCredentialResponse> {
return Single.create { emitter ->
// Triggers credential creation flow
credentialManager.createCredentialAsync(
request = request,
activity = activity,
cancellationSignal = null,
executor = Executors.newSingleThreadExecutor(),
callback = object : CredentialManagerCallback<CreateCredentialResponse, CreateCredentialException> {
override fun onResult(result: CreateCredentialResponse) {
emitter.onSuccess(result)
}override fun onError(e: CreateCredentialException) {
emitter.tryOnError(e)
}
}
)
}
}

Este exemplo define uma função Kotlin chamada createCredential() que retorna uma credencial do usuário como um RxJava Single do tipo CreateCredentialResponse . A função createCredential() encapsula o processo assíncrono de registro de credenciais em um estilo de programação reativo usando a classe RxJava Single .

Para uma implementação Kotlin desse processo usando corrotinas , leia o guia Faça login no seu usuário com o Credential Manager .

Fluxo de inscrição de registro de novo usuário

Este exemplo demonstra a abordagem usada pelo KAYAK para registrar uma nova credencial, aqui o Credential Manager foi encapsulado em primitivas Rx.

webAuthnRetrofitService
.getClientParams(username = /** email address **/)
.flatMap { response ->
// Produce a passkeys request from client params that include a one-time challenge
CreatePublicKeyCredentialOption(/** produce JSON from response **/)
}
.subscribeOn(schedulers.io())
.flatMap { request ->
// Call the earlier defined wrapper which calls the Credential Manager UI
// to register a new passkey credential
credentialManagerRepository
.createCredential(
request = request,
activity = activity
)
}
.flatMap {
// send credential to the authentication server
}
.observeOn(schedulers.main())
.subscribe(
{ /** process successful login, update UI etc. **/ },
{ /** process error, send to logger **/ }
)

O Rx permitiu que o KAYAK produzisse pipelines mais complexos que podem envolver múltiplas interações com o Credential Manager.

Login de usuário existente

O KAYAK seguiu as etapas a seguir para iniciar o fluxo de login. O processo inicia um elemento de UI na página inferior, permitindo que o usuário faça login usando um ID do Google e uma chave de acesso existente ou senha salva.

Imagem da página inferior para autenticação de chave de acesso

Figura 3: Folha inferior para autenticação de senha.

Os desenvolvedores devem seguir estas etapas ao configurar um fluxo de login:

  • Como a planilha inferior é iniciada automaticamente, tome cuidado para não introduzir tempos de espera inesperados na UI, como chamadas de rede. Sempre busque um desafio único e outras configurações de chaves de acesso (como RP ID ) no início de qualquer sessão do aplicativo.
  • Ao oferecer o login do Google por meio da API Credential Manager , seu código deve procurar inicialmente por contas do Google que já foram usadas com o aplicativo. Para lidar com isso, chame a API com o parâmetro setFilterByAuthorizedAccounts definido como true .
  • Se o resultado retornar uma lista de credenciais disponíveis, o aplicativo mostrará ao usuário a UI de autenticação da página inferior.
  • Se uma NoCredentialException aparecer, nenhuma credencial foi encontrada: nenhuma conta do Google, nenhuma senha e nenhuma senha salva. Neste ponto, seu aplicativo deve chamar a API novamente e definir setFilterByAuthorizedAccounts como false para iniciar o fluxo Cadastre-se no Google .
  • Processe a credencial retornada do Credential Manager.
Single.fromSupplier<GetPublicKeyCredentialOption> {
GetPublicKeyCredentialOption(/** Insert challenge and RP ID that was fetched earlier **/)
}
.flatMap { response ->
// Produce a passkeys request
GetPublicKeyCredentialOption(response.toGetPublicKeyCredentialOptionRequest())
}
.subscribeOn(schedulers.io())
.map { publicKeyCredentialOption ->
// Merge passkeys request together with other desired options,
// such as Google sign-in and saved passwords.
}
.flatMap { request ->
// Trigger Credential Manager system UI
credentialManagerRepository.getCredential(
request = request,
activity = activity
)
}
.onErrorResumeNext { throwable ->
// When offering Google sign-in, it is recommended to first only look for Google accounts
// that have already been used with our app. If there are no such Google accounts, no passkeys,
// and no saved passwords, we try looking for any Google sign-in one more time.
if (throwable is NoCredentialException) {
return@onErrorResumeNext credentialManagerRepository.getCredential(
request = GetCredentialRequest(/* Google ID with filterByAuthorizedOnly = false */),
activity = activity
)
}
Single.error(throwable)
}
.flatMapCompletable {
// Step 1: Use Retrofit service to send the credential to the server for validation. Waiting
// for the server is handled on a IO thread using subscribeOn(schedulers.io()).
// Step 2: Show the result in the UI. This includes changes such as loading the profile
// picture, updating to the personalized greeting, making member-only areas active,
// hiding the sign-in dialog, etc. The activities of step 2 are executed on the main thread.
}
.observeOn(schedulers.main())
.subscribe(
// Handle errors, e.g. send to log ingestion service.
// A subset of exceptions shown to the user can also be helpful,
// such as user setup problems.
// Check out more info in Troubleshoot common errors at
// https://developer.android.com/training/sign-in/passkeys#troubleshoot
)
“Depois que a API do Credential Manager é geralmente implementada, é muito fácil adicionar outros métodos de autenticação. Adicionar o login com um toque do Google quase não deu trabalho depois de adicionar chaves de acesso. –Mathias Keller

Para saber mais, siga o guia sobre como integrar a API do Credentials Manager e como integrar o Credential Manager com o Sign in with Google .

Considerações de experiência do usuário

Algumas das principais considerações sobre a experiência do usuário que o KAYAK enfrentou ao mudar para chaves de acesso incluíam se os usuários deveriam ser capazes de excluir chaves de acesso ou criar mais de uma chave de acesso.

Nosso guia UX para chaves de acesso recomenda que você tenha a opção de revogar uma chave de acesso e garantir que o usuário não crie chaves de acesso duplicadas para o mesmo nome de usuário no mesmo gerenciador de senhas.

Imagem da IU do KAYAK para gerenciamento de senhas

Figura 4: UI do KAYAK para gerenciamento de senhas.

Para evitar o registro de múltiplas credenciais para a mesma conta, o KAYAK usou a propriedade excludeCredentials que lista as credenciais já registradas para o usuário. O exemplo a seguir demonstra como criar novas credenciais no Android sem criar duplicatas:

fun WebAuthnClientParamsResponse.toCreateCredentialRequest(): String {
val credentialRequest = WebAuthnCreateCredentialRequest(
challenge = this.challenge!!.asSafeBase64,
relayingParty = this.relayingParty!!,
pubKeyCredParams = this.pubKeyCredParams!!,
userEntity = WebAuthnUserEntity(
id = this.userEntity!!.id.asSafeBase64,
name = this.userEntity.name,
displayName = this.userEntity.displayName
),
authenticatorSelection = WebAuthnAuthenticatorSelection(
authenticatorAttachment = "platform",
residentKey = "preferred"
),
// Setting already existing credentials here prevents
// creating multiple passkeys on the same keychain/password manager
excludeCredentials = this.allowedCredentials!!.map { it.copy(id = it.id.asSafeBase64) },
)
return GsonBuilder().disableHtmlEscaping().create().toJson(credentialRequest)
}

E foi assim que o KAYAK implementou a funcionalidade excludeCredentials para sua implementação na Web.

var registrationOptions = {
'publicKey': {
'challenge': self.base64ToArrayBuffer(data.challenge),
'rp': data.rp,
'user': {
'id': new TextEncoder().encode(data.user.id),
'name': data.user.name,
'displayName': data.user.displayName
},
'pubKeyCredParams': data.pubKeyCredParams,
'authenticatorSelection': {
'residentKey': 'required'
}
}
};if (data.allowCredentials && data.allowCredentials.length > 0) {
var excludeCredentials = [];
for (var i = 0; i < data.allowCredentials.length; i++) {
excludeCredentials.push({
‘id’: self.base64ToArrayBuffer(data.allowCredentials[i].id),
‘type’: data.allowCredentials[i].type
});
}
registrationOptions.publicKey.excludeCredentials = excludeCredentials;
}navigator.credentials.create(registrationOptions);

Implementação do lado do servidor

A parte do servidor é um componente essencial de uma solução de autenticação. O KAYAK adicionou recursos de senha ao back-end de autenticação existente, utilizando WebAuthn4J , uma biblioteca Java de código aberto. O KAYAK dividiu o processo do lado do servidor nas seguintes etapas:

  • O cliente solicita parâmetros necessários para criar ou usar uma chave de acesso do servidor. Isso inclui o desafio, o algoritmo de criptografia compatível, o ID da parte confiável e itens relacionados. Se o cliente já tiver um endereço de e-mail de usuário, os parâmetros incluirão o objeto de usuário para registro e uma lista de chaves de acesso, se houver.
  • O cliente executa fluxos de navegador ou aplicativo para iniciar o registro ou a entrada da chave de acesso.
  • O cliente envia informações de credenciais recuperadas para o servidor. Isso inclui ID do cliente, dados do autenticador, dados do cliente e outros itens relacionados. Essas informações são necessárias para criar uma conta ou verificar um login.

Quando o KAYAK trabalhou neste projeto, nenhum produto de terceiros suportava chaves de acesso. No entanto, muitos recursos estão agora disponíveis para a criação de um servidor de chave de acesso, incluindo documentação e exemplos de biblioteca .

Resultados

Desde a integração das chaves de acesso, o KAYAK observou um aumento significativo na satisfação dos usuários. Os usuários relataram que consideram as chaves de acesso muito mais fáceis de usar do que as senhas, pois não exigem que os usuários se lembrem ou digitem uma sequência longa e complexa de caracteres. O KAYAK reduziu em 50% o tempo médio que seus usuários levam para se inscrever e fazer login, observou uma diminuição nos tíquetes de suporte relacionados a senhas esquecidas e tornou seu sistema mais seguro, reduzindo sua exposição a ataques baseados em senha. Graças a essas melhorias, o KAYAK planeja eliminar a autenticação baseada em senha em seu aplicativo até o final de 2023.

“As chaves de acesso tornam a criação de uma conta extremamente rápida, eliminando a necessidade de criação de senha ou de navegação para um aplicativo separado para obter um link ou código. Como bônus, a implementação da nova biblioteca Credential Manager também reduziu o débito técnico em nossa base de código, colocando chaves de acesso, senhas e login do Google, tudo em uma nova interface de usuário moderna. Na verdade, os usuários podem se inscrever e fazer login no KAYAK com senhas duas vezes mais rápido do que com um link de e-mail, o que também melhora a taxa de conclusão.” – Matthias Keller

As chaves de acesso são uma solução de autenticação nova e inovadora que oferece benefícios significativos em relação às senhas tradicionais. O KAYAK é um ótimo exemplo de como uma organização pode melhorar a segurança e a usabilidade do seu processo de autenticação integrando chaves de acesso. Se você procura uma experiência de autenticação mais segura e fácil de usar, recomendamos que você considere o uso de chaves de acesso com a API Credential Manager do Android .

Login sem senha com senhas de acesso 

Chaves de acesso

As chaves de acesso são uma alternativa mais fácil e segura do que as senhas. Com as chaves de acesso, os usuários podem fazer login em apps e sites com um sensor biométrico (como impressão digital ou reconhecimento facial), PIN ou padrão, sem precisar lembrar e gerenciar senhas.

Desenvolvedores e usuários odeiam senhas: eles proporcionam uma experiência ruim para o usuário, incluem barreiras na conversão e criam riscos para a segurança tanto para usuários quanto desenvolvedores. O Gerenciador de senhas do Google no Android e no Chrome reduz as complicações pelo preenchimento automático. Para desenvolvedores que buscam ainda mais melhorias na conversão e na segurança, as chaves de acesso e a federação de identidade são as abordagens modernas do setor.

Uma chave de acesso pode atender aos requisitos de autenticação multifator em uma única etapa, substituindo uma senha e uma OTP (por exemplo, um código SMS de seis dígitos) para oferecer proteção robusta contra ataques de phishing e evita problemas de UX com senhas únicas por SMS ou baseadas em apps. Como as chaves de acesso são padronizadas, uma única implementação permite uma experiência sem senha em todos os dispositivos do usuário, em diferentes navegadores e sistemas operacionais.

Chaves de acesso são mais fáceis:

  • Os usuários podem selecionar uma conta para fazer login. Não é necessário digitar o nome de usuário.
  • Os usuários podem fazer a autenticação usando o bloqueio de tela do dispositivo, como um sensor de impressão digital, reconhecimento facial ou PIN.
  • Depois que uma chave de acesso é criada e registrada, o usuário pode alternar facilmente para um novo dispositivo e usá-lo imediatamente, sem precisar se registrar novamente (ao contrário da autenticação biométrica tradicional, que exige a configuração em cada dispositivo).

Chaves de acesso são mais seguras:

  • Os desenvolvedores só salvam uma chave pública no servidor em vez de uma senha, o que significa que há muito menos valor para um usuário de má-fé invadir servidores e muito menos para limpar em caso de violação.
  • As chaves de acesso protegem os usuários contra ataques de phishing. As chaves de acesso funcionam apenas nos sites e apps registrados. Um usuário não é induzido a fazer a autenticação em um site enganoso porque o navegador ou o SO processa a verificação.
  • As chaves de acesso reduzem os custos de envio de SMS, tornando-as um meio mais seguro e econômico de autenticação de dois fatores.

Uma chave de acesso é uma credencial digital vinculada a uma conta de usuário e a um site ou aplicativo. Com as chaves de acesso, os usuários podem fazer a autenticação sem precisar inserir um nome de usuário ou senha, além de fornecer qualquer fator de autenticação adicional. O objetivo dessa tecnologia é substituir mecanismos de autenticação legados, como senhas.

Quando um usuário quiser fazer login em um serviço que usa chaves de acesso, o navegador ou sistema operacional vai ajudar a selecionar e usar a chave de acesso correta. A experiência é parecida com o funcionamento atual das senhas salvas. Para garantir que apenas o proprietário legítimo possa usar uma chave de acesso, o sistema vai pedir que ele desbloqueie o dispositivo. Isso pode ser realizado com um sensor biométrico (como impressão digital ou reconhecimento facial), PIN ou padrão.

Para criar uma chave de acesso para um site ou app, primeiro o usuário precisa se registrar nele.

  1. Acesse o aplicativo e faça login usando o método atual.
  2. Clique no botão Criar uma chave de acesso.
  3. Verifique as informações armazenadas com a nova chave de acesso.
  4. Use o desbloqueio de tela do dispositivo para criar a chave de acesso.

Quando ele voltar a esse site ou app para fazer login, poderá seguir estas etapas:

  1. Acesse o aplicativo.
  2. Toque no campo do nome da conta para mostrar uma lista de chaves de acesso em uma caixa de diálogo de preenchimento automático.
  3. Selecionar a senha de acesso
  4. Use o desbloqueio de tela do dispositivo para concluir o login.

O dispositivo do usuário gera uma assinatura com base na chave de acesso. Essa assinatura é usada para verificar a credencial de login entre a origem e a chave de acesso.

Um usuário pode fazer login em serviços em qualquer dispositivo usando uma chave de acesso, não importa onde ela está armazenada. Por exemplo, uma chave de acesso criada em um smartphone pode ser usada para fazer login em um site em outro laptop.

As chaves de acesso são destinadas ao uso na infraestrutura do sistema operacional que permite que os gerenciadores de chaves de acesso criem, façam backup e as disponibilizem para os aplicativos em execução nesse sistema operacional. No Android, as chaves de acesso podem ser armazenadas no Gerenciador de senhas do Google, que sincroniza as chaves de acesso entre os dispositivos Android do usuário conectados à mesma Conta do Google. As chaves de acesso são criptografadas com segurança no dispositivo antes de serem sincronizadas e exigem a descriptografia em novos dispositivos. Os usuários com o SO Android 14 ou mais recente podem optar por armazenar as chaves de acesso em um gerenciador de senhas de terceiros compatível.

Os usuários não têm restrição de usar as chaves de acesso apenas no dispositivo em que estão disponíveis. As chaves de acesso disponíveis em smartphones podem ser usadas ao fazer login em um laptop, mesmo que não esteja sincronizada, desde que o smartphone esteja perto do laptop e o usuário aprove o login. Como as chaves de acesso são criadas com base nos padrões FIDO, todos os navegadores podem adotá-las.

Por exemplo, um usuário visita example.com no navegador Chrome na máquina Windows. Esse usuário já fez login em example.com no dispositivo Android e gerou uma chave de acesso. Na máquina Windows, o usuário escolhe fazer login com uma chave de acesso de outro dispositivo.

Os dois dispositivos serão conectados, e o usuário vai precisar aprovar o uso da chave de acesso no dispositivo Android, por exemplo, com um sensor de impressão digital. Depois disso, o usuário está conectado na máquina Windows. A chave de acesso não é transferida para a máquina Windows. Portanto, normalmente, example.com oferece a opção de criar uma nova chave de acesso. Dessa forma, não será necessário usar o telefone na próxima vez que o usuário quiser fazer login. Leia Login com um smartphone para saber mais.

Vários serviços já usam chaves de acesso nos sistemas deles.

Teste as chaves de acesso nesta demo: https://passkeys-demo.appspot.com/

  • O login com biometria pode passar a impressão falsa de que os usuários estão enviando informações sensíveis ao servidor. Na realidade, o material biométrico nunca sai do dispositivo pessoal do usuário.
  • As chaves de acesso sozinhas não permitem rastrear usuários ou dispositivos entre sites. A mesma chave de acesso nunca é usada em mais de um site. Os protocolos de chave de acesso são projetados com cuidado para que nenhuma informação compartilhada com sites possa ser usada como um vetor de rastreamento.
  • Os gerenciadores de chaves de acesso protegem as chaves de acesso contra acesso e uso não autorizados. Por exemplo, o Gerenciador de senhas do Google criptografa chaves de acesso de ponta a ponta. Apenas o usuário pode acessá-los e usá-los e, mesmo que eles sejam salvos em backup nos servidores do Google, o Google não pode usá-los para falsificar a identidade de usuários.

 

What’s your Reaction?
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0

Sobre o Autor:

Posts relacionados
Bastidores da BFBF 2024Break FridayCorporativoHurb

Bastidores Break Friday: nossa comunicação integrada

18/11/2024
Uncategorized

O que fazer em Fernando de Noronha?

18/11/2024
Uncategorized

Pacote de Viagem - Egito - 2º Semestre 2026: uma experiência única

14/11/2024
Tecnologia

6 ferramentas essenciais para viajar

27/10/2024