Forums » Suggestions
Remember password
In the Linux client I have to enter my password each time I play the game. I suggest adding an option to remember the password so you can quickly jump into the game.
Of course after posting this is when I find a thread on this topic from 2015 - https://www.vendetta-online.com/x/msgboard/3/29827#357180. I can't reply to that thread (probably because it is very old), and I can't delete my post, so oh well, here's some more of my thoughts on the topic:
All of my passwords are stored in my password manager and are generated to be long random sequences of characters. The password manager is a browser extension so it can auto-fill credentials for websites, but not the game. Despite having a keyboard, typing this password in every time is becoming frustrating. Since it seems doubtful that there will be an option to remember the password, I guess my next option is to make it really basic and unfortunately less secure.
All of my passwords are stored in my password manager and are generated to be long random sequences of characters. The password manager is a browser extension so it can auto-fill credentials for websites, but not the game. Despite having a keyboard, typing this password in every time is becoming frustrating. Since it seems doubtful that there will be an option to remember the password, I guess my next option is to make it really basic and unfortunately less secure.
Statistically I think you'll find a high-entropy "memorable" generated password, like those produced by XKpasswd.net (an improved version of the system from the classic comic), should provide a robustly secure, but memorable solution.
For instance, when I ran it just now, it made three sets of passwords:
**69/wear/CHILE/colombia/12**
&&35|stream|BONE|france|68&&
==34:ireland:SEVERAL:smell:63==
The combination of four random digits, along with three random words and also random characters as separators, creates a pretty difficult password to attack, but still possible to remember.
(Obviously, no reader should use those three passwords above, this is just an exercise as an example).
We still haven't ruled out the possibility of password storage, but the problem here is that most people are not like you.. they don't have unique random passwords per-service. So, basically, we don't want to become a channel for exposing people's inherently bad password habits (which could compromise their entire life). Thus, anything we implement would need to be.. pretty thoughtful in how we went about it.
Plus, some operating systems, like Windows, have high-level function calls intended for private-key storage, where the actual OS will use different "hardened memory" allocation practices, and not swap that data to disk in virtual memory, and so on. But Linux doesn't have these things, it's very low-level and "DIY" there. Doing something cross-platform requires us to approach things with considerable care.
As a side-note, our service itself (both website and game) are hardened against remote brute-force attacks. So, if you have some solid entropy in your password choice, it should be pretty unlikely to be compromised. We do also use email code-confirmation as a second-factor for certain types of personal information and account changes.
For instance, when I ran it just now, it made three sets of passwords:
**69/wear/CHILE/colombia/12**
&&35|stream|BONE|france|68&&
==34:ireland:SEVERAL:smell:63==
The combination of four random digits, along with three random words and also random characters as separators, creates a pretty difficult password to attack, but still possible to remember.
(Obviously, no reader should use those three passwords above, this is just an exercise as an example).
We still haven't ruled out the possibility of password storage, but the problem here is that most people are not like you.. they don't have unique random passwords per-service. So, basically, we don't want to become a channel for exposing people's inherently bad password habits (which could compromise their entire life). Thus, anything we implement would need to be.. pretty thoughtful in how we went about it.
Plus, some operating systems, like Windows, have high-level function calls intended for private-key storage, where the actual OS will use different "hardened memory" allocation practices, and not swap that data to disk in virtual memory, and so on. But Linux doesn't have these things, it's very low-level and "DIY" there. Doing something cross-platform requires us to approach things with considerable care.
As a side-note, our service itself (both website and game) are hardened against remote brute-force attacks. So, if you have some solid entropy in your password choice, it should be pretty unlikely to be compromised. We do also use email code-confirmation as a second-factor for certain types of personal information and account changes.
Thank you incarnate for the detailed reply. I'll try out your suggestion for the memorable password.
If you decide to implement some kind of automatic/passwordless login mechanism in VO, here's what has been rolling around in my head:
- Don't actually store the user's password, or even an encrypted form of the password. Inevitably that will be compromised and too many people still re-use passwords across different services, so is a non-option.
- Instead, create a unique PGP key for the installation. If the system has a keyring storage available, store it there for extra security
- On first successful login, if the user selected "automatic/passwordless" login, send the public key to the authentication servers
- Subsequent authentications authenticate using the PGP key, no password required.
- The login prompt would still show up and you can select or enter a username. If the selected/entered username is configured for automatic login, maybe the password field is disabled, but you still have to click Connect.
- On vendetta-online.com account management, create a new page that lists authorized installations/devices and allow the user to de-authorize, which would require re-entering a password the next auth attempt
If you decide to implement some kind of automatic/passwordless login mechanism in VO, here's what has been rolling around in my head:
- Don't actually store the user's password, or even an encrypted form of the password. Inevitably that will be compromised and too many people still re-use passwords across different services, so is a non-option.
- Instead, create a unique PGP key for the installation. If the system has a keyring storage available, store it there for extra security
- On first successful login, if the user selected "automatic/passwordless" login, send the public key to the authentication servers
- Subsequent authentications authenticate using the PGP key, no password required.
- The login prompt would still show up and you can select or enter a username. If the selected/entered username is configured for automatic login, maybe the password field is disabled, but you still have to click Connect.
- On vendetta-online.com account management, create a new page that lists authorized installations/devices and allow the user to de-authorize, which would require re-entering a password the next auth attempt
Yes, we've considered that for a long time (it has been on the TODO for years). Although, instead of PGP we would probably use ED25519 or Curve448 elliptic-curve keys directly.
But, even approaching things that way, the issue is complex. In fact, it's arguably more complex. Implementing anything with cryptography is a very careful and fragile exercise. Even when using best-practice higher-level libraries (libsodium, et al) they don't rule out the possibility of screwing something up.
Sony infamously screwed up their implementation of ECDSA key signing in the Playstation 3, resulting in severe compromises on that system.
Then, aside from all of the complexity, keep in mind we're a really small team managing a big game, with both a constant set of high-priority internal tasks (Server problems, client bugs), partner-mandated tasks ("Implement this new billing API or Google will kick you off the Play Store!") as well as sometimes-melodramatic community concerns ("I don't like X user, he shouldn't be allowed to play anymore!").
So, basically, at any given time we're trying to re-sort the list of "stuff that would be great to add" in order of what maximizes the odds of extinguishing the most critical fires. I wish it was more.. "preferential" than that, but we're rarely working on what we'd actually like to do.
At any rate, I understand the concern, and this is definitely still on our general forward-looking goal set.
But, even approaching things that way, the issue is complex. In fact, it's arguably more complex. Implementing anything with cryptography is a very careful and fragile exercise. Even when using best-practice higher-level libraries (libsodium, et al) they don't rule out the possibility of screwing something up.
Sony infamously screwed up their implementation of ECDSA key signing in the Playstation 3, resulting in severe compromises on that system.
Then, aside from all of the complexity, keep in mind we're a really small team managing a big game, with both a constant set of high-priority internal tasks (Server problems, client bugs), partner-mandated tasks ("Implement this new billing API or Google will kick you off the Play Store!") as well as sometimes-melodramatic community concerns ("I don't like X user, he shouldn't be allowed to play anymore!").
So, basically, at any given time we're trying to re-sort the list of "stuff that would be great to add" in order of what maximizes the odds of extinguishing the most critical fires. I wish it was more.. "preferential" than that, but we're rarely working on what we'd actually like to do.
At any rate, I understand the concern, and this is definitely still on our general forward-looking goal set.