Archisteamfarm: Encrypt password in the json config file

[igromanru]

I know that it's open source project and anyone who has some knowledge can decrypt it, but I think it's a generally issue to store passwords as a plain text.
If someone (for example a friend) just go on my PC and open a json file, he will know my password.
So could you please encrypt the password somehow, that it will take some effort to find it out or just can't be remembered.
P.S.: If you agree with it, I can develop it and make a pull request, if you want.

[JustArchi]

anyone who has some knowledge can decrypt it

Exactly. ASF is open-source and if ASF is able to decrypt given data, then anybody can read it as well using the same code/implementation/passwords.

If someone (for example a friend) just go on my PC and open a json file, he will know my password.

True, but if he manages to get to that file, and read the encrypted data it's not any more secure than plaintext, as stated above. Secure password is a password that can't be easily cracked by an attacker, in our scenario we add only extra insecure layer to that.

So could you please encrypt the password somehow, that it will take some effort to find it out or just can't be remembered.

ASF already offers you a solution - using password of null. You don't have to store your password in the config - if you prefer to type it on each ASF run. Your password never leaves ASF memory, therefore it's as secure as it can be.

However, I agree. I could add extra function that would support using e.g. AES-encrypted password with generally-known secret for users that would prefer to store it instead. As I said, this is not any more secure and I don't want to make users believe it is, that's why ASF won't have any function for encrypting data (because it's nonsense), however, it can support reading encrypted data and decrypting it.

[igromanru]

You could add an optional parameter to ASF.exe, the parameter should be used as AES key. So everyone can encrypt theirs data with an own key. That would be smart and secure...

[JustArchi]

Can be done, why not.

[igromanru]

Would you like to do it yourself or should I make a pull request?

[JustArchi]

I'll do that, I just think of a good variable name, --cryptkey crosses my mind for now. You got any better ideas?

[igromanru]

--cryptkey is a good call. Or --aeskey is smaller. But I think it's not really matter.

[JustArchi]

--aeskey indeed is smaller but in future it might be reused in other places, hell, even currently it's used for salt in ProtectedDataForCurrentUser algorithm, so it'd make more sense to use one for all, I doubt that anybody will ever want to have two different algorithms for two different bots, and in addition to that with different keys, that is overkill.

--cryptkey it is, I can always change it if somebody comes up with better idea until stable release.

[igromanru]

Yeah, it's fine. Thank you. :+1:

[JustArchi]

Done, but it will have to wait for next version, unless you want to compile yourself - I have enough for today :smile:

[igromanru]

Thank you, it's fine.:thumbsup: I will wait for next version. Have things to do now. :smiley:

[JustArchi]

Should be working in https://github.com/JustArchi/ArchiSteamFarm/releases/tag/2.1.1.4 but I didn't test it yet, I have other stuff to do right now. Feel free to give it a try and report back if everything works as supposed too (or not) :smile:

[igromanru]

I got an error:

28.06.2016 13:50:08 [*] INFO: CheckForUpdate() <Main> Checking new version...
28.06.2016 13:50:09 [*] INFO: CheckForUpdate() <Main> Local version: 2.1.1.5 | Remote version: 2.1.0.7
28.06.2016 13:50:09 [*] INFO: CheckForUpdate() <Main> ASF will automatically check for new versions every 24 hours
28.06.2016 13:50:09 [*] INFO: RefreshCMs() <Main> Refreshing list of CMs...
28.06.2016 13:50:10 [*] INFO: RefreshCMs() <Main> Success!
28.06.2016 13:51:00 [!] EXCEPTION: DecryptAES() <Main> Zeichenabstände sind ungültig und können nicht entfernt werden. (Padding is invalid and cannot be removed)
StackTrace:
   bei System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
   bei System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
   bei System.Security.Cryptography.CryptoStream.FlushFinalBlock()
   bei System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing)
   bei System.IO.Stream.Close()
   bei System.IO.Stream.Dispose()
   bei SteamKit2.CryptoHelper.SymmetricDecrypt(Byte[] input, Byte[] key, Byte[]& iv)
   bei SteamKit2.CryptoHelper.SymmetricDecrypt(Byte[] input, Byte[] key)
   bei ArchiSteamFarm.CryptoHelper.DecryptAES(String encrypted) in L:\GitHub\ArchiSteamFarm\ArchiSteamFarm\CryptoHelper.cs:Zeile 118.

What have I done:
I have choose 256Bit on aesencryption.net and encrypted my password. Copy & paste the base64 string to config.
"SteamPassword": "nQsmcJ+tfjJMKjCp+sw8LFFcjmDBLYOKLS1RwGsDHgY=",
Started the bot.

I have debugged your code, anything looks good, I guess it's an issue of SteamKit, but better you check it out.

P.S.: I am starting ASF.exe with parameter --cryptkey=testtest (testtest is my test key).
But it's looks right, the EncryptionKey is filled with "testtest" at this point.

[JustArchi]

I have choose 256Bit on aesencryption.net and encrypted my password. Copy & paste the base64 string to config.

That won't work, the algorithm that ASF is using is far more complicated and not possible to reproduce using any online AES website at the moment. You should launch your ASF with PlainText password and the cryptkey you want to use first, then generate your AES password using !password command. Then copy paste that into bot config, change password format to AES, and restart with the same cryptkey.

