2017-05-11 1 views
0

J'essaie de comprendre comment curl -u est sûr à utiliser avec un vrai nom d'utilisateur et mot de passe. En examinant l'en-tête d'une telle requête, il semble que le nom d'utilisateur et le mot de passe sont transformés en une sorte de hachage.Comment cUrl -u transforme-t-il le nom d'utilisateur et le mot de passe en hash?

Dans l'exemple ci-dessous, il semble jujuba:lalalala est tourné à anVqdWJhOmxhbGFsYWxh

Est-ce cryptage ou de compression? Est-ce sûr? Comment le destinataire décode-t-il ces données?

curl -u jujuba:lalalala -i -X Get http://localhost:80/api/resource -v 

* timeout on name lookup is not supported 
* Trying 127.0.0.1... 
    % Total % Received % Xferd Average Speed Time Time  Time Current 
           Dload Upload Total Spent Left Speed 
    0  0 0  0 0  0  0  0 --:--:-- --:--:-- --:--:--  0* Connected to localhost (127.0.0.1) port 80 (#0) 
* Server auth using Basic with user 'jujuba' 
> Get /api/resource HTTP/1.1 
> Host: localhost 
> Authorization: Basic anVqdWJhOmxhbGFsYWxh 
+2

L'authentification de base utilise simplement le codage Base64 pour l'en-tête. Il n'est pas sécurisé du tout sauf si la connexion est cryptée (par exemple en utilisant HTTPS). –

+0

Y a-t-il une raison de le faire si ce n'est pas sécurisé? Il ne semble pas particulièrement compressé. –

+1

[RFC 2617, Section 2] (https://tools.ietf.org/html/rfc2617#section-2) couvre la spécification de l'authentification de base HTTP; C'est comme cela que les clients créent ce hachage et comment les serveurs vont le gérer. – Castaglia

Répondre

2

Si vous exécutez la commande:

echo anVqdWJhOmxhbGFsYWxh | base64 -d 

Vous obtiendrez jujuba:lalala montrant que le contenu est juste 64 Base de encodée, qui est la norme pour l'authentification de base.

Vous devez utiliser HTTPS pour tout site nécessitant une authentification.

+0

En effet. Voir la spécification: https://greenbytes.de/tech/webdav/rfc7617.html#rfc.section.4.p.3 –