[victorbjorklund]

Can someone smarter explain to me what is different between?

1) domain.com/login user: John password: 5 char random password

2) domain.com/12 char random url

If we assume both either have the same bruteforce/rate limiting protection (or none at all). Why is 1 more safe than 2?

[koliber]

From the information theory angle, there is no difference.

In practice, there is.

There is a difference between something-you-have secrets and something-you-know secrets.

A UrL is something you have. It can be taken from you if you leave it somewhere accessible. Passwords are something-you-know and if managed well can not be taken (except for the lead pipe attack).

There is also something-you-are, which includes retina and fingerprint scans.

[rkangel]

This article is the exact reason why.

(1) Requires some out-of-band information to authenticate. Information that people are used to keeping safe.

On the other hand the URLs in (2) are handled as URLs. URLs are often logged, recorded, shared, passed around. E.g. your work firewall logging the username and password you used to log into a service would obviously be bad, but logging URLs you've accessed would probably seems fine.

[the latter case is just an example - the E2E guarantees of TLS mean that neither should be accessible]

[amanda99]

Two things:

1. "Password" is a magic word that makes people less likely to just paste it into anything.

2. Username + passwords are two separate pieces of information that are not normally copy-pasted at the same time or have a canonical way of being stored next to each other.

[victorbjorklund]

1) Make sense. 2) Not sure about that. If someone shares their password with someone else they probably share both the username/email and the password

[amanda99]

Yes, people share usernames and passwords, but there's no single canonical string, like "username=amanda99&password=hithere". For example most of the time when I share user/pass combos, they are in separate messages on Signal. You type them into two different boxes, so you normally copy the username, then the password in separate actions.

[nightpool]

I mean, for HTTP Basic there literally is a single canonical string, and it's not uncommon to see people send you links like https://user:[e-mail].

I think the arguments other commenters have made about logging, browser history storage, etc are more convincing

[wetpaste]

In the context of this article, it is that security scanning software that companies/users are using seem to be indexing some of the 12-char links out of emails which ends up in some cases on public scan. Additionally, if domain.com/12-char-password is requested without https, even if there is a redirect, that initial request went over the wire unencrypted and therefore could be MITM, whereas with a login page, there are more ways to guarantee that the password submit would only ever happen over https.

[ApolloFortyNine]

I researched this a while ago when I was curious if you could put auth tokens as query params.

One of the major issues is that many logging applications will log the full url somewhere, so now your logging 'passwords'.

[laurels-marts]

You can definitely pass JWT as a query param (and often are in embedded scenarios) and no its not the same as logging passwords unless you literally place the password in the payload (which would be stupid).

[jarofgreen]

As well as what the others have said, various bits of software make the assumption that 1) may be private and to be careful with it and 2) isn't.

eg Your web browser will automatically save any URLs to it's history for any user of the computer to see but will ask first before saving passwords.

eg Any web proxies your traffic goes through or other software that's looking like virus scanners will probably log URLs but probably won't log form contents (yes HTTPS makes this one more complicated but still).

[munk-a]

Assuming that 5 char password is done in a reasonable way then that data is not part of the publicly visible portion of the request that anyone along the chain of the communication can trivially eavesdrop. In a lot of cases that password even existing (even if there's no significant data there) will transform a request from a cacheable request into an uncacheable request so intermediate servers won't keep a copy of the response in case anyone else wants the document (there are other ways to do this but this will also force it to be the case).

[kube-system]

The difference is that people (and software that people write) often treat URLs differently than a password field. 12 characters might take X amount of time to brute force, but if you already have the 12 characters, that time drops to zero.

[hawski]

You can easily make a regex to filter out URLs. There is no universal regex (other than maybe costly LLM) to match the URL, the username and the password.