Login via un clefs publique/privée RSA?

[Xenos]

Salutations,

ça m'est venu à l'esprit, mais les connections SSH se font sans mot de passe (on rajoute la clef publique RSA du client, et le client peut se connecter au SSH sans entrer le moindre mot de passe).

Vous avez vent de sites, jeux (lol, je pense que non mais bon ) qui utiliseraient ce genre de méthode pour se logguer au site? Plutôt qu'un mot de passe?

Bon, c'est hyper-expérimental et je ne pense pas que ce soit vraiment très "user-friendly", mais pour la curiosité et l'amusement d'essayer, je suis tenter d'intégrer ça à ECLERD ou à Variispace

[julp]

On peut "nativement" faire quelque chose de très proche avec le SSL/HTTPS sauf que ça implique que tu génères tes propres certificats et comme l'ensemble sera auto-signé, ça n'aura guère de valeur au final. (sans compter que ça requerra sans doute certaines manipulations de la part de l'utilisateur)

Autrement, via un navigateur, ça me paraît compliqué pour un résultat qui ne me paraît pas plus sûr.

[Xenos]

Je ne parle pas de connexion par certificat, juste via le même système de clef RSA (publique privée) qu'utilise SSH (donc, pas de signature). Je ne vois pas trop le lien avec SSL du coup?

En revanche, oui, c'est pour la curiosité Mais je pense que ce serait beaucoup plus sûr qu'un login par mot de passe (sinon, on n'utiliserait pas ça pour les connexions SSH )

[Maz]

Pousse le vice! Avec une authentification par empreinte digitale!

[Meraxes]

Mais du coup, si un joueur perd sa clé privé (par exemple, sa machine est HS), il ne peut plus s'authentifier ?

Sauf si tu ajoutes un mécanisme de "régénération des clés" (par mail, sms ou autre).

C'est plus injuste que le cas où on oublie son mot de passe (parce qu'il y a moins de probabilité, je pense, que ce soit de la faute de l'utilisateur, à l'inverse d'un oubli de mdp).

Et si j'ai bien compris ce que tu veux faire, alors ça risque d'être un peu compliqué, aussi, de gérer un joueur qui se connecte depuis plusieurs machines différentes.

[Xenos]

Oui, si tu perds ta clef privée, c'est comme si tu perdais ton mot de passe... Reste plus qu'à reset tout ça (par mail, en effet) !

Je ne regénère aucune clef, c'est à l'utilisateur de la regénérer et de réuploader une nouvelle clef publique éventuellement.

La clef privée est un fichier, tu peux la trimballer entre plusieurs PC sans problème (ie: la mienne est dans KeePass, sur une clef USB en gros, et je peux la ballader comme un mot de passe entre mon desktop et mon laptop). En revanche, c'est évidemment juste pour le fun d'essayer: je conserverai le mot de passe, car 99% des gens utiliseront ça : ) la clef privée/publique, c'est pour rigoler un coup (j'ai des façons de me marrer très spéciales!) .

[Xenos]

Bon, finalement, c'est rigolo à implémenter, mais totalement inutile et impossible à présenter potablement aux utilisateurs

Dans le proto que j'ai fait et jeté direct, j'avais stocké la clef publique côté serveur (déjà, le client doit l'uploader, donc c'est pas top pour l'ux), et à la connexion, le client va chercher le fichier de sa clef privée (moisi également car non-enregistré par le navigateur), puis la CryptoAPI JS lit la clef (bien bien chiant à faire!), signe le pseudo du joueur (donc, le client doit aussi entrer son pseudo...), envoie le pseudo & signature au serveur, qui vérifie que le pseudo existe en DB pour récupérer l'ID du joueur (je n'économise même pas l'appel à la DB...), puis le serveur va chercher la clef publique stockée, et il vérifie que la signature du pseudo est valide pour cette clef publique (c'est le seul truc facile: openssl_verify en PHP)

Je laisse donc tomber
Les alternatives que je me suis amusé à explorer au passage:
- Authentification via www-authenticate: je ne suis pas allé très loin, puisqu'au final, cela sert juste à faire une autre interface pour demander le login & password du joueur, et que ces infos traineront dans les headers inutilement (je pensais pouvoir me passer de la session grâce à ça, mais cela impliquerait que ma session ne stocke que le login du joueur; or déjà, elle stocke l'id et non le pseudo et je ne m'interdis pas d'y stocker 2-3 autres infos si besoin)
- Authentification via certificat: j'aurai pû/dû aller plus loin car c'est intéressant comme concept, mais je n'ai pas réussi à charger mon certificat dans le navigateur et je ne suis même pas sûr de pouvoir le récupérer côté PHP pour ensuite le valider par le serveur... C'est probablement négocié plus bas dans la stack réseau, donc tant pis...

Bon, ben ce fut une belle idée inutile