search

namreeb / wowreeb

An intelligent, versatile, and multi-versioned World of Warcraft launcher
MIT License
58 stars 32 forks source link

Automatic login #3

Closed namreeb closed 6 years ago

namreeb commented 7 years ago

An intermediate step in SRP6a authentication is to compute SHA1(upper(username) + ":" + upper(password)). We can avoid storing passwords in plaintext or practically reversible encryption by storing this hash rather than the username and password.

HelloKitty commented 7 years ago

Storing the SRP6 scheme's x component is still very dangerous imo. It's just as useful to people as a plaintext username or password.

namreeb commented 7 years ago

Yes I agree. But I can't think of a safer way. Can you (I am asking seriously, not sarcastically)?

HelloKitty commented 7 years ago

@namreeb This is not my area but when I posted that I tried to come up with something but the only thing I could think of was a way to obscure it, though I think it's slightly creative. At the first time running the launcher you could generate a GUID and use it as the seed to create an RSA keypair. This GUID could be written into a placeholder white-space string into either your managed or unmanaged dll. The GUID could be used to reproduce the RSA keypair everytime you load the launcher and that same RSA keypair could be used to encrypt and decrypt. This would mean the SRP6 x would only be valid with that launcher. All other launchers will assuredly be generating keys from a different GUID making it less likely anyone can swipe them and use them in their own launcher.

It doesn't really have to be RSA, anything reversible though. The whole concept is that it won't protect users completely BUT it will require any "friend" visiting someone's house or borrowing their laptop to go from just swipping some SHA1 hash from a file to having to understand what is going on and then having to swipe the DLL and dissesmble it for the guid or inject it into a refresh one and etc.

If someone is using your computer with those skills you've got bigger problems anyway but this should handle the cases of "friends" stealing your details.

namreeb commented 7 years ago

Your case for obfuscated reversible encryption is the same as mine for serializing the hash as opposed to plaintext credentials, merely taking it a step further. Sure it's "safer" but there will always be a step that is safer yet. At the end of the day, any fully automatic login code will depend on the security of the file the credentials are stored in. The only truly secure option would be to password protect the passwords. But meh. Just don't send out your config file! :)

HelloKitty commented 7 years ago

Yes, I absolutely agree with you. It was merely moving the goal post. I still think it addresses the low hanging fruit issue by preventing a copy-paste being usable in other instances of your launcher.

In the end you're right. There is, to my knowledge, no way to protect the hash.

Shame servers don't let your query for the realmlist without authenticating otherwise you could save the session key instead and gain indirect revokability and potentially speed up auth by skipping the authserer whether it's down or up.

namreeb commented 7 years ago

I'm not at my computer right now so this may be wrong, but I think the next hash seed is the client seed. If it is, we could replace the random generation by the client with a seed based on the HWID of the system.

namreeb commented 6 years ago

I am re-opening this because there really shouldn't be a security issue if the passwords are stored in a key-protected encryption scheme (i.e. AES) and the user is required to provide a password upon loading (or upon attempting to use a configuration file entry which has encrypted credentials).

namreeb commented 6 years ago

Added in 3.0.