Security measures that can be added?

edited January 2014 in Mac

Hello to the comunity.
1Password Is perfect, I love it! And as a programmer, I want to suggest some security measures that can be added.
1) While some users has 1Password on many devices (Mac/Windows, iPhone/iPad, Android) any of these devices can be stolen. So may the thief can take control of password. So it would be a good idea to set some "wrong-password-attempts" that when a user enter 5-10 times wrong password, evreything included the encrypted file to be deleted.
If user choose this option, the 1password will notify the user, to make backups to external devices or cloud.
2) A usb device holding a unique password, that will be used as a 2-step-verification for computers only.


  • MeganMegan

    Team Member

    Hi @cypro,

    Welcome to the forums! Thanks so much for the kind words - it's always so great to hear from happy users.

    1) While some users has 1Password on many devices (Mac/Windows, iPhone/iPad, Android) any of these devices can be stolen. So may the thief can take control of password. So it would be a good idea to set some "wrong-password-attempts" that when a user enter 5-10 times wrong password, evreything included the encrypted file to be deleted. If user choose this option, the 1password will notify the user, to make backups to external devices or cloud.

    This sounds like an intriguing suggestion - I'll pass this on to our developers to see if we can find a way to integrate it! It brings up a good point though: the strongest protection for your database is a strong Master Password. We've got a great article on how to create passwords that are both strong and fairly easy to remember/type: Towards Better Master Passwords.

    2) A usb device holding a unique password, that will be used as a 2-step-verification for computers only.

    You're certainly not the first person to suggest something like this! In fact, there's a pretty lengthy thread discussing it in our 1Password Lounge. Being a developer, you'll probably understand a lot more of the technical ins and outs than I do. :)

  • There is a discussion somewhere on the AgileBits site about why the developers have chosen not to erase your data after some fixed number of tries, but I can't find it now. And my memory of it is too hazy now to attempt to repeat it. I remember that I stopped worrying about it after I read it, though.

  • JasperJasper

    Team Member
    edited January 2014

    Hey @cypro,

    Just to add a few more comments here:

    1) While some users has 1Password on many devices (Mac/Windows, iPhone/iPad, Android) any of these devices can be stolen. So may the thief can take control of password. So it would be a good idea to set some "wrong-password-attempts" that when a user enter 5-10 times wrong password, evreything included the encrypted file to be deleted. If user choose this option, the 1password will notify the user, to make backups to external devices or cloud.

    Keep in mind that iOS has a built-in erase data function to erase all data on your device after 10 failed passcode attempts (Settings > General > Passcode > Erase Data). In addition, you can do a remote wipe of your iPhone, iPad, or Mac using Find my iPhone. I think this would be more secure, since you can erase everything before an attacker will even have access to your encrypted 1Password data file.

    I think @hawkmoth is right, this has been discussed before, though I can't remember what was said about it.

    But my thought is that a "self-destruct" function in 1Password would kinda be a "security theatre" feature. It might make you feel safer, but not actually increase security in the event of a real attack on your 1Password data. During a brute force attack on your encrypted data, an attacker would most certainly not actually enter passwords attempts into the 1Password app. They would use a separate program to try and break your 1Password data without actually using 1Password, which would easily bypass any self-destruct function built into the 1Password app. I would imagine that such a feature would also lead to another issue - cases of accidental destruction (or even malicious destruction) of user's data, leading to complete loss of 1Password data if the user has no backups available.

    Sound right to you, @Megan?

  • This has something to do with the difference between the needs for encryption/decryption and identification too.

  • True. Cheers for the replies. I think, the YubiKey will be something cool, and you can add it as optional.

  • MeganMegan

    Team Member

    Hi @JasperP,

    I think you're right here. Such a feature would only have limited usefulness. Thanks for adding your thoughts! If we get any more technical though, I'm going to need to call in our security guru, as this is almost getting above my head :)

    Basically, it always comes back to having a great Master Password so that an attack has an infinitely smaller chance of accessing your data. Then many of these extra measures become bonuses instead of necessities.

  • I'm not clear -- if "it always comes back to having a great Master Password," doesn't the Yubikey offer a solution to even weaker ones? Or is it a device that only assures your bank that it's really you who is logging in to withdraw funds?

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Hi @cypro and @junnny‌!

    As @hawkmoth‌ has correctly pointed out, things like authentication factors and lock-outs only make sense in the context of an authentication system. 1Password isn't an authentication system.

    Authentication systems

    For many systems, you use a password to prove who you are (someone who knows that particular secret) and the system you are proving to will decide whether to let you in based on that proof. The system might require additional proof (multifactor authentication) or it may say you aren't allowed to try again after your attempted proofs fail (lock out). It might even destroy it is guarding.

    Let's look at these systems as having three parts.

    1. There is the Penelope who is trying to prove who she is.

    2. There in Vincent who is trying to verify the proofs that Penelope offers

    3. And there are Resources that V is guarding, and may grant P access to.

    That is what typically logging into some system is. The Resources may be a complex set of things that Penelope will be authorized to do, but we don't need to deal with that level of detail. Once V verifies P, V lets P have access to R.

    Security issues with authentication systems

    There are some really nice things that can be done with authentication systems. But first I want to talk about some problems.

    1. V has access to R.

      V can do stuff with R even without P's involvement. V can act against P's interests, either by design, coercion, or accident.
      But V does have access to R. V could decide to change what proofs
      he requires at any time. Maybe it is to require more proof, but maybe
      to require less. He can decide to grant access to those others than P.

    2. There may be a way around V

      If you think of V as a guard at a door, perhaps someone can get at R through a window that V isn't guarding. This is typically what happens when someone breaks into a site or service through means other than tricking V. The break into the building that houses R through some flaw in the building that isn't part of V's door.

    Those, in terms of security, are the principle downsides of authentication. Lots of systems have to work by authentication. They didn't have the choice that we have. So when your bank site uses authentication, it's not because they've picked a weaker system, it is because it is the right system for their circumstances.

    There are also some really nice things about authentication systems.

    1. Vincent can require additional proofs from P if needed.

    2. Vincent can stop talking to someone claiming to be P but failing to prove that she is

    3. Vincent can destroy the Resources if someone pretending to be P becomes too much of a threat.

    4. Others can do things on P's behalf with R. Perhaps just keeping it tidy, but perhaps doing more for example if R is money in a bank and the bank is authorized to do stuff (put in payments, make payments, etc)

    5. Different individuals can have different powers over R.

      Penelope could tell Vincent that Quentin is allowed to look at R but not change an of it.

    Those are all some things that can be done relatively easily with an authentication system. So, as I said, there are often very compelling reasons for things to be set up that way, despite the drawbacks.

    Encryption systems

    With encryption systems there is no Vincent. There is Penelope (who is now a proprietor and not a prover) and there is her **Message*. (There are good reasons why I'm calling the "message", but I'll leave that for another day.) The Message is all of her data that she would like to protect.

    Penelope also has a small Secret (with will be her Master Password). She may wish to keep her Message secret, but it is large. She can't keep the Message in her head. But she can keep her Secret in her head.

    Encryption is a process that transforms a Message into gibberish. I'm going to call that gibberish Ciphertext. So encryption is a process that transforms M into C, and decryption is a process that transforms C into M. The actual encryption and decryption depend on her Secret

    So suppose M is

    Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.

    Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this.

    Encrypting M using S might result in a C that looks like:




    To transform Ciphertext back into the Message involves decryption, which also requires the Secret. Encryption and decryption are about transforming data from messages to gibberish and back again.

    Note that everything about who the encryption system works is public.
    The only thing secret is the Secret. To get a better understanding of
    why that is how good cryptographic systems are built take a look at
    "You have secrets; we don't: Why our data format is public."

    There ain't no Vincent to get around

    There is no Vincent in this process. There is no entity that has or controls access to M other than P herself. Only Ciphertext gets stored any where. When Penelope uses her Secret to decrypt C, then M may only exist temporarily in the computer's memory.

    To answer the questions


    Locking people out or destroying the data assumes that the 1Password program is acting like Vincent. But it isn't. The 1Password program is there to help you manage your own data, but it is never granting access in the way that Vincent is.

    We presume that any serious opponent, Oscar, will have obtained a copy of C, and will have made as many copies of C as he wishes. Oscar does not need to do anything with the 1Password program at all. He obtains C off of the device or off of a sync service and then he tried to transform C into M. If the encryption system is well designed, then Oscar's best chance is to simply make repeated guesses at S. The actual
    details of the encryption system are public, so Oscar will be using his
    own specialized software to take guesses and see if they work.

    Multiple factors

    In one important sense, C itself is a factor. Oscar (and Penelope) need both C and P to get M. Contrast this with an authentication system. P just needs her proof (or proofs) to present to Vincent. But the Resources will become available to anyone who is able to trick Vincent.

    But if we want to third factor, beyond C and S, then the way to do that is to create two secrets that need to be combined to create S. That is, Penelope encrypts S using a separate secret, S2 to create S1. So S1 and S2 have to be combined in a particular way to create the Secret that that is needed to transform C into M.

    This, by the way, is really easy to do cryptographically. The hard part is getting this to work across a variety of systems. If P has a copy of C on her iPhone, and a copy of C on her Windows PC, then she will only be able to decrypt C if she can provide both S1 and S2 on every system on which she needs to do that decryption.

    Anyway, it is now past 1am, and I need to take Molly to the vet early tomorrow. So enough for now.

  • I'm no security jock, but i keep reading articles about the merits of a two-step authentication -- for example:

    You're always going to be more secure if there's a way to verify that it's you who is online sending messages or withdrawing funds from a bank account rather than someone pretending to be you. I thought the Yubikey says, "It really is me who is at the keyboard." At the very least, the Yubikey can provide a very robust "master password" -- which Agilebitists encourage, I thought. Adding anything two-step seems better still.


    Using 1P, I've got really robust passwords for most everything at this point and so, I suppose, the chances of hacking my Amazon account, for example, approach impossible. But, why not go for “the MOSTimpossible” rather than just employing the astronomical odds strategy as 1P is doing?

    Besides, the Yubikey is cool :-)

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    @junnny‌ wrote:

    Besides, the Yubikey is cool

    Indeed it is. I've really enjoyed playing with them. A Yubikey has two modes of operation. The first is as a "One-time Password" (OTP). (Not to be confused with a "One Time Pad".) The second is a static password mode.

    One-Time Passwords are cool

    This is really cool and it is useful in a a number of cases. It is, however, of no use whatsoever for a system that doesn't have a "Vincent". It requires that Vincent knows the same secret that the Yubikey knows.

    That OTP mode is very very useful for when passwords are transmitted over not perfectly secure channels. If Eve eavesdrops on the communication between Penelope and Vincent, she can learn the One Time Password, but it won't do her any good because that particular password can only be used one time. OTPs are great for when Penelope needs to prove who she is to Vincent over an insecure channel.

    With 1Password, your Master Password is never transmitted at all. So there is no need for a OTP. The security problem that OTPs are designed to solve do not apply to 1Password. It's simply not a threat that exists. Furthermore, as I said, there is no Vincent in the picture.

    Static password mode

    It's other mode of operation of a Yubikey is conceivably useful with 1Password. The Yubikey simply stores a random password on it that you can have it emit. So the password on your Yubikey could be something like "svEs1nmtSTKCWy" and the Master Password in your head could be "correct horse battery". The full Master Password that 1Password requires would be "correct horse batterysvEs1nmtSTKCWy". You type in the first part and you have your Yubikey type in the second.

    You don't actually need any changes to 1Password to use a Yubikey that way on Mac and PC. You can do that today.

    But what happens when you need to use 1Password on iOS or Android?

  • What happens when you need to use 1Password on iOS or Android? You get a Yubikey NEO [ ] and get mobile authentication through NFC ... if you have an Android phone, that is, and when and if Apple ever gets around to implementing NFC :-)

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Yep. Those Yubikey NEOs are fun to play with.

This discussion has been closed.