2

I'm building a Progressive Web App intended to be used primarily in an offline state. The user can "login" while disconnected, which verifies the password against a locally-stored hash and some other stuff.

The idea has been proposed to add 2FA to the offline login to make it "more secure". However, my (limited) understanding of MFA tells me that I'd have to store the 2FA secret key locally, and this code could be retrieved and probably be used to reverse engineer the auth code, making the whole thing moot.

(For the sake of argument, let's pretend this isn't JavaScript and a malicious actor can't just "skip" past my login process to access the app offline without logging in.)

Am I correct in my assumption that this is a dead-end? Or is there a way to do 2FA purely offline in a secure manner? Is there a better way to approach this?

|improve this question|||||
  • 1
    Authentication against a local application is a lost battle anyways. – MechMK1 Oct 31 '19 at 14:47
  • Yeah. For the sake of argument, let's say it's not. I want to focus on the nuts and bolts of MFA. – CandidGoose Oct 31 '19 at 15:03
  • you could encrypt the app's code, then decode it with a password supplied by the user. that way the app can't run w/o the password, and you don't have to store the password to verify it. you don't have to do all the code, just enough to secure it and prevent debugging-based by-passes. – dandavis Oct 31 '19 at 17:05
2

Authentication against a local JS application does not work. I wrote a detailed answer on this topic before. The crux of the argument is that an attacker is in complete control over the mechanism that performs the authentication, and is therefore able to always authenticate themselves successfully.

What about Multi-Factor Authentication?

It will not fare any better. Imagine a simple scenario, in which your application would send an SMS token to your user, once they entered the correct password. An attacker can simply read out which value is expected, and enter that value.

But what if an attacker would not be able to skip past my login?

That's the problem. In any even remotely realistic scenario, you don't get to tell the attacker how they can attack your application.

An offline JavaScript application can't securely authenticate a user, because the attacker is completely in charge of the authentication process.

|improve this answer|||||
  • The password (and potentially MFA code), after being validated, after used to generate a key that can decrypt necessary information. If the user bypassed authentication schemes, they would still not have a decryption key and thus can't do anything of value. That is why I would like to focus on the MFA piece exclusively, per the statement in my original question. – CandidGoose Oct 31 '19 at 15:35
  • That would be a huge design flaw, as it would require you sending all confidential information to every user. Furthermore, 2FA in all useful cases, is something dynamic - i.e. a one-time token sent via a second channel. You can't use dynamic components to decrypt something. – MechMK1 Oct 31 '19 at 15:40
  • I'm not sure what you mean by sending all confidential information to every user. Many apps receive confidential information. That's why TLS exists. – CandidGoose Oct 31 '19 at 16:00
  • One of the scarier parts is, the credentials -- whether it be a key-stretched password, a public key, or whatever -- is on the client machine. Security conscious web developers assume the table with those credentials will targeted by attackers, but it's one thing to assume it will one day be leaked; it's another to hand it out to anyone who asks. – Ghedipunk Oct 31 '19 at 16:10
  • @Ghedipunk The password credentials are strongly hashed. As for MFA, well... that's what I'm trying to determine from my question. – CandidGoose Oct 31 '19 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.