Add 2FA option when encrypting passwords
SubtypeZero opened this issue · 10 comments
I noticed some talk about storing encrypted passwords in the future and thought it would be worth suggesting the use of 2FA. It's not very difficult to implement the time-based algorithm used by most common authentication apps available. This may be a poor example, so you'd want to make sure the implementation is correct, but here's an example from an authentication plugin I worked on a while back that may help. The plugin definitely could use some updating, but it should serve as a decent example. TOTP.java#L69-L122
If i understand you correctly you want me to implement 2FA forloading te saved password from config? The thing is: how is that supposed to work? The config would need some way to link your device to it - even if there would be a sane way to make te config verify that its your device and the auth is correct theres i no way to use it as a passphrase for the encrypted password due to it changing over time ...
The only thing i could do is save the linked devices into config (encrypted), ask for the passphrase to decrypt the linked devices and saved password, and then ask/verify the 2FA to actually put the already decrypted password into the login-gui (which provides a false sense of security)
If you know a better way to handle this than the one i descried above please tell me ...
(I'm not Mojang therefore im unable to implement it for logging into their services (ask on their issues tracker for that...))
It's just a suggestion, but what you'd need to do is store a key for the particular device. The key acts like a seed when generating the time-based codes (6 digits long). When it's time to verify, the client would enter a code generated by their app. When submitting the code to the mod, the mod would then generate a code of it's own based on the stored key and the two codes would be compared. That's how the verification process generally works, but I just realized there's a flaw in my reasoning. I didn't think about this before, but you'd have to store that key somewhere and if you're storing it without encryption then it's basically the same as leaving a password in plaintext because you could fetch the code and use it to authenticate or get the real (encrypted password). Therefore, this may not be an option and you'd be better off using some sort of hash algorithm (definitely not MD5) to hash inputs and see if they match what you have stored.
my main problem iwth this is as follows: even if i were to verify tha authenticity of the time-based-codes - how would you go about decrypting something with it when they are "random" by design?
As far as i can tell 2FA is unsuitable for this purpose (even though it is a good idea in general ...)
i can't hash the password either due to it being needed for logging in ...
Im probably going to end up using something like an aes encryption
if i may cite myself: "random" - the quotationsmarks are there on purpose ... i know the are not generated by a RNG ... but they appear random to anyone using it (ie. they arent just incremental numbers ...)
The problem is that you need to have a secret key to generate the codes and compare them, which would require storing it somewhere. It’s not ideal because the client has access to both sides. For 2FA to work, it’s best to have the client and the server (code checker) running in two separate machines. Since this is not going to be practical for the mod, the only other logical option I see is to use a hashing algorithm when storing passwords, which would protect the passwords when the mod isn’t running (requires password entry at least once, to decrypt and load into memory).
Elaborating on "i can't hash the password either due to it being needed for logging in ..."
If i stored the password in hashed form into the config i have to ask the user for his password the next time he wants to login (due to the hasing not being revertible) - but asking for the password again makes saving it in the first place useless (password checking is done by mojang anyways ...)
That’s true, but you could use it to implement a “master password” if you wanted, which would be helpful to users who have multiple accounts. As far as 2FA goes, it’s definitely not going to be ideal, but you could still read about it here if you’re curious about how it works: https://en.m.wikipedia.org/wiki/Multi-factor_authentication
why save the master-password in hashed form when you can use it as decryptionkey (and verify its validity by checking the decryption output)
I know all i want to know about 2FA ...