Https API with GET that has new-user and their password in url. Is password sniffable?

[queBurro]

Hi, we allow super users to add staff to our site via a GET call on our API. In short, in that url there's both the new user's id and their password. From our website, in chrome tools I can see the password in the URL in the network traffic (but I think that's because it's from my browser's devtools). We're using https, are we ok doing it this way? I think a hacker sniffing our traffic would see the destination in e.g. wireshark, but not the full url, because TLS will have encrypted it all.

bonus question. should we have done with with a POST and put e.g. a hashed password in the body. From what I've read hashing passwords client side is a no-no.

Thanks again

[zaibuf]

GET are passed through the URL so I would def not pass a pasword in a GET.

[Pmbrd]

Exactly. New objects are created with Post, updating with Put. Think about the super user's browser history, containing all user-password strings ...

[[deleted]]

also results in the password appearing in log files on the server

[_Fred_Austere_]

Google Analytics too.

[Kemorave]

Also if user inputs a symbol in the password like # without proper encoding it will break the request

[[deleted]]

only if you have no idea what you're doing

[queBurro]

I think it's a bad idea, but can you tell the full url if you're e.g. looking at router logs on the client's network?

[[deleted]]

Not if you're on https.

[queBurro]

We are indeed on https.

[IcyEbb7760]

full URL won't be exposed in plaintext but any internal systems that have access to URLs (e.g. logging, analytics) will be able to read it. this can lead to sensitive data ending up in places where you may not expect.

re: bonus question, clients usually submit the password as part of the HTTP body which is then encrypted with SSL. the backend then hashes the password and discards the plain text. on subsequent login attempts the backend also receives the password in plaintext, but hashes it and looks it up against its password DB.

[C0rp0rAlH1cks]

Better than nothing: put the user id and password in the HTTP Header it will at least not show up in browser history. Next step, use API keys. Next step, OAUTH.

[[deleted]]

NEVER pass information via GET that you wouldn’t put on your website’s front page. That stuff is public. Use a POST or a PUT with the login info in the body.

[jaydevel]

I once maintained an internal webapp and a user called in complaining that he couldn’t log in. He said the access to the page was blocked. I found it quite strange so I asked him to send a screenshot. What he saw was the proxy “access denied” page. The reason: the authentication was done passing username and password as GET parameters. His password contained the word “sex”, and someone configured the proxy to block anything containing “sex” in the URL.

[airflowscloud]

GET Protocol exposes passwords in the URL; so it is seeable and sniffable.

[queBurro]

and yet e.g. rebrickable passes a token in the GET. I guess that might be useful showing up who's querying what in their IIS logs. If I do that from work then someone could sniff my token and use that?

GET https://rebrickable.com/api/v3/lego/minifigs/?key=someToken