[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:
Www2COin1988,mbGbarfed->mitc
. While easily memorized, this is a 28-character password that approximates a random string.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?
How to defeat SMS 2FA?
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.
This is an easy way to get the Dunes of Despair mission + bonus with lots of time to spare and without cheesing the mesmer boss. It's likely the way the devs intended the bonus to be done. This method is sort of described on the wiki, but not very clearly, and jumbled in with a bunch of worse alternative methods.
[This is an informational post I made on reddit. I’m reposting it here because it’s useful information.]
[Edit: DSOAL-GW1 was updated to r420+gw1_rev1 on 6/26/2021.
The new version includes a fudge factor that makes sounds carry farther, so their diminution with distance better accords with perceived in-game distance. This departs from the authentic “GW sound as originally intended” experience, but most listeners consider it a large improvement. If you don’t like the default, you can change the fudge factor by setting the environment variable DSOAL_ROLLOFF_FUDGEFACTOR to any floating point value between 0 and 1.0. The smaller you set this value, the farther sounds will carry. A setting of 1.0 makes no change to the rolloff strength as set by GW, and thus gives the authentic experience. A setting a 0 totally disables diminution of sound with distance (which sounds terrible and is not recommended). The default setting is one-third (0.333…).
Download link for latest version: https://github.com/ChthonVII/dsoal-GW1/releases/tag/r420%2Bgw1_rev1
[(End of edit)]
DSOAL-GW1 is a fork a DSOAL that has been modified to work with Guild Wars 1. DSOAL is a DirectSound-to-OpenAL compatibility layer that is able to emulate DirectSound3D and EAX in software. Put simply, this makes it possible to activate GW’s “Use 3D Audio Hardware” and “Use EAX” options and to hear GW's sound effects as originally intended.
Some history:
When GW was released in 2005, the audio component of Microsoft’s DirectX API was something called DirectSound. DirectSound had a 3D audio component called DirectSound3D, or DS3D, that could pan and amplify/attenuate sound sources based on their position relative to the camera in the game’s 3D world. PC’s with a high-end Creative sound card also had access to EAX, an extension to DS3D with a suite of hardware DSP effects for occlusion, obstruction, reverb, echo, etc. Like most games of its era, GW’s audio system was designed around DirectSound and DS3D, and owners of high-end PCs could get the “definitive” audio experience with EAX.
All that ended in 2007 with Windows Vista. Vista completely broke DS3D and EAX. Rather than fix it, Microsoft deprecated DirectSound and pushed developers to adopt its new XAudio2 API for future games. With DS3D and EAX broken, GW hasn’t sounded “right” in any version of Windows since XP.
Download: https://github.com/ChthonVII/dsoal-GW1/releases/tag/r420%2Bgw1
Source Code: https://github.com/ChthonVII/dsoal-GW1
[EDIT: See this post for test build of next version.]
Installation:
C:\Windows\SysWOW64\
. (Yes, that is correct.) On ancient 32-bit Windows computers (or 32-bit Wine prefixes), this is C:\Windows\System32\
. If dsound.dll already exists in this location, then MAKE A BACKUP before replacing it.C:\users\<your username>\Application Data\openal\
. [Edit: On newer version of Windows, Application Data
has been replaced by AppData\Roaming
. Use that instead.]C:\users\<your username>\Application Data\openal\hrtf
and extract all of the .mhr files from HRTF_OAL_1.19.0.zip into that directory. [Edit: On newer version of Windows, Application Data
has been replaced by AppData\Roaming
. Use that instead.]sources
can be set to any power of two between 128 and 2048. Because of GW’s idiosyncratic approach to DirectSound buffers, only half of these will actually be used. Unless you’re trying to run GW on a toaster, leaving this at 2048 is recommended.resampler
is a matter of taste. Cubic has many fans. See this video for a comparison: https://www.youtube.com/watch?v=62U6UnaUGDE.-dsound
to GW’s command line.Ambisonic Setup (recommended for systems with 4 or more speakers):
C:\users\<your username>\Application Data\openal\presets\presets.txt
to determine which preset best matches your speaker layout.channels
explicitly if your speaker setup isn’t automatically recognized.hq-mode= true
.distance-comp = true
.surround51=C:/users/billybobobbubba/Application Data/openal/presets/itu5.1.ambdec
HRTF Setup (recommended for headphones):
channels = stereo
and stereo-mode = headphones
.frequency = 44100
or frequency = 48000
depending on the frequency needed for your chosen HRTF preset.hrtf = true
.hrtf-mode = full
.default.hrtf
to the name of your chosen preset, minus the “.mhr”. (For example: default-hrtf = irc_1007_44100
)Troubleshooting:
Set the following environment variables:
DSOAL_LOGLEVEL=2
DSOAL_LOGFILE="C:\blah\blah\blah\DSOAL_log.txt"
ALSOFT_LOGLEVEL=3
ALSOFT_LOGFILE="C:\blah\blah\blah\ALSOFT_log.txt"
(Use a real directory that exists, and you have write permissions for, rather than C:\blah\blah\blah\
.)
If a log file isn’t being created, then the corresponding .dll isn’t getting loaded. The .dll files may be in the wrong place, or you may need to fix the registry entries or add -dsound
to GW’s command line. If all else fails, try installing to the system directory.
The ALSoft log will show whether your .ini file and any presets for ambisonics or HRTF are getting found and loaded.Credit:
The overwhelming majority of the credit for this belongs to Christopher Robinson (kcat) and the other openal-soft developers who have spent years working on open-alsoft and dsoal. They built a fricking transcontinental railroad; I just laid the last mile of track to hook up GW station.
Comparison to Other Methods of Restoring DS3D+EAX:
There are other options for restoring DS3D and EAX functionality, but DSOAL is generally superior.
Using DSOAL-GW1 for Other Games:
Will DSOAL-GW1 work for other games besides Guild Wars? It will probably work, but provide no benefits over mainline DSOAL, and possibly hurt performance a bit. DSOAL-GW1 is only useful if a game shares GW’s rather idiosyncratic approach to DirectSound buffers. This might be the case if you are experiencing missing sounds after a few minutes of gameplay when using mainline DSOAL and your log file is full of errors that say, “DSBuffer_SetLoc Out of software sources.” If you try DSOAL-GW1 and your log file is full of warnings that say, “Assigning a source for software buffer that was previously deferred as per Guild Wars hack,” then DSOAL-GW1 is probably not suitable for that game.
-- Chthon
[This is an informational post I made on reddit. I’m reposting it here because it’s useful information.]
For some reason, probably to do with the anniversary event, I've found myself explaining the use case for elemental weapons, and the suckiness of sundering weapons, multiple times in the past week. So I decided to port my martial damage spreadsheet to javascript, with a nice pretty interactive graph that visually illustrates the comparative strength of the weapon prefix options. Please feel free to link to this the next time someone asks about weapon prefixes: https://chthonvii.github.io/guildwarsmartialdamagecalc/
The TLDR for those too lazy to look at a graph:
[This is an informational post I made on reddit. I'm reposting it here because it's useful information.]
This post is intended as a linkable resource for quickly and easily responding to the "can I play GW on a X?" posts that seem to pop up once or twice per week. (There are two in the top six posts right now.)
TLDR Version:
Can I play GW on...
Further Details:
@ChthonVII
@lemmy.wtf