2FA for master password

[acidjunk]

Feature request: it would be nice to have the ability to enable 2 Factor Auth on the master pass. (e.g. with an authenticator app like Google Authenticator).

[rich123]

How do you envision this might work?

Keep in mind a few facts:

1) Password Gorilla is a local application that does not rely on any external or web services for its task (storing passwords).

2) All of the contents of the password file is entirely protected via a single secret key (that key being derived from your master password via a KDF [Key Derivation Function])

3) Google Authenticator uses a shared secret key to generate a "one time password" (https://en.wikipedia.org/wiki/Google_Authenticator)

4) The shared secret key is necessary to derive the "one time password" key provided by authenticator.

5) Because of #2 above, the shared secret key can not be stored inside the password file (because doing so creates a chicken-or-the-egg issue, if the key is stored inside the password file then to obtain the shared secret, the password file must be decrypted, but to decrypt the password file, the shared secret must be obtained).

6) #5 then necessitates storing the shared secret key elsewhere. But because the key should be secret, storing it on your local computer in an unencrypted form means that malware (or another user with access) could simply obtain the shared secret, defeating the purpose. So the shared secret would need to itself be encrypted under another password to prevent this information leakage possibility.

7) But, #6 now means that you'll first have to enter a "google authenticator access password" in order to decrypt the shared secret key in order to obtain the one time password from authenticator to then enter both the one time password and your original master password to then unlock your password file.

8) Because of #2 and the fact that the password file is protected by symmetric encryption, to unlock the password file, you have to enter the identical master password that was used to lock the file (in the context of PWGorilla/PWSafe, "used to lock the file" occurred when you first entered a master password upon file creation, or the last time you changed your master password). This means that this password is "used twice" (once to "lock" - then again to "unlock"). Symmetric encryption is incompatible with a "one time password" because if you encrypted via a "one time password" and then threw away that "one time password" (which is how a "one time password" works, it is only available once and is never available again) you would never be able to "unlock" later, because you could never retrieve the one time password again.

9) So, because of #8, the "one time password" can not be utilized to derive the "key" used in #2 to encrypt/decrypt your password file (because symmetric encryption requires the same key be available for both encrypt and decrypt steps, and a "one time password" is only available "one time"). So, at best, an integration with GAuthenticator (or a generic HTOP/TTOP system) degrades to #8 where you have to enter two passwords (HTOP/TTOP key access password) to obtain the key to generate the one time password to then enter the one time password and the original master password to then unlock the password file.

