Les meilleures pratiques de SPA pour l'authentification et la gestion de session

cette question a été abordée, sous une forme légèrement différente, en détail ici:

"151950920 De" Repos "Authentification 151960920"

mais ceci l'adresse du côté du serveur. Regardons du côté client. Mais avant cela, il y a un prélude important:

la cryptographie Javascript est sans espoir

L'article de Matasano sur ceci est célèbre, mais les leçons qu'il contient sont assez importants:

http://www.matasano.com/articles/javascript-cryptography /

pour résumer:

• un homme-dans-l'attaque du milieu peut trivialement remplacer votre code de crypto Par <script> function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
• une attaque man-in-the-middle est triviale contre une page qui sert n'importe quelle ressource sur une connexion non-SSL.
• une fois que vous avez SSL, vous utilisez une vraie crypto de toute façon.

et d'ajouter un corollaire:

• une attaque XSS réussie peut entraîner l'exécution du code par un attaquant sur le navigateur de votre client, même si vous utilisez SSL - donc même si vous avez toutes les hatch battues vers le bas, votre navigateur crypto peut toujours échouer si votre attaquant trouve un moyen d'exécuter n'importe quel code javascript sur le navigateur de quelqu'un d'autre.

cela rend beaucoup de repos les schémas d'authentification impossible ou stupide si vous avez l'intention d'utiliser un client JavaScript. Voyons!

HTTP Basic Auth

tout d'abord, HTTP Basic Auth. Le plus simple des schémas: il suffit de passer un nom et un mot de passe avec chaque requête.

cela, bien sûr, nécessite absolument SSL, parce que vous passez un nom codé Base64 (réversiblement) et un mot de passe avec chaque requête. N'importe qui écoutant sur la ligne pourrait extraire nom d'utilisateur et mot de passe trivialement. La plupart des arguments" Basic Auth is insecure "viennent d'un endroit de" Basic Auth over HTTP " ce qui est une idée terrible.

le navigateur fournit la prise en charge HTTP Basic Auth dans le paquet, mais elle est aussi laide que sin et vous ne devriez probablement pas l'utiliser pour votre application. L'alternative, cependant, est de cacher le nom d'utilisateur et le mot de passe dans JavaScript.

c'est la solution la plus reposante. Le serveur n'exige aucune connaissance d'état que ce soit et authentifie chaque interaction individuelle avec l'utilisateur. Certains adeptes du repos (principalement des hommes de paille) insistent sur le fait que le maintien de n'importe quelle sorte d'état est hérétique et va mousser à la bouche si vous pensez à n'importe quelle autre méthode d'authentification. Il y a des avantages théoriques à ce genre de normes-la conformité - il est soutenu par Apache hors de la boîte - vous pourriez stocker vos objets en tant que fichiers dans des dossiers protégés par .htaccess si votre cœur désirée!

Le problème ? Vous mettez en cache du côté client un nom d'utilisateur et un mot de passe. Cela donne evil.ru une meilleure fissure - même la plus élémentaire des vulnérabilités XSS pourrait amener le client à transmettre son nom d'utilisateur et son mot de passe à un serveur malveillant. Vous pouvez essayer d'atténuer ce risque en tapant sur le clavier et en salant le mot de passe, mais rappelez-vous: la cryptographie JavaScript est sans espoir . Vous pouvez atténuer ce risque en laissant le support de base de L'auteur du navigateur, mais.. laids comme le péché, comme mentionné plus tôt.

HTTP Digest Auth

Est l'authentification Digest possible avec jQuery?

Un plus "secure" auth, c'est une demande/réponse de hachage défi. Sauf JavaScript Crypto est sans espoir , donc il ne fonctionne que sur SSL et vous devez toujours mettre en cache le nom d'utilisateur et le mot de passe du côté du client, ce qui le rend plus compliqué que HTTP Basic Auth mais pas plus sécurisez .

interrogation authentification avec paramètres de Signature supplémentaires.

un autre auth plus "sécurisé", où vous cryptez vos paramètres avec des données nonce et timing (pour vous protéger contre les attaques répétées et timing) et envoyez le. Un des meilleurs exemples de cela est le protocole OAuth 1.0, qui est, pour autant que je sache, une façon assez rudimentaire d'implémenter l'authentification sur un serveur REST.

http://tools.ietf.org/html/rfc5849

Oh, mais il n'y a pas de clients OAuth 1.0 Pour JavaScript. Pourquoi?

la cryptographie JavaScript est sans espoir , rappelez-vous. JavaScript ne peut pas participer à OAuth 1.0 sans SSL, et vous devez encore stocker le nom d'utilisateur et le mot de passe du client localement - ce qui met cela dans la même catégorie que Digest Auth - c'est plus compliqué que HTTP Basic Auth mais c'est pas plus sécurisez .

Jeton

l'utilisateur envoie un nom d'utilisateur et un mot de passe, et en échange obtient un token qui peut être utilisé pour authentifier des requêtes.

