Esta solução é RESTful e segura?

Nosso produto registra novos players em nosso serviço e optamos por hospedá-lo no Azure (estamos usando .NET) e queríamos que fosse sem estado (para escalabilidade) e relativamente seguro.

Como este é o primeiro WS REST que estou escrevendo, eu gostaria de obter algum feedback sobre se é ou não uma solução sólida.

Algumas presunções para saber sobre o nosso aplicativo:

1. Os usuários estão logados no serviço anonimamente, sem exigir uma senha de um usuário
2. O WS deve ser completamente sem estado para permitir o dimensionamento horizontal
3. Estamos nos conectando usando HTTPS (SSL) para impedir a invasão de terceiros

EDITAR:

1. Temos como alvo dispositivos iOS / Android nativos
2. Nossa principal preocupação é garantir que apenas clientes não violados possam enviar solicitações

E o processo de autenticação abstrata:

1. O cliente cria um hash simples (UDID: Timestamp) e o criptografa usando o timestamp com algum algoritmo básico (por exemplo, chave secreta é todo segundo caractere do hash)
2. O cliente envia seu UDID, carimbo de data e hora e hash para o servidor
3. O servidor reconstrói o hash e descriptografa o hash criptografado enviado pelo usuário
4. Se os dois forem iguais - sabemos que ele foi realmente enviado de nosso cliente (e, esperançosamente, não de um remetente malicioso)

Qualquer entrada / sugestão seria ótima - obviamente, já que é a primeira vez que estou lidando com esse problema, talvez eu o tenha projetado incorretamente.

Obrigado!

2ª atualização:

Lendo as especificações de segurança do OAuth, parece que não há resposta real para minha pergunta - já que o cliente e o servidor precisam conhecer as chaves secretas e o cliente é armazenado localmente nos dispositivos móveis de nossos usuários (em oposição a um aplicativo Web).

No guia de segurança do OAuth ( http://hueniverse.com/oauth/guide/security/ ):

Ao implementar o OAuth, é fundamental entender as limitações de segredos compartilhados, simétricos ou assimétricos. O segredo do cliente (ou chave privada) é usado para verificar a identidade do cliente pelo servidor. No caso de um cliente baseado na Web, como um servidor Web, é relativamente fácil manter o segredo do cliente (ou chave privada) em sigilo.

No entanto, quando o cliente é um aplicativo de desktop, um aplicativo móvel ou qualquer outro software do lado do cliente, como applets de navegador (Flash, Java, Silverlight) e scripts (JavaScript), as credenciais do cliente devem ser incluídas em cada cópia do aplicativo . Isso significa que o segredo do cliente (ou chave privada) deve ser distribuído com o aplicativo, o que herda de comprometimento.

Isso não impede o uso do OAuth dentro desse aplicativo, mas limita a quantidade de confiança que o servidor pode ter em tais segredos públicos. Como os segredos não podem ser confiáveis, o servidor deve tratar esse aplicativo como entidades desconhecidas e usar a identidade do cliente apenas para atividades que não exijam nenhum nível de confiança, como coleta de estatísticas sobre aplicativos. Alguns servidores podem optar por proibir esse aplicativo ou oferecer diferentes protocolos ou extensões. No entanto, neste momento, não há solução conhecida para essa limitação.

Isso é um pouco fora da tangente, mas, do ponto de vista da segurança, qualquer segredo que esteja em um cliente não é um segredo. Você declara na sua pergunta isso.

Nossa principal preocupação é garantir que apenas clientes não violados possam enviar solicitações.

Como alguém que trabalhou na indústria de jogos, essa é uma causa perdida. Se houver valor suficiente para poder enviar solicitações arbitrárias, os usuários descobrirão como enviar essas solicitações. Você nunca pode confiar em saber se uma solicitação é de um cliente confiável. Aqui estão algumas dicas das minhas experiências.

• Mantenha a cópia canônica do estado do jogo no servidor
• Imagine o que muda para o estado que cada usuário pode fazer e faça verificações no servidor quanto à violação.
• Tenha limites de taxa de velocidade com que os usuários podem subir de nível ou ganhar moeda / itens para capturar scripts.
• Se o trapaceiro não puder lamentar, outros jogadores não os banirão. Muitos trapaceiros também gastam.
• Tenha controles sociais sobre os trapaceiros, ou seja, para que os trapaceiros se tornem óbvios para seus amigos. Se você puder ter uma lógica de correspondência, os trapaceiros serão removidos de jogar contra seus amigos.

A chave sobre o REST é que você está usando os recursos inerentes em http:

• GET: para simplesmente recuperar dados
• POST: para inserir um novo ponto de dados
• PUT: para atualizar um ponto de dados
• DELETE: para excluir um ponto de dados

Outra orientação é que seus URLs devem ser intuitivos, ou seja, se o seu URL para jogadores for http://example.com/api/playeruma maneira sensata de expor seu último histórico de pontuações http://example.com/api/player/1/scores(por exemplo, as pontuações para o ID do jogador 1).

Quanto à segurança, o que você leu nas especificações do OAuth é muito verdadeiro ... se você estiver incorporando algum tipo de chave privada em um binário em que outras pessoas possam ter as mãos, você não pode assumir que seja totalmente privado. Sugiro que, se você tiver algum tipo de chave privada em seu código, configure-a para que possa expirar e, em seguida, envie uma atualização para alterá-la. De qualquer modo, aproveite a oportunidade para protegê-lo com criptografia e todo o resto, mas facilite a desativação se for invadido. A realidade é que o twitter e outros sofrem esse mesmo desafio, onde de vez em quando as chaves secretas de seus aplicativos oficiais são descobertas e publicadas na internet, e eles precisam atualizar seus aplicativos.