So according to some reddit user IKEA sends your password as a GET parameter in plain text.

https://reddit.com/r/CrappyDesign/...

Seems to be a network authentication thingy, but still 🤔

On no they send password to servers in plaintext... I hope my furniture will not get hacked by hackers now.

Remember to clear your browser history 🙈

Passwords should be hashed on the client. Trusting https isn't good enough.

Yes, you can do server-side shenanigans, too, but obfuscating passwords prior to transit is absolutely top priority.

@teganburns Auth tokens are a huge difference.

@Root What's the point of hashing the password on the client side?
The hash would just be another representation of the password which a man in the middle (or someone else) could capture and then use it to authenticate

@Panni so you know only the hashed version and not the clear text password, thus you can't reuse it for other services as a lot of people have the same password for all their services.

@spacem this can be huge risk for people have a universal password...

Here we go again:
https://devrant.com/rants/1256569/...
Applies to passwords as well. No difference between GET and POST in security, well if you ignore the browser history, but auto redirects and XHR requests shouldn't go in there anyway

@teganburns You do know that DevRant uses HTTPS so GET and POST is essentially the same in terms of security, right?

@teganburns any sort of session you get when clicking that nasty "keep me logged in" button also never expires. At least not on any major site I use out there. Session id's are just as valuable and are also being transfered on every request

I still would never put regular form data in GET requests.

@Meta Reasoning behind that?

@PrivateGER Exactly what @teganburns said.

@Root @sSam
Maybe encryption of the password manually on client side would make sense if server and client could come up with encryption keys without actually sending them ov... Oops, nope, we invented the wheel again.

@teganburns My point still stands, GET has the same security as POST. I didn't mention design standpoints.

@joas The point is to prevent interception of the cleartext password, as @sSam said, not to replace encryption entirely.

@Root
Okay, it would stop people behind user's back to steal the password stored in GET parameters, but wouldn't really provide any additional protection against MITM. At that point you should just stick to not showing the password on screen at all.

@joas one-way hashing.
If you intercept the hash via a mitm attack, packet sniffing, ssl inspection, etc., and you know the hashing algo, it'll still take you a prohibitively long time to reverse the hash and get the original password. (Interestingly, collisions would actually help here, as they'd give false positives.)

Rainbow tables? Mitigated by salt.

There isn't a downside apart from the extra effort to implement.

There’s a lot of misinformation here so it should be cleared up.

There’s a basic security concept that many, many developers seem to not understand: when you send data via https, whether post or get, it is encrypted. Post requests are no more secure than get requests in terms of “plaintext” or whatever terms might be used. Get requests are not transmitted as “plaintext.” They are encrypted when transmitted.

I think people are getting confused because get requests are slightly more visible to them in their browser, but they are losing the point that the data is treated the same was as an https post request body.

When you build an API, you chose http verbs based on what the endpoint does. For instance, if you’re getting data, whether an auth token/password needs to be included or not, you use a get request. That’s proper API building 101.

@PrivateGER I think a lot of people aren’t understanding that concept TBH.

Some more clarification: a number of people in this comment thread are also missing the differences between normal webpage interactions (POST vs GET) and the usage of GET, POST, PATCH, etc. in a REST API. You would not want to use GET for a normal form to send a password/sensitive information because that url could stick around in history/possibly be copied out by the user. Or in the case of the IKEA practice, it’s bad because it looks like the password was included in the email? But to reiterate again, that specific case is insecure because of the local consequences. The data is perfectly safe in terms of transmission and visibility to outside sources. It’s encrypted.

When it comes to REST APIs, you use the appropriate verb. It is perfectly acceptable and secure to send auth tokens and passwords via GET requests in the url string. You generally wouldn’t send a password through GET because a POST request would be more appropriate to generate an auth token from a password, but sending auth tokens via GET requests is secure, frequently done, and proper semantic REST API building. All methods are equally secure.

Also, I encourage everyone to read @Kimmax’s rant linked above :)

@Condor if someone pulls a man in the middle on you, you have bigger problems. And if he does, he could also simply inject a legit looking e.g. paypal login form, including a valid and correctly named certificate (since you trust the attackers CA) and ask for your password and worse

@Condor @Root

I'm thinking that there would be good use for non-reversable password hashing with locally stored salt to protect against poor security of smaller websites if you can't come up with complitely unique for every singe site (like the most of us).

It would have to be baked in to a browser or added by extension. There's some existing but aren't quite well known.

The other way is to use password manager, but they are either too much hassel or can't trust them enough.

@Condor
Only if there were oAuth provider that doesn't integrate access it's own services and it was implemented everywhere on the web.

@Condor
Oh, thanks I'll check it out.

@joas hashing client-side has nothing to do with GET vs POST. Like stated before, it prevents listener(MITM) getting clear text password.

@Condor how does server-side hashing prevent hashing collisions? If you don't hash client-side you don't need to input the exact password, you need to input password that results in correct hash on server-side.

Since all normal websites use HTTPs anyways the biggest threat MITM poses is replaying attacks? To protect against it you can:

xyz - random bits

Client: send to server - xyz+hash(hash(password)+xyz)

Server: checks hash(xyz+savedHashedPsw)==receivedHash

@joas your local salt solution is exactly the same as simple password manager.

@Kimmax @dfox I think better discussion would be "visible in address bar GET" vs "not visible GET" requests. In my opinion, if visible GET contains sensitive information it's a security issue as the link can be shared or screenshot by accident.

@sSam and I can send out my password via mail on accident. It's a user problem, these links are meant to be called from scripts etc. invisible for the normal user. If you choose to open your dev tools, that's your thing

@Kimmax yeah, that's what I meant, links that are visible to normal user shouldn't contain sensitive information, but the ones that are invisible can.

It happened to me not long ago: I asked a friend for the URL of some website, and he copied the URL from the address bar of his browser and sent it to me. That URL contained the token so I could login in their account.

@sSam yeah, visible links shouldn’t contain tokens/passwords, but I think people are getting tripped up because they are just talking about get vs post instead of normal web requests for web pages instead of differentiating between those and xhr requests to REST APIs which I’d argue are even more common now. Like it’s already been said, ajax requests to REST APIs in the browser are not visible to the user and get vs post are more or less equally as secure.

Dam!

Eh, most APIs use this method which is why you never log into your bank account on a public network.

The concept of frontend hashing is stupid and provides nothing in case of mitm, the hacker already has your hashing js algorithm, he can even change it.