Colocando uma Senha em uma Chamada da API REST

Suponha que eu tenha uma API REST que também seja usada para definir / redefinir senhas. Suponhamos também que isso funcione em conexões HTTPS. Existe algum bom motivo para não colocar essa senha no caminho da chamada, digamos também que eu a codificarei no BASE64?

Um exemplo seria redefinir uma senha como esta:

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

Entendo que o BASE64 não é criptografia, mas só quero proteger a senha para navegar no ombro neste caso.

Um bom servidor registra todas as solicitações enviadas a ele, incluindo URLs (geralmente, sem parte variável após '?'), IP de origem, tempo de execução ... Deseja realmente que esse log (potencialmente lido por um amplo grupo de administradores) contenha informações criticamente seguras como senhas? Base64 não é uma rolha contra eles.

O que você está propondo não é seguro nem RESTful.

O @Netch já mencionou o problema nos logs, mas também existe outro problema, no qual você está mostrando senhas enviadas por HTTP, tornando trivial capturar senhas com qualquer tipo de farejador de fio ou ataque man-in-the-middle.

Quando você faz uma solicitação GET usando REST, os diferentes elementos na URL representam elementos mais refinados. Seu URL parece que você está retornando uma parte NEWPASSWD de um OLDPASSWD que faz parte de uma senha redefinida. Isso não faz nenhum tipo de sentido semântico. GETs não devem ser usados ​​para salvar dados.

Você deveria estar fazendo algo assim:

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

POST porque você está gravando dados e https porque você não deseja que ele cheire.

(Essa é realmente a segurança de barra baixa. O mínimo absoluto que você deve fazer.)

O esquema proposto tem problemas em várias áreas.

Segurança

Os caminhos de URL são freqüentemente registrados; colocar senhas unidas no caminho é uma prática ruim.

HTTP

As informações de autenticação / autorização devem aparecer no cabeçalho da autorização. Ou, potencialmente, para itens baseados em navegador, o cabeçalho Cookie.

DESCANSAR

Os verbos como resetpasswordno seu URL geralmente são um sinal claro de um paradigma de transferência de estado não representacional. Um URL deve representar um recurso. O que significa GET resetpassword? Ou excluir?

API

Esse esquema exige sempre o conhecimento da senha anterior. Você provavelmente desejará permitir mais casos; por exemplo, a senha é perdida.

Você pode usar a autenticação Básica ou Digest , que são esquemas bem compreendidos.

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

Ele não coloca informações ultra-sensíveis no caminho e segue as convenções HTTP e REST.

Se você precisar permitir algum outro modo de autorização (por exemplo, algum token enviado por um canal verificado para redefinir a senha), você pode simplesmente usar um cabeçalho de Autorização diferente sem precisar alterar mais nada.

Além da segurança, o problema é que não é uma abordagem muito RESTful.

OLDPASSWDe NEWPASSWDnão represente nada na hierarquia de recursos e, pior ainda, a operação não é idempotente.

Portanto, você só pode usar POSTcomo seu verbo e não deve incluir as duas senhas no caminho do recurso.

O problema é evitar senhas de texto sem formatação em suas solicitações. Existem duas opções para atender aos requisitos de serviço da web.

1. Hash do lado do cliente

• Eu acho que você está armazenando suas senhas como, por exemplo, hash (senha + salt)
• Você pode fazer o hash da nova senha com um sal no lado do cliente
• Isso significa: Crie um novo salt no lado do cliente, crie um hash, por exemplo, hash (newPassword + newSalt)
• Envie o novo hash criado mais o sal para o seu serviço da web
• Envie a senha antiga também como hash (oldPassword + oldSalt)

2. Criptografia

• Crie um recurso "chave única" (otk) para um usuário como / otk / john
• Este recurso retorna uma chave única aleatória segura segura, por exemplo, kbDlJbmNmQ0Y0SmRHZC9GaWtRMW0ycVJpYzhMcVNZTWlMUXN6ZWxLdTZESFRs e um ID exclusivo, por exemplo, 95648915125
• Seu serviço web repousante deve armazenar esse otk aleatório para a próxima comunicação segura com o ID 95648915125
• Criptografe sua senha nova e antiga com o otk, por exemplo, AES (por motivos de segurança, você deve usar dois otks separados para a senha antiga e nova)
• Envie as senhas criptografadas para o recurso de alteração de senha com o ID 95648915125
• Uma combinação otk e ID pode funcionar apenas uma vez; portanto, você deve excluir essa combinação depois de procurar a senha
• Possível opção melhor: envie a senha atual / antiga por Basic-Auth.

Nota: HTTPS é necessário para ambas as opções!

Quais são os recursos de uma operação de redefinição de senha?

1. Isso muda alguma coisa.
2. Há um valor que está definido como.
3. Somente algumas pessoas têm permissão para fazer isso (o usuário, um administrador ou qualquer um, talvez com regras diferentes sobre como fazê-lo).

O ponto 1 aqui significa que você não pode usar GET, você deve POST algo representando a operação de alteração de senha em um URI que representa um recurso que lida com alterações de senha ou PUT algo que representa a nova senha em um URI que representa a senha ou representa algo (por exemplo, o usuário) cuja senha é um recurso.

Geralmente, nós POSTAMOS, não menos importante, porque pode ser estranho COLOCAR algo que não podemos obter mais tarde e, é claro, não podemos obter a senha.

O ponto 2, portanto, serão os dados que representam a nova senha, no que é POSTADO.

O ponto 3 significa que precisaremos autorizar a solicitação, o que significa que, se o usuário for o usuário atual, precisaremos que a senha atual seja comprovada (embora não necessariamente receba a senha atual, se, por exemplo, um desafio baseado em hash foi usado para provar o conhecimento dele sem enviá-lo).

O URI deve, portanto, ser algo como <http://example.net/changeCurrentUserPassword>ou <http://example.net/users/joe/changePassword>.

Podemos decidir que queremos receber a senha atual nos dados do POST, bem como no mecanismo de autorização geral que está sendo usado.