c'est légèrement plus sûr que HTTP Basic Auth, car dès que la transaction nom d'utilisateur/mot de passe est terminée, vous pouvez jeter les données sensibles. C'est aussi moins reposant, car les tokens constituent "l'état" et rendent l'implémentation du serveur plus compliquée.

SSL Still

le hic, cependant, est que vous devez toujours envoyer ce nom d'Utilisateur initial et mot de passe pour obtenir un token. Les informations sensibles touchent toujours votre JavaScript compromissible.

pour protéger les informations d'identification de votre utilisateur, vous devez toujours garder les attaquants hors de votre JavaScript, et vous avez toujours besoin d'envoyer un nom d'utilisateur et un mot de passe par le fil. SSL requis.

Expiration Du Jeton

c'est commun pour appliquer des politiques de token comme " hey, quand ce token a été autour trop longtemps, le jeter et faire l'utilisateur authentifier à nouveau."ou "je suis presque sûr que la seule adresse IP autorisée pour utiliser ce token est XXX.XXX.XXX.XXX ". Nombre de ces politiques sont très bonnes idées.

feu de cheminée

cependant, l'utilisation D'un token sans SSL reste vulnérable à une attaque appelée "sidejacking": http://codebutler.github.io/firesheep /

L'attaquant ne reçoit pas les informations d'identification de votre utilisateur, mais ils peuvent toujours prétendre être votre utilisateur, ce qui peut être assez mauvais.

tl;dr: L'envoi de jetons non cryptés sur le fil signifie que les attaquants peuvent facilement attraper ces jetons et prétendre être votre utilisateur. FireSheep est un programme qui rend cela très facile.

Un Autre, Plus Secure Zone

plus l'application que vous utilisez est grande, plus elle est dure est de s'assurer absolument qu'ils ne seront pas en mesure d'injecter un code qui change la façon dont vous traitez les données sensibles. Faites-vous absolument confiance à votre CDN? Vos annonceurs? Votre propre base de code?

commun pour les détails de carte de crédit et moins commun pour le nom d'utilisateur et le mot de passe - certains responsables de la mise en œuvre conservent la "saisie de données sensibles" sur une page séparée du reste de leur application, une page qui peut être étroitement contrôlée et verrouillée de la meilleure façon possible, de préférence une page qui est difficile pour phish utilisateurs.

Cookie (signifie simplement Token)

il est possible (et courant) de placer le token d'authentification dans un cookie. Cela ne change aucune des propriétés d'auth avec le token, c'est plus pratique. Tous ces arguments s'appliquent toujours.

Session (toujours moyen de Jeton)

session Auth n'est qu'une authentification de jeton, mais avec quelques différences qui le font paraître comme une chose légèrement différente:

• les utilisateurs commencent avec un token non authentifié.
• le backend maintient un objet 'state' qui est lié au token d'un utilisateur.
• le token est fourni dans un cookie.
• l'environnement d'application résume les détails loin de vous.

mis à part cela, il n'est pas différent de Token Auth, vraiment.

cela va encore plus loin d'une implémentation reposante - avec les objets de l'état, vous allez de plus en plus loin sur le chemin du simple Vieux RPC sur un serveur de l'état.

OAuth 2.0

OAuth 2.0 se penche sur le problème de "comment un logiciel a donne-t-il au logiciel B l'accès aux données de L'utilisateur X sans que le logiciel B ait accès aux identifiants de connexion de L'utilisateur X."

la mise en œuvre est très juste un moyen standard pour un utilisateur de obtenir un token, et puis pour un service tiers de faire "yep, cet utilisateur et ce token correspondent, et vous pouvez obtenir certaines de leurs données de nous maintenant."

fondamentalement, cependant, OAuth 2.0 est juste un protocole symbolique. Il présente les mêmes propriétés que les autres protocoles de tokens - vous avez encore besoin de SSL pour protéger ces tokens - il change simplement la façon dont ces tokens sont générés.

il y a deux façons que OAuth 2.0 peut vous aider:

• fourniture D'une authentification/Information à autrui
• obtention D'une authentification/Information d'autrui

mais quand il s'agit de ça, vous êtes juste... à l'aide de jetons.

retournez à votre question

donc, la question que vous posez est " devrais-je stocker mon token dans un cookie et avoir la gestion de session automatique de mon environnement prendre soin des détails, ou devrais-je stocker mon token en Javascript et gérer ces détails moi-même?"

Et la réponse est: faites ce qui vous rend heureux .

la chose à propos de la gestion automatique des sessions, cependant, c'est qu'il y a beaucoup de magie qui se passe dans les coulisses pour vous. Souvent, il est plus agréable d'être dans le contrôle de ces informations.

je suis 21 SSL est oui

l'autre réponse est: utilisez https pour tout ou les brigands voleront les mots de passe et les jetons de vos utilisateurs.