10) And, because the one time password can't be used for the actual key used in #2 to encrypt/decrypt the passwords file, should malware or another user of the same computer copies away your password file then they are unhindered in attempting to brute force your master password by any GAuthenticator/HTOP/TTOP layer that might exist above the master password (because the master password can't be derived from the GAuthenticator one time code). So you add a lot of what Bruce Schneier terms "security theater" ( https://en.wikipedia.org/wiki/Security_theater) to the unlock process for the master password file, but provide no security increase for the passwords stored in the file (because the only protection for the file is still the symmetric key derived from the same master password).

[acidjunk]

Thanks for the very detailed answer. I understand that for "practical" 2FA you'll need communication with an external service. But I think such a webservice is quite easy to make + cheap to host.

I can build a small Time-based One-Time Password (TOTP) webservice that confirms to RFC 6238 that could be used to do the 2FA stuff. So I imagine it could be an option for the user: enable it, create+validate an account on forementioned webservice and let Gorilla pass use it when enabled.

Why? My biggest fear after a couple of years with the pass vault: a keylogger would potentially have access to all passes.

[rich123]

But I think such a webservice is quite easy to make + cheap to host.

Agreed. But with that option PWGorilla is no longer an offline password storage system. While the majority of passwords PWGorilla stores are not useful without a working connection to the internet, I for one do store passwords that don't require a 'net connection to be useful. I.e., passwords to local router/wifi boxes, bios passwords for physical systems, passwords for encrypted gpg keys that I infrequently use, etc. I suspect I am not the only person storing "other" access credentials beyond website logins in PWGorilla.

But, you missed the larger point. With symmetric encryption used to protect the PWSafe storage file, there is no way to use a 2FA code as part of the key for decrypting the file, because 2FA codes are "one-time" codes (the same code is only ever generated once), but the file storage requires (at a minimum) a "two-time" code (same code available for encrypt and decrypt, and a strict "two-time" code would require a master password change with every lock/unlock cycle).

So a 2FA system can not protect you from a keylogger, because if the 2FA system always returned the same code (which it would need to for decrypting) then a keylogger can still capture the 2FA code and master password anyway. Reality is, if you gain a keylogger, there is very little that can be done, prior to physically removing the keylogger, to protect against the keylogger stealing your secrets.

Even PasswordSafe's (the program) Yubikey integration simply uses the Yubikey in its mode of "store a fixed random value, return that exact same random value each time it is used" [1] which simply amounts to a two part password, half stored on the Yubikey, half stored in human memory, but still, always the same ultimate final combined password when used to unlock the encrypted file. But both still vulnerable to a keylogger (because a Yubikey emulates a keyboard when it is being used).

[1] I verified this by reading enough of the PWSafe source to determine in what mode it was utilizing a Yubikey from an earlier request for Yubikey integration (which would be nice, given that a Yubikey can remember a far more complex, longer, passcode than a human mind, but without Tcl Yubikey interface libraries, is quite a difficult task).

[acidjunk]

If I'm not mistaken: The user could add the extra 6 digits (returned by the authenticator app) to the pass when the user wants to access the PW DB: and when the user has 2FA authentication configured and enabled -> you use the last 6 digits to verify the 2FA online, and when OK, the remaining password to unlock the PW db. (not for all users, but only for users that have it configured and are aware that they need to have a internet connection when using the app with 2FA enabled.)

So the decrypting will still happen without any changes and a static key.

I'm not sure if it "solves" all loop holes though: A more complete Functional Design could be useful? For example: When a hacker opens the pw db in an older version of PWGorilla, or somehow without the 2FA enabled: they could just strip the last 6 digits of the password (captured with fore-mentioned keylogger) and still be able to login. The could probably modify a PWGorilla from src code to use it without 2FA (but it would require substantial extra effort). Not sure if that's really the case...

Op vr 10 mei 2019 om 12:28 schreef rich123 notifications@github.com:

But I think such a webservice is quite easy to make + cheap to host.

Agreed. But with that option PWGorilla is no longer an offline password storage system. While the majority of passwords PWGorilla stores are not useful without a working connection to the internet, I for one do store passwords that don't require a 'net connection to be useful. I.e., passwords to local router/wifi boxes, bios passwords for physical systems, passwords for encrypted gpg keys that I infrequently use, etc. I suspect I am not the only person storing "other" access credentials beyond website logins in PWGorilla.

But, you missed the larger point. With symmetric encryption used to protect the PWSafe storage file, there is no way to use a 2FA code as part of the key for decrypting the file, because 2FA codes are "one-time" codes (the same code is only ever generated once), but the file storage requires (at a minimum) a "two-time" code (same code available for encrypt and decrypt, and a strict "two-time" code would require a master password change with every lock/unlock cycle).

So a 2FA system can not protect you from a keylogger, because if the 2FA system always returned the same code (which it would need to for decrypting) then a keylogger can still capture the 2FA code and master password anyway. Reality is, if you gain a keylogger, there is very little that can be done, prior to physically removing the keylogger, to protect against the keylogger stealing your secrets.

Even PasswordSafe's (the program) Yubikey integration simply uses the Yubikey in its mode of "store a fixed random value, return that exact same random value each time it is used" [1] which simply amounts to a two part password, half stored on the Yubikey, half stored in human memory, but still, always the same ultimate final combined password when used to unlock the encrypted file. But both still vulnerable to a keylogger (because a Yubikey emulates a keyboard when it is being used).

[1] I verified this by reading enough of the PWSafe source to determine in what mode it was utilizing a Yubikey from an earlier request for Yubikey integration (which would be nice, given that a Yubikey can remember a far more complex, longer, passcode than a human mind, but without Tcl Yubikey interface libraries, is quite a difficult task).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zdia/gorilla/issues/201#issuecomment-491241636, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFHHSVLSZLHHDVC6F26OXLPUVE5HANCNFSM4HLRVVQA .

[rich123]

Except, the 2FA code is different with each request, which when added to the master password would make for a different master password being entered to unlock (than what was used to create the file), which will fail to unlock, because unlocking requires entry of the same password that was used to create (or last used during a change).

And, in the end, from a key logger standpoint, the only item protecting the file is the master password, so that is still all that needs to be captured. The 2FA part would simply be security theater pretending to offer something more when the master password is all that is protecting the stored file.

But the big issue with the 2FA apps, is that the code provided is only provided once. Symmetric encryption is fundamentally incompatible with a password that is only ever generated once. That one time aspect is how they add security to a network login to a computer system (because a man-in-the-middle has a reduced chance of knowing both during the brief time of a single login attempt). But for symmetric encryption, the exact same key is used for both encryption, and later decryption. With a "one time" password (assuming it is used as intended, only one time), one could encrypt, but then one would never be able to decrypt (because the key would have been lost because of the one time aspect).

[acidjunk]

Only the last 6 digits would be different. (that's the one time part) I assume that stripping the last 6 chars of the pass is technical possible when 2FA auth is is accepted by the external webservice.

The login scenario would be:

1) ask the user for his normal pass + the 6 digits. 2) check the 2FA 6 digits stop with auth error if not valid. If valid continue with 3: 3) strip the last 6 digits from what the user entered 4) continue normal login

