[This is an amalgamation of three informational posts I made on reddit in the wake of the Peter Kadar and GWReborn account compromises. I’m reposting it here because it’s useful information.]

Part 1, General Best Practices:

    1. Attack surface reduction.
    • a. Don’t link your GW1 account to a GW2 account.
    • b. Don’t link your GW1 account to an ArenaNet account.
    • c. (So far as I know, unlinking isn’t an option, so there’s nothing you can do if you’ve already linked.)
    1. Keep information useful for social engineering out of public view.
    • a. Use a dedicated e-mail address for your GW username that never sends or receives e-mail other than to/from A-Net, and keep this address totally secret from the rest of the world. (It used to be that you couldn’t change your username, but I believe you can now.)
      • Since it’s easy to forget the credentials for an e-mail account you never use, write them down and store them in your GW DVD case.
    • b. Keep your character names on a need-to-know basis. Use PMs when you need to share your character names, rather than public posts. Maybe don’t make high-profile, clickbaity YouTube videos showing your character names.
    • c. Keep your real name secret from everything GW-related.
    1. Don’t advertise your wealth. It makes you a target. (As the old country song goes, “never count your money when you’re sittin’ at the table.”)
    1. Defense against brute force, password cracking, and credential stuffing.
    • (FYI: What is cracking? Assume that an attacker has breached an online service and stolen a copy of their user database. If the passwords are properly stored as salted hashes, the attacker must work backwards from each hash to the password. That’s cracking. Cracking is stupendously easy for weak, “spaceballs-quality” passwords (< 1 sec), but essentially impossible for strong passwords (not before the death of the sun, even if you could convert the whole mass of the earth into a computer and use the sun’s full energy output to power it). Cracking is often more of a threat than brute force, because rate limiting and lock outs can easily stop brute force.)
    • a. As above, use a dedicated, secret e-mail account for your username. (Stops brute force; Useless against cracking because the attacker already has the database.)
    • b. Use a strong password. There is a ton of misinformation about passwords floating about, and most people who think they know how to make a strong password actually don’t. So I will cover some basics:
      • i. Password strength does not depend on the properties of the string chosen as the password (e.g., "1 uppercase letter, 1 lowercase letter, etc.), but rather it depends on the process by which the password was chosen. Password strength is proportional to the number of possible passwords the generation process could have created. (So, random strings is a very good password generation process. While, for example, “my wife’s first name, followed by her birthday” is a terrible password generation process, because it only has one possible output. Unless you’re a Mormon or something, but let’s not go there…) This is why “password strength meters” are total crap.
      • ii. The best scheme for generating strong passwords that are easy for a human to remember is the diceware/xkcd system. A few important notes: (a) To achieve reasonable security in a threat model that includes cracking, you need 6 words from the EFF’s long list. (b) You need to use a truly random method for selecting words, like dice. Whatever “randomly” pops into your head is not “random” in the sense used here. (c ) You must take the words you roll exactly as you rolled them; you can’t reroll a word you don’t like or reorder them.
      • iii. Another sound system for creating strong passwords that are easy for a human to remember is Bruce Schneier’s scheme. (Note: Schneier later retracted the remark in the link criticizing the xkcd scheme.) Begin with a personally memorable sentence. (Note that this sentence has to be personal to you. It cannot be a quote, bible passage, song lyric, etc.) Condense the sentence into a password by replacing most words with their first letter, or with an abbreviation or symbolic shorthand. For example: “When we went to Colorado in 1988, my brother Greg barfed on me in the car” can be condensed to Www2COin1988,mbGbarfed->mitc. While easily memorized, this is a 28-character password that approximates a random string.
    • c. Never change your password unless you suspect it’s been compromised. “Password rotation” is a cargo cult practice that was only ever useful in the context of certain 1970s multi-user mainframes. It serves no useful purpose today. And it’s even detrimental because the annoyance of changing passwords tends to make people opt for weaker passwords.
    • d. What about using a totally random string and storing it in a password manager? Theoretically a good idea. The problem is that most password managers are utter shit, and their developers are incompetents and crooks. The only two I can reasonably recommend are PasswordSafe and KeePass (without the browser extension). The following are necessary, but not sufficient, requirements for a trustworthy password manager (a) open source, (b) standalone; no browser integration, and (c ) offline; no cloud integration.
    • e. Never use your GW password anywhere else. More, generally, never use any password in more than one place. Reusing passwords makes you vulnerable to “credential stuffing” attacks in which the attacker tries to use username/password pairs stolen from one online service at multiple other services.
    1. Defense against phishing
    • a. The only place you should ever enter your password is the GW client. Never type it into your browser, or e-mail or text it to anyone.
    • b. The only place you should ever enter a 2FA code is the GW client. Never type it into your browser, or e-mail or text it to anyone.
    • c. The 2FA options available for GW prevent unsophisticated phishing attacks, but you are still vulnerable if you can be tricked into handing over the 2FA code.
    1. About 2FA:
    • a. SMS 2FA is very weak. So weak that it’s arguably worse than useless because it may create a false sense of security that causes you to be more careless with your password practices. See [Part 2].
    • b. The authenticator app is significantly stronger. Definitely better than nothing. It has a few shortcomings though: (a) Doesn’t protect against phishing, as noted above. (b) Protocol design uses a long-term shared secret, which is bad for the reasons noted in [Part 3]. (c ) Poor implementation of initial transmission for the shared secret. (d) Relies on a smartphone, which are notoriously insecure. Depending on how bad your PC security is versus how bad your smartphone security is, it might be safer to use a PC program rather than a smartphone app. (I’d definitely prefer a program on Linux over any smartphone app. And also a program on Win10/11 over a smartphone app on Android. Not sure about Win10/11 vs. iPhone.) (e) There’s a risk of accidentally locking yourself out of your account. (Make sure to write down your TOTP secret and store it in your GW DVD case.)
    1. There are some things that you simply can’t protect against. For instance, if someone at support is dead set on getting tricked by social engineering and giving away your account, there’s nothing you can do about that.

Part 2, Why SMS-Based 2FA Sucks:
[This post was in response to “how did he hacked your mobile phone? xD”]

How to bypass SMS 2FA?

  • Use social engineering against account support personnel.
  • Find a vuln in the ArenaNet Account webpage.
  • Compromise a device on the same network as the victim to route your traffic through so GW doesn’t prompt for 2FA. (A router would do nicely, and consumer routers generally have poor security. And ISP-provided modem+router boxes often have publicly known factory default passwords (in addition to poor security).)

How to defeat SMS 2FA?

  • The most common way is to just phish the victim for the 2FA code. However, this method is unlikely to work in the case of GW1 because the standalone GW client is the only place the victim ever expects to enter that code.
  • More likely in this case would be a sim swap. That’s when the attacker uses social engineering or bribery to persuade a cellular service provider employee to port the victim’s phone number to a new sim card. This is pretty rampant because the security of the whole system depends on the poorly paid, poorly treated, and poorly trained employees down at the Verizon Store to resist social engineering and bribes. Frequently used to steal accounts of cryptocurrency whales.
  • Up-and-coming technique is Lapsus$-style fraudulent EDRs. Turns out there’s no fast and reliable way for tech companies to verify that the person submitting a law enforcement “emergency data request” is really a law enforcement officer, so they don’t even try. Hit the cellular service provider with a fake EDR demanding real-time access to the victim’s SMS.
  • More exotic tricks like using a Stingray or DIY Stingray-like device.
  • Compromise the smartphone. (Not hard. iPhone security is bad; Android security is a joke. Smartphone manufacturers often stop providing patches within a couple years after a model is released, long before consumers stop using them.)

That’s not even close to an exhaustive list. Just some common/popular techniques off the top of my head. The rather unfortunate bottom line is that SMS-2FA is so easily defeated in so many ways that it’s very nearly useless. Not totally useless, but close to it. There’s also an argument that it’s actually worse than useless because it creates a false sense of security that causes people to be more careless with their password practices.

Part 3, The Authenticator App Is Better, But Not Perfect:
[This post was in response to “Any compromises in the app authenticator?”]

The things listed above as bypasses are going to work no matter what 2FA method is used. There’s nothing your 2FA method can do to stop support from falling for a social engineering attack, and so forth.

Likewise, “compromise the smartphone” is going to work against any 2FA method that depends on a smartphone.

Now on to issues specific to the authenticator app. According to this support page, it’s just TOTP. While TOTP is most definitely better than nothing, it has a couple of notable shortcomings:

TOTP’s most glaring shortcoming is that you can still be phished. It’s a little harder for the attacker because they need to phish the TOTP code in real time, since they expire, but phishing attacks are still totally viable. (In the GW context you can guard against this by making DAMN SURE you never enter a TOTP code anywhere other than the GW client. Never type it into your browser. Never e-mail or text it to anyone.)

TOTP’s other notable shortcoming is that it relies on a long-lived shared secret. Obviously, it’s bad if your TOTP secret leaks, but the long-lived-ness makes it worse in a couple of subtle ways. First, the attacker can steal the TOTP secret months or years before they steal the password, and it will still be good when they finally get the password. Second, because the attacker can sit on the TOTP secret for such a long time, it can be very hard to figure out when and how they stole it. The nightmare scenario with this is that the attacker breaches (or has already breached) A-Net and gets everyone’s TOTP secrets, and then goes about obtaining passwords for high-value accounts, stealing only a couple accounts per day, and no one has the faintest clue how they’re getting past TOTP. (Breaching A-Net shouldn’t get them the password, since those are supposed to be stored as a salted hash, and that’s unbreakable if you do it right and the user’s password isn’t poor enough to be subject to a dictionary attack. By contrast, TOTP secrets need to stored in plaintext, so there’s no protecting them in a breach.)

So we might want to take a looks at how the shared secret is initially transmitted and then stored.

In terms of securing the initial transmission, A-Net could do better. During the set-up, they’re sending the shared secret over TLS to your browser. That means that an attack against TLS (Logjam, MitM certificate, etc.) or against the browser (malicious extension, zero-day vuln, etc.) can be leveraged into stealing the TOTP secret. This could be improved by moving this operation to the GW/2 client, thus cutting the browser and its vulnerabilities out of the picture, and using one of the following key-exchange methods to cut out TLS and coterie of not-so-trustworthy “trusted” CAs. (a) User generates the secret, then encrypts it using asymmetric public key built into the GW/2 client, transmits to A-Net. (b) Use some species of Diffie-Hellman exchange to generate the secret.

In terms of storing the secret, well, given the state of smartphone security, a system design that stores a long-term cryptographic secret on a smartphone doesn’t seem like a very good idea to me…

(Aside, if you ever find yourself in charge of picking a 2FA protocol for an online service, U2F is a superior alternative that doesn’t share TOTP’s shortcomings discussed here. Avoid FIDO2 like the plague.)

Finally, a word about usability concerns: If you lose your TOTP shared secret (or lose/break the device containing the only copy), then you’ve locked yourself out of your account. I suggest writing it out on a piece of paper and storing it in your CD case.