Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
spacem18446yOn no they send password to servers in plaintext... I hope my furniture will not get hacked by hackers now.
-
Root823426yPasswords 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. -
Kimmax111096yHere 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?
-
Kimmax111096y@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
-
@teganburns My point still stands, GET has the same security as POST. I didn't mention design standpoints.
-
Root823426y@joas The point is to prevent interception of the cleartext password, as @sSam said, not to replace encryption entirely.
-
Root823426y@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. -
dfox428426yThere’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. -
dfox428426ySome 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. -
Kimmax111096y@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
-
joas19446y@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. -
sSam15016y@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. -
Kimmax111096y@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
-
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.
-
dfox428426y@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.
-
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.
Related Rants
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 🤔
rant
plaintext
psa
at least it's ssl
flaw
security
password
ikea