I hope it clear that it isn't a problem that the 6 digits change every time.

"from a key logger standpoint, the only item protecting the file is the master password" : the keylogger now has masterpassword + 6 digits (which are only useable one time), just the master password wouldn't be enough anymore.

We use this kind of setup at work for protecting a normal openVPN with 2FA. After the 2 auth stuff s done, the last 6 digits are stripped, and the remaning pass is used to do auth as usual with openVPN.

Op vr 10 mei 2019 om 16:59 schreef rich123 notifications@github.com:

Except, the 2FA code is different with each request, which when added to the master password would make for a different master password being entered to unlock (than what was used to create the file), which will fail to unlock, because unlocking requires entry of the same password that was used to create (or last used during a change).

And, in the end, from a key logger standpoint, the only item protecting the file is the master password, so that is still all that needs to be captured. The 2FA part would simply be security theater pretending to offer something more when the master password is all that is protecting the stored file.

But the big issue with the 2FA apps, is that the code provided is only provided once. Symmetric encryption is fundamentally incompatible with a password that is only ever generated once. That one time aspect is how they add security to a network login to a computer system (because a man-in-the-middle has a reduced chance of knowing both during the brief time of a single login attempt). But for symmetric encryption, the exact same key is used for both encryption, and later decryption. With a "one time" password (assuming it is used as intended, only one time), one could encrypt, but then one would never be able to decrypt (because the key would have been lost because of the one time aspect).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zdia/gorilla/issues/201#issuecomment-491319807, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFHHSWMVR6AVLDHSA4E2N3PUWEULANCNFSM4HLRVVQA .

[rich123]

And you've done nothing to add security to the openVPN setup. You've simply added security theater.

The same would apply to this in PWGorilla. It add zero security (only useless security theater).

Because in both cases (openVPN or PWGorilla) an attacker only needs the password without the 2FA to break either.

An attacker is not going to attack PWGorilla (or your work openVPN setup) by going through the gates the PWGorilla source code sets up as theater (nor the openVPN theater setup). Attackers don't follow the rules (hence why they are attackers).

They will ignore the 2FA, capture the password with their keylogger, and open the encrypted password safe (or break into the openVPN connection) without needing the 2FA part at all.