This is because IV must be included (prepended) into the encrypted byte array for ASF, and I didn't see any website doing that so far. ASF IV is unique and always generated randomly, that's why every !password call, even with same cryptkey will always result in different encrypted password, even though all of them are resulting with same string. aesencryption.net for instance, is always using the same IV, so if you encrypt the same password two times using same cryptkey and bitness, it will be the same. If you do it in ASF, those two passwords are guaranteed to be different, unless generated IV would be the same, which is not possible with current implementation, chance is too low.

Thanks to that, cracking your password without knowing your cryptkey will take millions of years if not more.

[igromanru]

Ah ok, thank you. I have missed the IV part.
Hmm, the think with command is very complicated. Is it not possible to modify the ConfigGenerator the same way? Also pass --cryptkey= to ConfigGenerator, so it can generate encrypted password?

[JustArchi]

CG doesn't have required SK2 dependency, and I don't want to include it only for that part. Besides, this feature is more like for geeks and people who actually prefer to put extra effort into extra security, definitely not for everyone. 99% of users won't even bother with it, while the rest 1% won't have a problem using !password.

[igromanru]

After a lot of pain I manager to configure all my accounts. At least, it works.
Thank you for the feature.

[JustArchi]

It is, that's why I decided to make it easier for maintenance. ConfigGenerator is a nice tool for people with no general IT knowledge, as it's supposed to "make things work", but the more things I add to it, the harder it will become to set it up, and for people with enough knowledge it is actually easier to manually maintain configs. When CG becomes too hard to set up, we could as well just use manual configs from the beginning.

More advanced people will be happy to e.g. being able of writing a script asking ASF through WCF for !password of each account and automatically putting it in the config, and not being forced to do that with GUI. Less advanced people will appreciate that CG doesn't require more than needed to set up ASF. In fact, it still requires too much, but tutorial helps a bit.

[igromanru]

I agree with you, but the problem is, that it's not possible to generate encrypted password without using/starting the program. Additional to that I have to use WCF or Steam chat, it's a bit overkill for a simple task. It would be handy if I could configure settings before I start ASF at all.

I got few ideas about that. The simplest would be, to check if the password is set to "PlainText" and automatically encrypt it and change PasswordFormat to "AES" if --cryptkey= parameter was passed.
And If you want to make it much smarter, you can check, if the password is base64 and automatically encrypt it if PasswordFormat was set to AES. So an user that have not so much knowledge can simple change the format and the password would still "safe". Without --cryptkey= your buildin password would be taken but it's still safer than PlainText and with ProtectedDataForCurrentUser it would work much better! :grin:

[JustArchi]

That would be indeed nice, but the first rule I set for ASF is the fact that configs must be read only. ASF should never modify them. Configs are fully provided by user, and ASF should work the way user wants, not decide that it knows better what user wants. The only exception from this rule is if configured setting is invalid, but even then the option is ignored, not overwritten.

Besides, not everyone likes full JSON structure. I personally use only core minimal settings for keeping my config small. ASF can (re)generate only full structure, and this is something I don't like. It would make much more sense to define in config only variables we want to adjust, and that's impossible to do with CG. That's also one of the reasons why ASF never regenerates configs with new properties.

[igromanru]

Actually you can keep json small, without serializing the full object, there are multiple ways. :wink:
Whatever, IMO it's our duty to make users life simpler and get sure to protect them. Like you said, most normal user don't care about security and this is exactly the problem why so many people get hacked. Of cause everyone should choose for himself, but if they have no IT knowledge, they can't do it properly.
But it's just my opinion. :smiley:

I'm thankful for your tool and that you've implemented my required feature. Thank you for a great job. :blush: :thumbsup:

[JustArchi]

Actually you can keep json small, without serializing the full object

Of course you can, but that would include deep analysis of what config file provides, and serializing only those fields. Even in this case I don't want to create potentially harmful situation such as ASF generating wrong configs or corrupting them. Lack of touching them ensures that they'll be valid.

IMO it's our duty to make users life simpler and get sure to protect them

That's true, but I'll never do security at all cost - something what Valve did introducing 15 days holds. It's up to user to decide how secure his ASF usage should be, and not me. Default ASF config is based on simplicity, it requires changing from 1 up to 3 fields (depending if user wants to skip asking for login/password). Introducing encrypted password by default would rise problems such as expecting user to provide cryptkey, or running into issues such as "why my ASF no longer works on new PC", because using AES with default cryptkey is not really any more secure than using PlainText. I don't want that, I want to make program that targets both new users and advanced ones, allowing newbies to easily make ASF working without digging too deep inside, while at the same time allowing advanced users to tune ASF in whatever way they wish.

I do understand that security is important, and that's why I spent time coding this feature instead of saying "meh, not really needed", but I also have to keep things in balance, ASF is getting more and more complicated with each version - targetting encrypted passwords by default will only make it harder :smile:

Maybe I consider adding this option later, but for now this feature is too new to consider it. I didn't even test it carefully yet for regressions and possible issues, hence pre-release. I also prefer to base CG on simplicity and easy use, as advanced users are able to handle configs manually anyway.

Anyway, let me know if you (or anybody else) spot any issues related to recent encryption. To be honest I don't expect any bugs, but I didn't test it carefully yet either. It should work decent enough to be called stable :+1: