[venomsnake]

That is obviously sloppy work on the part of the developers. And bad. But anyone that can snoop on loopback already owns the machine and he could just cheat engine the passwords from the browser ram.

So it is not making safe situation bad, but bad situation worse. Of course with Blizzard Warden, Steam anti cheat, driver level firewalls and all the other little helpers that collect information about your system - this could lead to a leak to some entity's logs in the cloud.

[elbigbad]

I have a problem with the phrase "obviously sloppy work on the part of the developers." How exactly does one avoid loopback in an application like this?

Your second point is spot on though I think, one would need to own the machine already before being able to sniff loopback.

[venomsnake]

Sending in plaintext is sloppy. You can have any protocol over loopback.

[jpgoldberg]

And where would you store the keys for that communication in a way that an attacker with root privileges couldn't get it? "Encrypting" with keys available to the attacker is mere obfuscation. In this case, it would provide no extra security to customers; all it would do is lead them to believe that something is encrypted when it is merely obfuscated.

[julie78787]

Except that you can attack stored encryption secrets either off-line, or with the same privileges as the user.

If they are hard-coded in the binary, they can be extracted off-line by another use with the same binary. If they are generated at run-time, they have to be stored with permissions that grants the user access to their own resource.

There are programming techniques for sharing a file descriptor, but they aren't portable. That makes generating a keypair, then sharing an open file descriptor to the file containing the keypair impossible.