Unless the 2FA code feeds directly into the generation of the key used to encrypt/decrypt, it adds nothing to either setup but security theater.

And, were we to add such security theater to PWGorilla, we open PWGorilla up to being dinged by some security blog somewhere for "offering a false sense of security with a useless, and nonsensical, 2FA setup that does nothing to add any additional protection to the stored password file".

In your work openVPN case, if an attacker does not have the "after stripping 2FA code" password, the openVPN is protected (but not by the 2FA code, but by the fact that the attacker does not (yet) have the "after stripping" password to the VPN).

But, once the attacker managers, somehow, to obtain the "after stripping" password, they can make all the use of the openVPN they like, without ever participating in the 2FA theater, because all openVPN uses for protection is the password "after stripping" away the 2FA code.

[acidjunk]

I agree that it would make it just harder to use the keylogged stuff.

Hmm, so the only safe 2FA would be something that changes the complete master password on every use: after checking the 2FA and maybe prepare a new master pw on the webservice. Not practical/feasible :(

Thanks for the detailed insights. I don't know if there are other things that could minimize the risk of a keylogger.

Feel free to close this issue.

Op vr 10 mei 2019 om 17:49 schreef rich123 notifications@github.com:

And you've done nothing to add security to the openVPN setup. You've simply added security theater.

The same would apply to this in PWGorilla. It add zero security (only useless security theater).

Because in both cases (openVPN or PWGorilla) an attacker only needs the password without the 2FA to break either.

An attacker is not going to attack PWGorilla (or your work openVPN setup) by going through the gates the PWGorilla source code sets up as theater (nor the openVPN theater setup). Attackers don't follow the rules (hence why they are attackers).

They will ignore the 2FA, capture the password with their keylogger, and open the encrypted password safe (or break into the openVPN connection) without needing the 2FA part at all.

Unless the 2FA code feeds directly into the generation of the key used to encrypt/decrypt, it adds nothing to either setup but security theater.

And, were we to add such security theater to PWGorilla, we open PWGorilla up to being dinged by some security blog somewhere for "offering a false sense of security with a useless, and nonsensical, 2FA setup that does nothing to add any additional protection to the stored password file".

In your work openVPN case, if an attacker does not have the "after stripping 2FA code" password, the openVPN is protected (but not by the 2FA code, but by the fact that the attacker does not (yet) have the "after stripping" password to the VPN).

But, once the attacker managers, somehow, to obtain the "after stripping" password, they can make all the use of the openVPN they like, without ever participating in the 2FA theater, because all openVPN uses for protection is the password "after stripping" away the 2FA code.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zdia/gorilla/issues/201#issuecomment-491336867, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFHHSQGSGEDDYZ4YGUEFSDPUWKQPANCNFSM4HLRVVQA .

[rich123]

Hmm, so the only safe 2FA would be something that changes the complete master password on every use: after checking the 2FA and maybe prepare a new master pw on the webservice.

Yes, exactly. Except that you'd need the 2FA code to be generated twice, not just once (in all the current 2FA systems, they are supposed to only generate any given code once).

Minimizing risk of a keylogger is not something that is easily done by changes in PWGorilla (because of the enormous far-reaching access of a keylogger). Mitigating that risk involves preventing the installation of a keylogger in the first place. The reason being that even if you only ever ran PWGorilla on a network isolated, air-gapped, computer that is free of a keylogger, you would still have to type your passwords into your network connected computer to make use of them. A keylogger on that networked computer would not gain your PWGorilla master password, but would gain all the passwords you made use of for login purposes during such time as it was present on that computer. And since the accounts you use most often are also likely to be your most valuable (i.e., your email), the impact is quite great even if the master password to the Password Safe data file never escaped from that air-gapped computer.

So mitigating keylogger risk essentially boils down to two choices:

1. Disconnect your computer from the network and never again reconnect it.

2. Do your best to maintain your OS and other software updates current so as to not become infected with a keylogger.

Since #1 is generally not considered feasible in today's world, #2 becomes the remaining mitigation.