Difference between Account Key and multifactor authentication

SystemSystem

Team Member
edited February 2017 in Lounge
This discussion was created from comments split from: Why not use 2 factor authentication to secure my 1Password Vault?.

Comments

  • Hi,

    The following comes from over 25 years in technology management and digital/cyber security... also, the following is not meant to offend -- Instead to educate and clarify. That is my intent so please take the following words, phrases, terms, etc. as knowledge sharing.

    I respectfully disagree with the sediments that the "Account Key" (= "AK") provides the type of security associated to 2FA. And I completely disagree with the comment that "1Password accounts have something better than two-factor authentication built in actually" -- Frankly, this statement is made with a complete disconnect of 2FA and is disturbingly misleading to your customers.

    *** I'd highly recommend contacting each person in this comment thread and clarifying this misleading statement. This statement is FALSELY misleading your clients to believe that a protection exists -- when it clearly does NOT. It is very bad for your / AGILEBITS business -- particularly because your software is designated as a security software and the statement is blatantly false security statement made out of ignorance of 2FA ***

    Here is why...

    The AK or any type of password REGARDLESS of the security mechanism behind it only provides a SINGLE level of protection or 1FA. The strength of a single factor password is only as strong as the length and complexity of the password - PERIOD. This security feature is completely bypassed by a weak password, shoulder surfing, brute-forcing attacks, etc. 2FA provides significantly added protection against these type of attacks that AK does NOT.

    *** The following is assumed that readers have a basic knowledge of 2FA and/ or multi-factor authentication e.g. something you have, something you know, who you are. If not, please perform a quick internet search of 2FA, multi-factor authentication, etc. ***

    2FA offers a second level/ degree of security because it utilizes a dynamically changing security code that is obtained/ delivered through a trusted method (e.g. Key Fob, USB key e.g. YukiKey, APP e.g. Google Authenticator, SMS e.g. text msg, etc.).

    [BTW text messages is the weakest of the 2FA options I listed above because there are test weakness]

    2FA protects against weak password, shoulder surfing, brute-forcing, etc attacks due to the delivery method and time-limited nature of the code/PIN mechanism.

    Consider the following analogy: Credit card with versus withOUT a security chip/PIN.

    Almost all of us have personally or know someone who has experienced a false credit card purchase. Why?

    Primarily because credit cards are easily copied. This allows anyone (e.g. criminals) to make unauthorized purchases using that duplicate/ fake credit card.

    A vendor that forces purchases to utilize enhanced security features like chip/PIN almost completely stops / protects against these types of false purchases. Why? Simply because the purchase relies on knowledge of the secret PIN at the time of purchase. The PIN is supposed to validate that person using the credit card is the legitimate owner of the credit card because only the legitimate owner knows the PIN for that credit card. Therefore, this PIN is the 2FA equivalent of the credit card model because it is based on "something you know" (first factor) in addition to the "something you have" (second factor) which is the credit card.

    The FALSE statement noted in a previous comment above -- is analogous to a vendor saying "we have extra secure credit card terminals that that have enhanced security features and does all these security testing in the background". However, where that model falls completely -- is if a person (e.g. criminal) uses a duplicate/ fake credit card the credit card terminal accepts but has not method to check if the person presenting the card is actually the real owner.

    The same way that chip/PIN 2FA model protects credit card purchase is similar to the way 2FA model protects passwords.

    1password has a built-in mechanism to provide for OTP (one-time password) which is fantastic because this supports the 2FA model --- but has many drawbacks, which I am not going to get into now.

    What would be a fantastic security feature if 1password enable 2FA to unlock password vaults.

    LastPass and many other of 1Password competitors support the 2FA model using tools like eg Google Auth, YubiKey, etc. I've used many of them but the one challenge is have is the cloud nature of many of these tools and possible breach exposures (again -- this could be an entirely different thread).

    Personally, I like and use 1Password because of the non-cloud feature and ability to sync via my trusted wifi network -- thereby reducing the overall threat landscape.

    IMO, the most significant drawback and missing security feature is of 1Password is 2FA.

    Just in case the "finger-print" point is brought up, let's clarify that finger-print recognition (under its current implementation on iPhone's, laptops, etc) is NOT 2FA -- it is simply an alternate to password which still makes it 1FA.

    Thank you for listening and I'm am open to comment and questions.

  • brentybrenty

    Team Member

    @AndyAndy: I hope you don't mind, but I've split your comments off into a new topic rather than pile on to that old thread so we can discuss this in more detail.

    I think we're actually in agreement on the main points and perhaps just arguing semantics and philosophy. The Account Key is not the same as traditional multifactor authentication, and that's its strength. Based on your comments, that probably sounds laughable to you, but it's true and I'll come back to that. As mentioned previously, it strengthens the security of your data by encrypting it, rather than strengthening the security of your login by being an additional factor that's required over and above a username and password.

    What it really comes down to is authentication versus encryption. Things like one-time passwords are used to authenticate the user before granting access, whereas the Account Key is used to encrypt the data, regardless of access.And the most significant risk which you touched on, is having credentials compromised. When one-time passwords are transmitted, they have the potential to be captured, whether that means you receive or send them over a compromised channel. And if you're sending credentials over a compromised channel, the attacker can probably get everything: username, password, and one-time code. In this scenario, which is not at all outlandish, this authentication process does not protect you.

    Conversely, the Account Key is not merely a token for authenticating you with the server; rather, it is needed to decrypt your data. And, also unlike a one-time password, it is 1) generated locally on your device, 2) stored only where you choose, and 3) never transmitted. So literally the only way for someone to get it is from you directly, either by hitting you on the head or controlling your machine to capture it.

    Certainly multifactor is useful, and in cases where authentication is really the only layer of security between an attacker and your important account, it's crucial; but 1Password.com is a very different beast. We have users' encrypted data, and we want to make sure that an attacker cannot gain access to it even if they gain access to our servers. That isn't a threat that one-time passwords can protect you against. To put it more bluntly, if someone hacks 1Password.com, grabs the database, and takes full control of the server, they can't decrypt your data because we don't have your Account key, and when you login you're not sending it to the server either.

    You say that we've made false, misleading statements, and go on to explain in detail your position, but I'm not entirely clear on what you feel was actually said which was false or misleading, and you haven't asked about these things directly. If you can specify what you're referring to, we'll do our best to clarify.

  • Hi,

    I am good with the comment split as long as once we are clear in this thread -- that the posters of the original thread are updated that encryption is not a replacement (better or worst) for 2FA. That both are necessary for good security.

    I guess, where my point stems from is based on the initial thread entitled:

    "Why not use 2 factor authentication to secure my 1Password Vault?"

    And the initial comment/inquiry:

    "Why is it not a security weakness that all of my passwords are secured with only 1 master passphrase? What if some focuses their effort on hacking my 1Password Account? Have you considered 2 Factor Authentication for logging into 1Password? Or is there some other reason I need not worry bout this?"

    Where I felt it necessary to include my commentary is when Jacon (Agilebit staff/ rep):

    1. Altered the thread theme from 2FA authentication to encryption -- two entirely different themes; and,
    2. Then Jacob made the statement that encryption is somehow better 2FA authentication; and,
    3. Most importantly, when a poster came to the false conclusion that encryption is better than 2FA, Jacob failed to come back and clarify authentication and encryption are mutually exclusive.

    Yes, I agree the account key mechanism that is described is a critical data-at-rest encryption feature. IMHO, this should be included as an absolute base feature considering the function and highly sensitive contents of any password vault app.

    However, it is NOT better nor does it protect against authentication based attacks which is was the overall theme of the post and the follow-up questions. Thus is why my commentary was around the post's initial theme which is 2FA and authentication.

    For a strong security both data-at-rest encryption and enhanced authentication mechanisms are critical to protect any highly sensitive data.

    Much like a seat belt and anti-lock breaks are important for driver safety. One is not better than the other -- they are both necessary for overall driver safety.

    I hope this clarifies my commentary and I hope that a response is made in the initial thread so that the original poster and all the other inquiries not left with incorrect conclusions.

  • @AndyAndy: Could you describe a plausible scenario (relevant to 1Password) where 2FA would protect the user better than the Account Key?

  • Hi,

    2FA and AK are two separate and mutually exclusive security mechanisms and thus offer protection from two completely different attacks vectors.

    For example if a laptop, phone or other device was stolen.

    2FA protection...
    If the thief had knowledge of the password -- they would have full access to the database. This is where 2FA would offer protection because knowledge of the password would be insufficient as they would also have access to the second factor One-Time-Passcode / PIN delivered via secondary APP, token, SMS message, etc.

    Alternatively, if the thief did not know the password, 2FA would protect against all attempts of brute-forcing (guessing of passwords) because again the secondary OTP / PIN would be required.

    AK protection...
    AK provides encryption protection mechanism. Which effectively turns the the database from clear text into an unreadable format. Assuming the database encryption strength is sufficient that it can not be decrypted.

    Perhaps another example to illustrate this is...

    Earlier versions of Adobe PDF writer and MS Office allowed a user to password protect documents. Which was great, until someone realized that the files themselves were not encrypted and the password protection was only triggered within Adobe or MS Office -- so simply opening them in a 3rd party product allowed complete access to the file without the need of the password at all.

    After realizing this, Adobe and MS Office began encrypting and password protecting their files. In the beginning, both used weak encryption schemes. Thus using the right tools, both files could be decrypted and passwords brute-forced.

    At present, both products use much stronger industry tested encryption mechanisms (eg AES 256). However, regardless of the encryption level, they are still susceptible to brute-force attacks (password guessing).

    Using parallel GPUs millions of guessing can performed in just a few seconds. With most people using a 8, 10 or even 15 character password with generally a poor complexity -- brute-force attacks may take seconds to minutes. Not many are crazy, such as myself, and people use 30+ character, highly complex passwords.

    2FA provides increased security against brute-force attacks. Even with someone using a weak 8 character password.

    I hope this assists.

  • So BOTH encryption (AK) and 2FA adds to the security of 1Password. Neither is stronger than the other as they defend against completely attack vectors. Their security is cumulative.

  • 2FA and AK are two separate and mutually exclusive security mechanisms and thus offer protection from two completely different attacks vectors.

    I don't understand what you mean by "mutually exclusive" here. 2FA could be used together with the Account Key as an extra layer of security when accessing 1password.com. In fact, as I understand it 1Password for Teams does indeed offer both 2FA and AK. Correct me if I'm wrong.

    2FA provides increased security against brute-force attacks. Even with someone using a weak 8 character password.

    But brute-force attacks are only relevant once the hacker already has access to the encrypted data. So I don't see how 2FA provides protection against brute-force. 2FA only protects against logging into 1password.com. So it also doesn't protect against a stolen laptop or similar.

  • Another example is when you access LastPass, Google, Facebook, Twitter, banks, PayPall and 100's of other services, etc.

    • They use SSL as the encryption to protect against Man-In-The-Middle and eaves-dropping attacks
    • They also offer a 2FA type mechanism to protect against password based attacks

    Both are important. Just one is simply lacking and insufficient.

    It has taken about 15 years and finally more and more providers are offering 2FA beyond as a supplementary method to protect against arguably the most common type of attack --> password based attacks.

    With value of the data within a password manager database --- I would encourage that 2FA be a top priority over added functionality or almost everything else.

    Cheers.

  • Another example is when you access LastPass, Google, Facebook, Twitter, banks, PayPall and 100's of other services, etc.

    I would argue that only LastPass is relevant for comparison here. The others cannot offer the same zero-knowledge encryption that LastPass and 1Password do. Thus, when dealing with sites like Google and Facebook, secure authentication is your primary (if not only) defense against attackers.

    Sorry, I still don't see the big need for 2FA. But I suppose you can always argue that extra layers of security are better.

  • brentybrenty

    Team Member

    Thus, when dealing with sites like Google and Facebook, secure authentication is your primary (if not only) defense against attackers.

    @pervel: That's what I was getting at but I'll be the first to admit that I didn't explain myself well.

    @AndyAndy: The point I'm trying (and perhaps failing) to make is that, in the case of storing sensitive data (like 1Password does), authentication provides little real security without encryption.

    Certainly you're correct that both have their uses and protect against different types of attacks, but if 1Password used authentication alone, none of us would be comfortable using it to store our most sensitive, important information. This is provable I think since I'm confident that no one here stores this kind of information in their email account, which is protected only by authentication. Conversely, encryption has a proven track record of securing this type of data, both in the case of 1Password and other similar products. If this were weak and exploitable, the whole industry would have disappeared long ago, because it's all built on encryption. Some offer authentication in addition to this for specific use cases, but no one is eschewing encryption because it's so fundamental and we'd all might as well just post our data publicly since it would end up there anyway when — not if — servers are breached. :angry:

    To bring it back to the basics, the kind of attack that authentication would protect against simply does not apply to the standalone version of 1Password. Since the data is not hosted, there's neither an opportunity for this risk nor a means to protect against it (by authenticating with the server). Somewhat similarly, with 1Password.com, the data is hosted, but only in encrypted form, and we never have the keys needed to decrypt it, and they are never transmitted. Certainly we could add a more traditional multifactor authentication, but this would be more applicable to account management rather than data, since, again, we don't have what an attacker needs to actually access the data. Finally, authentication and encryption are mutually exclusive in the sense that something like a time-based password cannot be used to encrypt the data, as it's changing. I suspect that what you're thinking of is that they can both be used as part of an overall security strategy, but not in the sense that they interact with each other. :glasses:

    Authentication does not protect against brute force attacks. In order to perform a brute force attack on your data in the first place, the attacker has your data. At this point they've already circumvented authentication in some way (usually by reset/recovery process, but gaining access to your device directly accomplishes this as well). Your scenario with the stolen laptop seems to assume that an attacker would try to use the 1Password app manually, which would then require a one-time password to unlock, but at that point they have your data and can bypass that and perform an automated brute force attack on the data on disk. Encryption does defend against this sort of attack, and ultimately its the only one we need to worry about since authentication is just another obstacle, like getting your device would be. :sunglasses:

    Similarly, brute force attacks against your data are technologically infeasible on a few levels if you have a sufficiently strong Master Password, as that will be your weakest link. And the 128-bit, randomly generated Account Key means that an attacker cannot actually perform a brute force attack against your Master Password itself since it is also used to encrypt the data. Even someone with a weak Master Password has the benefit of those additional 128 bits of entropy, and PBKDF2 significantly slows down brute force attempts on top of that. Your "30+ character, highly complex password" is going to be more than sufficient for many years to come, to put it mildly. :)

    So when we say that encryption is better, it's absolutely true in this context because it actually protects your data where authentication cannot. The context is important though: we're not saying that encryption is always better than authentication, in any context, because the context may make a difference. But since this is the AgileBits support forum and we're talking about 1Password and its security model, I hope you'll forgive us for making statements that are applicable to the topic at hand, as it also happens to be our area of expertise since we don't have an interest in evaluating these things as they apply to other companies products and services; we're in the business of making 1Password a great tool that's helps both us and our customers secure our most important data. :blush:

  • I must say that as a long tim customer of 1Password with many licences, I am disappointed at the stance that is projected around 2FA.

    I get it about -- you want to and perhaps have to defend your stance around encryption and AK.

    However, it is irrelevant the strength or length of a password because a simple key logger (very few systems are 100% malware free) or brute force attack (leveraging increased GPU speeds) can defeat it for reasons previously covered.

    Also, that more and more providers including competitors to 1Password are enabling FIDO + U2F complient 2FA systems have me wondering why is 1Password so hesitant against it?

    Does it take a breach or attack to react?

    Would you not want to get ahead of attacks instead of responding?

    Just leaves me (a customers) scratching my head and looking for alternatives.

  • Does it take a breach or attack to react?

    But that's the point. 2FA does not protect users against a breach of their servers. The Account Key does!

  • rickfillionrickfillion Junior Member

    Team Member

    @AndyAndy,

    I think what it really boils down to is that "2FA" is too broad a term. It's really difficult for us to discuss it because depending on the use, it means very different things from our perspective.

    We do support 2FA in the form of Duo. In this case we support it for a very narrow set of features : login to the admin console. There's a reason that we did this, and I hope that by explaining it, I'll shed a bit of light on the struggle here. From the Admin Console you can do a bit more damage than you would be able to from say our native apps as it can do more. This becomes a bit of a concern for us going forward as we want to bring some of that power down to the apps, but that's going to be up to us to figure out.

    In the case of Duo, it's part of the server session authentication handshake. Instead of Duo, let's say we used TOTP since that's more widely understood (and for the purposes of this discussion they can be considered similar enough). How does TOTP work? You've got the TOTP secret, and a function that takes the secret and current time, and it outputs the 6 digit code. How would it work in our case? Our server would generate a secret for the user account and save it in our database. We'd make that secret available to the user somewhere so that they can get it into an app (say Authy or Google Authenticator). When doing the handshake with the server, the server would respond saying "yea, that's nice, you'd like to create a session with me... but we're not gonna move forward without the TOTP code." The webapp would get the response, know to provide a UI for the user to get the code from Authy and punch it in. The webapp sends the request, the server validates the TOTP code based on its known secret and it then creates a session.

    This all worked because the two sides had a shared secret. One side proves to the other that they have the secret by providing a value derived from it.

    The authentication process required to create a session with the server actually gives us a decent place to make use of 2FA like that. And that's why we've implemented it there with Duo. It's limited to Teams for the time being. We see value in bringing that to Families and Individual accounts too, but we aren't sure if we want it to be backed by Duo or something else.

    Often times when people think of 2FA within the context of 1Password, what they're thinking of is 2FA as part of the unlock process. So that even if someone were to guess your Master Password, they wouldn't be able to get at the data. Let's walk through what that would require.

    First let's just address the medium sized elephant in the room. If an attacker has my 1Password data, and my Master Password and my Account Key, I'm going to go ahead and say that they probably have my 2FA secret as well. But for the sake of argument, let's say they don't...

    All of our clients (except the webapp) are built to be offline apps. They've always been offline apps that happened to be able to sync data, and 1Password accounts don't really change that. This means that the app has to have all of the data locally that's needed to unlock the vault and decrypt the items. 2FA could still work while offline, there's nothing about the 2FA concept that requires an internet connection (especially if based on something simple like TOTP). But it brings about an interesting problem : where would we store the TOTP secret? Where on a system could I store a secret that the 1Password app could access while offline that an attacker wouldn't be able to trivially also access when stealing the database? There really isn't anywhere. I'd love to hear ideas for this, because if you have a solution for this problem then there's a whole pile of fun features I'd love to add that are dependent on it.

    So there's a bit of a mismatch there between the fact that the apps don't require an internet connection and doing 2FA during the unlock process simply because there's nowhere to store the secret such that it's not trivially bypassed.

    In my opinion, in order to provide 2FA during unlock, we would need to provide an "online only" mode. This would change how the client apps work such that they aren't expected to work at all while offline. For some people, the inconvenience would be worth it.

    Here's how such a thing could work... The client app could still contain vault data. The vault data is encrypted with a vault key, and this is a randomly generated key that no one should have any worries about cracking. What we'd stop allowing it to save is the various keys needed to 1. verify your master password, 2. decrypt the vault keys. This way an attacker would have nothing to even start brute force attacks with. The unlock process would be changed to being a two step process : 1. auth with server, 2. download encrypted keys from server with which it can unlock the vault keys. It turns out that this two step process is actually something we already support in some of our apps (Mac and iOS) and is what allows you to change your account's Master Password on one device then unlock the app on another device with the new Master Password. It's also why sometimes it takes a few seconds for the app to tell you that your Master Password is incorrect when it's wrong (it tried to auth with the server with it).

    If the unlock process includes an auth phase like that, then we suddenly re-gain the place to store a shared secret for 2FA. The server can store it.

    Last fall Shiner and I spent a couple days experimenting with this Online-only concept. It's neat, and it has some benefits. There's still some corner cases that we didn't have answers for, which is why it's not a feature yet.

    So let me ask you this... would you be willing to give up offline access to your data in order to have 2FA as part of your app unlock?

    Rick

  • Frankly, online/ offline access should not be in the discussion or requisite cost of implementation 2FA.

    2FA can come in many forms including a soft token (eg Google Authenticator), hardware (eg Yubikey), SMS, biometrics, etc

    The goal is simple: adding more than just "something I know" as a way of accessing my vault. Including "something i have" (eg tokens above) protects the vault against almost all password attacks. These days, It is simply too easy to obtain passwords via key loggers, malware, screen scapers, etc, etc.

    I am confused why this is such a difficult sell?

    Are your clients not worth the investment in 2FA?

    I advise many clients around the world.

    I like many of the offline features of 1Password; HOWEVER, I must admit I am challenged in continuing to recommend 1Password because what I fell is an overwhelming opposition to allowing such a basic level of protection that will likely be default on almost all systems with a few years.

    Why is 1Password so opposed to this? Particularly given is a security product tasked with protecting highly sensitive authentication and other information.

  • XIIIXIII
    edited March 2017

    @rickfillion Thank you for providing so much detail.

    where would we store the TOTP secret? Where on a system could I store a secret that the 1Password app could access while offline that an attacker wouldn't be able to trivially also access when stealing the database?

    Can you please explain why the secure keychain is not an option on iOS/macOS?

  • rickfillionrickfillion Junior Member

    Team Member

    That's a great question @XIII.

    The iOS and Mac keychain are really quite good. We use them for certain things (more on iOS than on Mac, but I'll avoid going on a rant there).

    If an attacker is in a position to steal not only my database off my Mac, but also my Master Password, I think it's likely that they're also in a position to read the keychain. If they know my master password, account key, I think there's a good chance they also know my system password and whatever other protections would impede them from getting at data in the system keychain.

    If the attack vector is someone rooting my Mac to get to my Master Password there's literally nowhere on the Mac that's safe.

    Replying to these threads is difficult, because I really feel like I come off as being anti-2FA. We're trying to be open and honest and talk about attack vectors and how various things do and don't protect against them. It really helps us when people discuss specific things that they're looking to protect against so that we can avoid making blanket statements.

    Andy made a great point in his last reply about Yubikey. There's actually an opportunity there, and this is my fault for not going into those solutions. With Yubikey and some other hardware based solutions that don't involve shared secrets you could implement a key splitting solution locally which would actually add some security. The app could be made to require not just your Master Password and Account Key, but also an extra bit of data that can only be provided by this other piece of hardware.

    One of the purposes of the Account Key was to get some of the benefits of key splitting, and helps with some of the same attacks. It would be really cool if we went beyond that.

    Rick

  • XIIIXIII
    edited March 2017

    I use(d) a Yubikey with LastPass, but only on Windows/macOS (and Solaris...).

    Yubico also offers a Neo version that works via NFC with Android, but "of course" Apple won't allow you to do that on iOS...

    (Could the secure enclave play a role there?)

  • rickfillionrickfillion Junior Member

    Team Member

    Unfortunately the secure enclave isn't really programmatically available to us, and instead we have to interact with it via the Keychain APIs.

    I didn't realize that they had something for Solaris. I still think Solaris is the coolest operating system name of all time (I'll limit my cool claim to the name as I've never had hardware that it liked much). Heck I'd even put SunOS second. :)

    Would you mind sharing with us how you used the Yubikey with those? I think I know, but I'd rather not make assumptions.

    Thanks

    Rick

  • Would you mind sharing with us how you used the Yubikey with those?

    On SunOS/Solaris? I used the non-binary version of the LastPass Firefox extension and inserted the Yubikey in an USB slot of my SPARC workstation, with this setup: https://lastpass.com/yubico

  • brentybrenty

    Team Member

    @XIII: Ah, interesting. Thank you! Bonus points for "non-binary". :pirate: :+1:

    @AndyAndy: Rick did a great job of laying it all out. While we could certainly just do whatever you tell us to, that doesn't address the question of security; it's just a checkbox. I think the point he was trying to make is that the details matter. Adding two-factor authentication superficially is just security theater.

    2FA protection...
    If the thief had knowledge of the password -- they would have full access to the database. This is where 2FA would offer protection because knowledge of the password would be insufficient as they would also have access to the second factor One-Time-Passcode / PIN delivered via secondary APP, token, SMS message, etc.
    Alternatively, if the thief did not know the password, 2FA would protect against all attempts of brute-forcing (guessing of passwords) because again the secondary OTP / PIN would be required.

    What you describe needs to authenticate with something. And if you're offline, it either isn't possible, or we have to store a secret locally which could be vulnerable to attack. After all, if what we're trying to protect against with this is a compromise of your machine potentially allowing someone to capture Your Secret Key and/or Master Password, authenticating with something locally is risky (and arguably not a second factor anyway).

    As Rick mentioned,

    If an attacker is in a position to steal not only my database off my Mac, but also my Master Password, I think it's likely that they're also in a position to read the keychain.

    The Keychain is the best option available to us, and even it is problematic when it comes to a compromise, which is ostensibly the whole point of the 2FA solution you're proposing. Even if it would be nice to say "we have 2FA", it has to be practical and offer a real security benefit or no one would (or, at least, should) use it.

  • primeprime
    edited March 2017

    I've said this in another thread. When you use 2SA, you usually (I always have) get a recovery key. These recovery keys are about 14-20 characters, so how is it any different with the secret key that's 40 characters long? I actually feel safer with the secrecy key then using 2SA with a recovery password.

    2SA:
    Your password
    1 time password
    OR
    Recovery Password

    Again, it an attacker has your password AND your recovery password, 2SA is useless.

    A few sites will give you a few recovery codes. Instagram gave me 5 and they are only 8 chararers long (all numbers).

    Also, using SMS for the 2nd factor is a horrible idea. It's not secured at all.

  • brentybrenty

    Team Member

    @prime: I think that's the difficulty with discussing "2FA" that Rick alluded to. There are many different implementations, and not all are created equal, both from a security standpoint and usability. There's a lot we need to take into account before adding features like this to 1Password. On the one hand, we don't want to make it easier for people to lock themselves out of their data; but at the same time, an escape hatch for users can also be a weak link.

  • primeprime
    edited March 2017

    @brenty and no matter what you guys do, it will be wrong lol. It can't be easy trying to come up with something that works for everyone.

    One idea that people can do; if they log onto a public computer and worried about their secret key, they can always change it later to be on the safe side.

  • brentybrenty

    Team Member

    @brenty and no matter what you guys do, it will be wrong lol. It can't be easy trying to come up with something that works for everyone.

    @prime: Thanks for the vote of confidence! :lol:

    But in all seriousness you're right: we can't please everyone, but if we can come up with a secure solution that works for most people I'll call that a win. ;)

    One idea that people can do; if they log onto a public computer and worried about their secret key, they can always change it later to be on the safe side.

    Absolutely. While it isn't as apparently convenient as a dongle, it's also one less thing to lose and it can be changed afterward if you have to use an untrusted computer in an emergency. Cheers! :)

  • @brenty I have confidence in you guys, just not in people lol!! People love to complain, and sadly I know I have. This is why I like it here and support Agilebits, you guys put up with me lol.

    I know I've came off like a jerk a few times, and I do apologize for it. I even tell people there's been times I know I was hard on you guys, but you all kept your cool and were a big help.

    The internet is full of people who will complain about everything they can find.

  • brentybrenty

    Team Member

    Hey, it takes all kinds! :lol: :+1:

  • edited June 2017

    @rickfillion: "Andy made a great point in his last reply about Yubikey. There's actually an opportunity there, and this is my fault for not going into those solutions. With Yubikey and some other hardware based solutions that don't involve shared secrets you could implement ...."

    Fantastic, thanks Rick!

  • Drew_AGDrew_AG 1Password Alumni

    On behalf of Rick, you're very welcome! :)

This discussion has been closed.