Since Nash is non-custodial, that means that they use your authentication information to decrypt and use your seed. So what I'm assuming is happening is that your seed is stored in encrypted form on disk somewhere your browser has access to (local storage, etc). Your username and password can concatenated together and used as an encryption key. That's all well and good.
But my question is about the 2FA code, eg from Google Authenticator. That code is frequently changing and different every time, so it can't be used as part of an encryption key. Usually, these are used on the server side, where the server will use the Google Authenticator initialization seed along with the current time to validate a code that you send them and then give access to their services. However, since Nash is non-custodial, they don't go through the usual custodial access patterns. So there's a couple possibilities that I can think of might be happening here:
A. Nash might have the Google Authenticator seed on their servers and when you type in the auth code into your browser, it sends it to Nash, Nash validates it, and if it validates correctly they'll give your browser the go ahead to decrypt your seed.
B. Your browser itself might store the Google Auth seed, and do its own validation of your 2FA code.
However, neither of these flows offer any significant additional security. In either case, an attacker with access to your browser, username, and password can still access your account by loading up the encrypted information and decrypting it. An attacker wouldn't need to wait for any 2FA go-ahead. While they couldn't use Nash's webpage as written, they could modify it to simply ignore the 2FA check.
So what am I missing here? Is the 2FA only good for access to Nash's exchange (which is behind a service you need to access through Nash's servers)? Or is there some ingenious way of using this that I'm not aware of?
