It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
How do passwords work? i have a multi-user computer and so people do their own things such as set up proxies. i don't know what one really is or how safe it is. I understand proxies as a middle-man. so say i log into gog, but i did it over a proxy. are my credentials encrypted at my computer before being transmitted? or is it in plain text and only encrypted at a storage level on the server? i suppose another way of asking is is there anyway a dodgy proxy can steal my credentials? thank you
This question / problem has been solved by onarliogimage
avatar
timmy010: How do passwords work? i have a multi-user computer and so people do their own things such as set up proxies. i don't know what one really is or how safe it is. I understand proxies as a middle-man. so say i log into gog, but i did it over a proxy. are my credentials encrypted at my computer before being transmitted? or is it in plain text and only encrypted at a storage level on the server? i suppose another way of asking is is there anyway a dodgy proxy can steal my credentials? thank you
Rough explanation:

Depends on the implementation, but the state of the art for decades (and the correct way to do this) is to first transform your password with a one-way function into another form (i.e., cryptographically hash the password), and then send this value to the server.

The server only knows this value in its database, and compares the value you send with what it knows. If they match, you log in.

Like I said, this is a one way function, so there is no (computationally feasible) way to convert it back to your password even if somebody captures it on the way. Similarly, the server (e.g., GOG) does not know what your actual password is.

If the hash scheme used has known weaknesses, then an attacker with sufficient computational resources can do the conversion though. So this scheme is as strong as the cryptographic hash function used, and whether it is used properly. Omitting the details here...

EDIT: A few general additions:

- There are multiple layers of security that indirectly affect your security in this case of course. For example, you communicate with GOG over a secure TLS channel, so nothing is transmitted in plain text anyway.

- There are still ways to lose your password hash. For example, GOG's database could get compromised and hashes stolen. Then the attackers can potentially crack your pasword hash and get the original password. There is nothing you can do about this. Hence it is a good idea to pick a unique pass for each service you use. (removed the salting stuff since ninja'd with a better explanation below!)

- In your threat scenario there are other ways other users can steal your password. For example, are you sure they cannot install a keylogger on the machine?
Post edited December 11, 2016 by onarliog
Adding to this, because 1-way functions always produce the same result it would only be too easy to pre-calculate millions of passwords. So to offset this often there's Salt added to the password. Random characters or words added either decided at the server level, or when the OS is installed.

Example: Password1
Salted: unixver_1101;Password1_humptydumpty

more complex hashing may sometimes take the result of the hash and recalculate it multiple times.

user: Jeb
Password: Password1

cycle 1: Jeb.Password1.salt
cycle 2: Jeb.d85e2811da2734a174b2ff4b6092e87a.salt
cycle 3: Jeb.97a3f6dc7de0d1a35ef05c83edf36839.salt

Final password hash: d929f8f2440562f6da6429607b9bda59

There could also be dozens of salts and just picks one at random, at which point it may have to calculate the hash a few hundred times before it verifies the password is correct.