Feature Request: YubiKey Support

2

Comments

  • ehunt123
    edited December 1969
    I'd assume that you could implement a system like Rohos has (or is still trying to get done properly) using the SecurityAuthorization framework, if the Yubikey were to retain its "truly secure key". Or, assuming the agilekeychain uses its masterpass as part of the salt, having the unique OTP (uses modhex) be one half.

    There was some work to get a login system done using a system like this (user's keychain is secured by a pw + the otp -- requiring both) in 10.5 but has not been updated, unfortunately.

    Some ideas:

    Even with the various wrappings of pks11 and other "CaC", a YubiKey is not a true pks#11 key, the key itself would require some serious hacking inside the pks stuff (trunk is on macosforge) to work, so this wouldn't be a quick bridge to getting it working.

    It was quickly integrated into pam under linux, almost three years ago:

    http://code.google.com/p/yubico-pam/

    (there is another variant that is designed for laptops/being offline)

    Only issue that the work Apple did to get pam+et al integrated into securityauthorization normally makes building the source they have to keep open near impossible.
  • JeremyLaurenson
    JeremyLaurenson
    Community Member
    I have to also jump n this bandwagon. I would love to use YubiKey with 1Password.
  • JeremyLaurenson
    JeremyLaurenson
    Community Member
    Here you go, folks... no more excuses. :D

    Here is 100% complete code that I have running that implements YubiKey in a simple OSX app.
    It includes validating the generated code with an AES key, checking for replays and even checking that the YubiKey clock is not too far out of sync with the computer clock.
    You may want to add validating the YubiKey ID, I suppose.

    I hereby grant Agile Web solutions to reuse or abuse the code.

    File here: http://drop.io/yubimac

    Others, feel free to download and mess with it. It does require you to reprogram your YubiKey with a new, private AES key.
  • khad
    khad
    1Password Alumni
    edited September 2010

    Yubikey is an excellent complement to a memorized password for multifactor authentication, but in most cases it isn't usable for strictly local validation. The strength of Yubikey is that -- due to its non-local validation -- the database is not vulnerable to a local brute-force attack. The host machine sends a query to a remote database validation server, and simply gets a response as to whether the OTP is valid or not. In order to validate without a remote connection, the database would have to be stored locally. To my mind, this would not be unlike the CSS keysets for decrypting DVD content being stored in the players in all of our living rooms in order to decode video for playback: given enough time and determination, anyone with direct access to secure data can break it.



    Agreed. I wish YubiKey made more sense in more places, but adding 1Password support just wouldn't seem to be that helpful. I was all ready to voice my full support for it, but am rethinking that a bit now. I love Security Now and all that Steve Gibson does for the security community (although he did recommend a competing password manager back in July :P ), but I think even he would agree that it may cause more trouble than it's worth in 1Password.

    Which sucks. Because I wanted to believe...

    The hard part would be supporting iOS devices with YubiKey. We don't just make software for OS X, you know. :)

    (P.S. Welcome to the forums ehunt123 and JeremyLaurenson!)
  • Add my vote as well.
    YubiKey support would be nice,
  • khad
    khad
    1Password Alumni
    Welcome to the forums, dndbs! Thanks for letting us know this would be useful to you as well.
  • khad
    khad
    1Password Alumni
    edited October 2010
    Awesome response, brenty. I can totally get behind this. Multi-factor authentication is already present in the mobile apps by the very fact that they run on "something you have." Cheers!

    Stay tuned for the "something you are." We are working on some 1Password socks that will analyze your feet to authenticate you. They are mighty soft (and fuzzy). :-D
  • khad
    khad
    1Password Alumni
    I do not have a time frame for the authentication socks at this time, but you can find all the latest updates on our blog and even get the freshest socks news delivered right to your inbox by subscribing to our newsletter. :lol:
  • It would be very nice to have some kind of multifactor authentication. Have used the Yubikey with LastPass and they do not use the key for the iOS device. Have also used MyOpenID by JanRain. Here they call me and I have to respond by pressing the # key on my phone. This seems to me to be a very cool idea and easy to use. I agree and completely local authentication would not be possible with either of these systems. Maybe, in combination with a one time password for those times when the Internet is not available?
  • Can I tip my hat towards this request as well? Yubico's Yubikey OTP (One Time Password) would be a great addition to the 1Password ecosystem of apps for Mac and Windows. This is one those features the Virginia team working on the LastPass.com service implemented early on. Very useful indeed.

    It only makes sense to use multifactor authentication when a user is putting all of their eggs (i.e. passwords) in one basket (i.e. software). The basket should be protected with something you know (i.e. a password that is somehow known and entered into the computer) and with something you have (i.e. a one time password system or token like the Yubikey).

    A Yubikey might look like a small- and perhaps typical- USB drive... but it isn't a drive, it is a device with a specific purpose. A Yubikey is somewhat similar to SafeNet's eToken PRO Anywhere USB device in that it provides a mechanism for One Time Passwords using a third party service. Unlike SafeNet's eToken PRO Anywhere, Yubico's Yubikey USB device doesn't need special drivers installed on the Mac or Windows. It works on every computer because the Yubikey is really a fancy keyboard in a small- tiny really- form factor that talks to a server to get a One Time Password.

    When 1Password and Agile's future products support Yubico's Yubikey, the software will not allow a user to see the contents of 1Password's database unless a user types in a mentally memorized password that doesn't automatically change, and presses the button on the Yubikey (while connected to the computer of course) to provide a one time use password that always changes automatically.

    If Agile hasn't done this already, I'd say have someone from the staff get a Yubikey and a LastPass.com Premium account so they can try what an integrated Yubikey password system looks and feels like. Knowing the folks and products in Agile, I'm sure the Yubikey integration Agile will come up with will have an ease, flair, and style that only Agile can conjure up. 1Password is brilliant in its presentation and ease of use. The Yubikey OTP USB device will fit right in.


    khad wrote:

    Multi-factor authentication is already present in the mobile apps by the very fact that they run on "something you have."


    Huh? I'm not sure khad understands the concept of something you have. Either that or he accidentally gave a different impression by wording the sentence like this. I was initially a little concerned to see someone on Agile's Customer Care staff get this wrong since Agile makes the important 1Password software product. Anyone can make mistakes though. No worries.

    Something you have refers to the way a user authenticates (i.e. provides credentials like username, password, and token) to the software or service. It does not have anything to do with where you run that software from. In other words, just because it is possible to run 1Password from a USB drive, it doesn't mean you have multifactor authentication.

    I'm a big fan of 1Password for Mac and Windows by the way. Knox rocks your socks too. Go Agile! You guys blew my socks off Thanksgiving 2010 by letting me freely gift apps I already held dear, used regularly, taught and showed others consistently. I got to send 1Password and Knox gifts to my family. If I wasn't on the opposite coast I'd visit and awkwardly hug Dave Teare or the person(s) responsible. This is how you guys win fanatical customers.
  • Slobodan
    Slobodan
    Community Member
    I add my voice for Yubikey support. It is elegant, open (they offer software for free for developers) and more secure.
  • MartyS
    MartyS
    Community Member
    Thanks for the very kind words, getraf, and welcome to both you and Slobodan for joining our forums! We appreciate knowing that the posters on this thread each see some value in this approach.

    We're keeping an open mind, but just to set the proper expectations: this is not something that's being actively worked on at this time. As Khad said, stay tuned to our normal announcement channels should there be any developments (hehe) in this area.
  • jrmithdobbs
    edited August 2011
    MartyS wrote:

    Thanks for the very kind words, getraf, and welcome to both you and Slobodan for joining our forums! We appreciate knowing that the posters on this thread each see some value in this approach.

    We're keeping an open mind, but just to set the proper expectations: this is not something that's being actively worked on at this time. As Khad said, stay tuned to our normal announcement channels should there be any developments (hehe) in this area.


    The newer versions of the yubikey hardware/firmware (2.2+) now support an HMAC-SHA1 mode that can be queried through normal USB HID apis (though they require an admin account to access and password verification on use, at least on OSX). Basically you spit a 64byte challenge to the the device and it spits back a response using HMAC-SHA1 with the set key which is not retrievable from the device.

    The upside of this is that 1Password could use this same mechanism on both the iOS/Android versions and the OSX/Windows versions, since HMAC-SHA1 is trivial to implement in software. (iOS Framework even provides it already.) Since, as pointed out above, the physical device in the case of a phone/etc *is* the second factor of "something you have" I think this would be a nice improvement.

    It could even be done in a way that each device (yubikey, ipod, android device, etc) had a different HMAC key and 1Password wouldn't ever actually need to know the HMAC keying material.

    For example:

    1. Don't use the actual master password as the source material for your key derivation function.
    2. Use a real random 128/256bit key and don't pass it through a derivation function at all.
    3. Split the key using Shamir's secret sharing algorithm in a way where 2 shares are necessary for recombination and there are as many shares as HMAC-SHA1 sources + 1 for the master password.
    4. Encrypt one share with the master password as source for the key derivation function.
    5. Encrypt each additional share with the response from it's corresponding HMAC source as the source material for the key derivation function.
    6. Store each challenge for each HMAC source encrypted the same way as the master password share so that the master password is required before the challenges can even be found. (This prevents the loss of two devices immediately compromising the system assuming a strong password.)
    7. Every time a given non-password share is used, re-encrypt it using a new challenge.

    This gives you semi-one-time password support and opens up your design to allow fairly trivial addition for an endless number of factors for auth.

    The UI for adding devices could be challenging to get right since each time you add a device you will need to decrypt the real key then split it back out which will require querying all of the HMAC sources at that time; however, the back-end portion is pretty straight forward.
  • Bill Wilson
    edited August 2011
    Please count my voice as one more asking/pleading/begging for Yubikey support.

    I know you don't want to hear this, but I switched from 1Password to Lastpass.com because of its Yubikey support. I'd rather use 1Password, but without Yubikey...

    Look, everyone knows Yubikey is not perfect. But multi factor authentication is important for some of us, including those of us with laptops.

    Don't get distracted by the "we can't use Yubikey on an iOS device." Lastpass doesn't either. But if you added this functionality into the regular OS X and even Windows platforms, you'd make a lot of people happy. You might even get some folks like me back in the fold. ;)
  • Fredvs79
    edited August 2011
    Hi,

    I'd also like to voice interest in Yubikey support. As I understand it, there are two methods to implement yubikey support, one of which is already basically supported by 1Password already:
    1) yubikey in static password mode
    2) yubikey in one time password (OTP) mode


    YubiKey generates a 44 character long password every time, when the button is pressed. The 44 character password contains the following information:

    The first 12 characters represent the ID of the YubiKey. Rest 32 characters represent the password (typically One Time Password).

    YubiKey can be operated in one of the following two modes depending on the user requirement:

    1) One Time Password Mode:

    In the One Time Password (OTP) mode, every time when the user presses the button, YubiKey generates a 44 character long password which contains a static “YubiKey ID” and an event based “One Time Password”.
    For Example:
    Observe the following OTPs generated from a YubiKey configured in “One Time Password Mode”
    fuhkifhkhufbfdccgukghlbuinldkcndkrrluvedbthrhi
    fuhkifhkhufbfdvblbbleffckfhthjdgrgjrbtjbnnlhdl
    fuhkifhkhufbfdhgghncdchnkhrribnukccgurhtlgkfuf
    fuhkifhkhufbfdfcicntcjjdjgchdgifgjebgrenugrfuk
    fuhkifhkhufbfdcrtefbtnnebvtuvhdthbrltvckergedl
    Here the first 12 characters (representing the YubiKey ID) of all the OTP are same. The next 32 characters (representing the One Time Password) are all different and generated based on event based OTP generation scheme of Yubico, thus resulting in a unique 44 character long password every time. This is the default mode of YubiKey.
    2) Static Password Mode:
    In the Static Password mode, every time when user presses the button, YubiKey generates a 44 character long password which contains static “YubiKey ID” and a static Password.
    For Example:
    Observe the following passwords generated from YubiKey configured in “Static Password Mode”
    fuhkifhkhunjfkjeegdcherbljkrdgvhhkllicgcuu
    fuhkifhkhunjfkjeegdcherbljkrdgvhhkllicgcuu
    fuhkifhkhunjfkjeegdcherbljkrdgvhhkllicgcuu
    fuhkifhkhunjfkjeegdcherbljkrdgvhhkllicgcuu
    fuhkifhkhunjfkjeegdcherbljkrdgvhhkllicgcuu
    Here the first 12 characters (representing the YubiKey ID) and the next 32 characters (representing the One Time Password) are randomly generated at the time of programming the key and always same when the button is pressed, thus resulting in a same 44 character strong password every time.

    To validate the OTP generated by YubiKey (in “One Time Password Mode”), the OTP needs to be sent to Yubico Validation Server (or a locally hosted validation server). The Yubico Validation Server validates the OTP and if it is valid, provides “OK” status or else provides a negative status response.

    As the OTP generated by YubiKey (in “Static Password mode”) is always the same, there is no need to validate it against Yubico Validation Server. The password can be used as a conventional but strong password. This password is 44 characters long.

    One method to use the yubikey with 1Password, especially if there is no internet connection available, would be to configure the YubiKey from "One Time Password" mode to "Static Password" mode.

    Yubico provides a personalization tool that can be used to configure YubiKey from “One Time Password” mode to “Static Password Mode”. Use this utility to configure the YubiKey to produce a fixed (randomized at the time of programming) password which you can use with the router. Please note that the Static password can not be defined by user. It is selected by YubiKey randomly, when it is changed from “One Time Password” mode to “Static Password” mode.

    To use YubiKey to authenticate with 1Password, follow the steps below:
    • 1) Configure your YubiKey from “One Time Password” mode to “Static Password” mode as explained above
    • 2) Set your password for 1Password as the static password generated from YubiKey




    This method will save us from having to "type" in the static password to unlock 1Password. This password (44 characters) is probably much stronger than the password you are currently using, and even if your current password is at least 44 characters long, it will save you from having to exercise your fingers so much. The downsides of this method are that
    1) because the static password is randomly generated, it is not likely something you can remember easily, necessitating you to have your yubikey present to unlock 1Password.
    2) should you lose your yubikey, because you cannot remember the unlock password, you are now S.O.L. for remembering your other passwords.

    For those who wish for the additional security of multifactor authentication (something you have) via the YubiKey or the coolness of One Time Passwords, there would need to be an internet connection on your computer that verifies the OTP with the Yubico server.

    One downside to this is that the local computer needs to have internet connection to verify the password. I'm not sure if the communication between this server and your local computer can be spoofed to give a valid response, especially given that a local computer could be a laptop connected to the internet via an unsecure wireless connection. Many of the services that use the OTP feature of the Yubikey are on hosted machines that a hacker has no access to, preventing a man-in-the-middle attack. One way around this is if a local instance of Yubico's authentication server is running on the local machine, also solving the problem of requirement for internet connection. The downside to this is that it is probably not easily implemented by AgileBits and would require a dedicated 'push' to implement, which is not something they are focused on at the moment.

    What would be nice is a compromise. I would like to see 1password be able to be unlocked via a SECOND password.

    The first password that would unlock 1Password would be the current one we are using - something you know.
    The second password that could unlock 1Password would be the static password of the YubiKey. 1Password would check the entered password against BOTH of these answers and if the entered password matches EITHER of these two answers 1Password would unlock for use.

    The upshot to this is that you can verify yourself with something you have (YubiKey), quickly and easily, without fear of keyloggers or the annoyance of typing in your strong (read: long) password. And should you lose that YubiKey or not have it on your person when you wish to use 1Password you can still log in via your regular password.

    This solution would NOT be that difficult to implement, it would simply require adding an additional password to check against.

    Thoughts?
  • khad
    khad
    1Password Alumni
    edited August 2011
    Welcome to the forums, Fredvs79! Thanks for reposting that.

    Having two passwords actually decreases security if one is weaker than the other. If either one works to unlock your data, the security is reduced to the lowest common denominator. If I have two passwords, "a" and "CDFcrBDyFoju2geRxNytnpmoUGBbHKVDty7RKBptZqWiZnEmGT" but both will grant you access to my data, my data is only as secure as the "a" password.

    We continue to evaluate the MFA landscape, but I don't have anything to announce at this time.

    If we can be further assistance, please let us know. :-)

    Cheers,
  • Thanks Khad. You are quite astute to note that part of my post was written elsewhere on a different forum almost 3 years ago, but which everyone here in this discussion has failed to make mention of.

    I would like to point out that you have unfortunately seemingly missed the point of my post. While I agree that when two passwords are capable of unlocking 1Password, I would not compare the randomly generated 44 character password to the letter "a". That is a horrid analogy, and completely outside the reasonable realm of comparison. How many characters is your "strong" password that you enter every time you unlock 1Password? If it is less than the 44 character password that is randomly generated by the yubikey in static mode, then as per your your example case, your "strong" password would probably be more like the example of the letter "a". Therefore you are not weakening security by adding yubikey support.

    If your unlock password is longer than 44 characters, congratulations, I'm sure it isn't TOO much of a burden to type that in EVERY time you wish to unlock 1password, which could be several times an hour depending on how configure 1Password. And have you considered that if you make a mistake typing in your longer-than-44-character-password, you have to type it in again? Plugging in a yubikey would be a lot easier.

    In summation, with two passwords, the security is only as strong as the weaker password. But by adding yubikey support, I don't believe you are weakening security, as the yubikey password is in all likelihood stronger than your regular password.
  • jpgoldberg
    jpgoldberg
    1Password Alumni
    edited August 2011
    Hi everyone,

    There is a lot to say in favor of multi-factor authentication (MFA) and Yubikey specifically. Many of you have done a great job saying this.

    I personally keep going back and forth between wanting us to move toward MFA and wanting to stay clear of it. So I find looking at this discussion very useful.

    As has been mentioned, we would need a solution that works across all platforms, and most importantly does not let the second factor travel through the syncing mechanism. This isn't insurmountable, and internally we've been kicking around some ideas that might do the trick. Though we have to be careful about how backups and such work.

    One thing that we need to keep in mind is that the number of times that people have had their data stolen (through having their computers stolen) is tiny compared to the number of cases where people have forgotten their master passwords. So given the kinds of threats that are actually out there, I can see something like this harming far more users than it would help. If the second factor is lost or damaged somehow, you lose access to hundreds of your passwords. Data Availability is a part of data security that people often overlook.

    Another point against introducing MFA is more generally covered in the section on feature bloat in

    http://blog.agilebit...ce-is-security/

    And there is one more point to consider. 1Password stores your data on your local machine (and, if you sync, on Dropbox). But there are other systems where the data is stored remotely and the same password that is used to unlock your data is also used to log into the system. With such systems, a username and password is all that is needed to get at all of your passwords. With those systems, having a second factor for authentication is more important for security.

    With 1Password, your 1Password encrypted data also needs to be captured. This does, of course, happen sometime when a computer is stolen or if there is a Dropbox breach. So it wouldn't be correct for me to say that your 1Password data file acts as a second factor. It's not protected to the same extent that you would protect a second factor. But without too much of a stretch, I think that we could almost get away with saying that 1Password uses one and a half factor authentication.

    I'm not trying to say that we won't do this. I have been looking at the technical requirements needed, and have been thinking about this a great deal. But I want to be as open as possible about why I am less enthusiastic about two factor authentication than many of the people posting here.

    But your enthusiasm is an important factor (the pun was purely accidental). So please continue with the great discussion and ideas here.

    Cheers,

    -j
  • shaddowman
    shaddowman
    Community Member
    edited November 2011
    Add me to those wanting Yubikey integration. maybe just make it an option for those that want it.
  • John L
    John L
    Community Member
    The biggest reason I need MFA is that I use my password repository (which, for the time being is a major competitor of yours) from my work desktop. I don't want my employer having access to my entire password repository simply because I needed to login to some random website using a password from my password repository. For that matter, I don't want them to have access to *any* of my stored passwords. It's the whole reason I use the autofill/autocomplete functionality.

    Right now, with the use of a Yubikey, my information is protected even if someone has installed a keylogger on my machine. Yes, they'd have access to my local 1Password repository via my local Dropbox copy but at least they wouldn't be able to immediately access any of my stored 1Password information the moment I step away -- assuming I take the Yubikey with me. ;)
  • ContinuIT
    ContinuIT
    Community Member

    Hey Guys,

    I would really love a feature whereby whilst my USB "key" (don't really care what kind) is inserted in my Mac/PC/whatever that 1password could be configured to remain unlocked while it was there (or at least allow me to set an extended unlock period if the key was present). On removal, lock 1Password. This would be SOOOOOOO great and save me having to enter my absolutely massively overly complex 1password password multiple times a day.

    Love your product and recommend it on almost a daily basis - where's my free lunch :)

    Cheers,
    Glenn

  • Megan
    Megan
    1Password Alumni

    Hi Glenn (@ContinuIT)

    Thanks for the kind words and support! I've merged your request with an already existing discussion. It hasn't seen a lot of action lately, but our developers are certainly keeping this idea on their radar. ;)

  • khad
    khad
    1Password Alumni

    Please do keep in mind that as Jeff mentioned above (way back in August 2011) for MFA to work it would need to be required on all platforms. A USB key gets a lot trickier on mobile devices.

  • root
    root
    Community Member

    If like to add my voice to those requesting yubikey support. I love 1password and everyone at AB. I recommend 1P to everyone and everywhere, but recently our company decided on another solution (rhymes with fastpass :p) because it supported physical tokens and that was a requirement.

    I totally understand the issues around 1password and a physical token, especially with mobiles, but having support for it would make the product a better contender.

    Keep up the great work, you all rock!

  • khad
    khad
    1Password Alumni

    Thanks for your kind words and support, @root!

    Multistep authentication has clear and obvious security benefits. So it is more than natural for people to ask why 1Password doesn’t employ it. We're planning to write a more detailed explanation of our developing thoughts on it, but let's discuss the difference between authentication and decryption.

    When you connect to some service, like Dropbox, you or your system has to prove that it really has the rights to log in as you. That process is called “authentication”. It is the process of proving to the Dropbox servers in this case that you are really you. You can do this through a username and password; you can do this through a username, password, and code sent to your phone; you can do this by having a particular “token” stored on your computer. Authentication always involves (at least) two parties talking to each other. One party (the client) is under your control; the other (the server) is under someone else’s control.

    1Password, however, involves the 1Password application (under your control) talking to your 1Password data (under your control) on your local disk (again, under your control). This is not an authentication process. So 1Password doesn’t even do one-step authentication. It does no authentication at all. 1Password doesn’t gain its security through an authentication process. Instead the security is through encryption. Your data on your disk is encrypted. To decrypt it you need your 1Password master password.

    There are great advantages to this design: Your data and your decryption of it doesn’t require our participation in any way once you have 1Password. Your data is yours. Even if AgileBits were to get abducted by aliens tomorrow, you would still have access to your data since we never store it on our servers.

    However, one disadvantage of this design is that the kinds of techniques used for multi-step authentication are entirely inapplicable to 1Password. Those techniques are designed to add requirements to an authentication process, but unlocking your 1Password data is not an authentication process at all. Because there is no 1Password "server", there are no (additional) steps we can insist on as part of a (non-existent) login process.

    1Password is decrypting data stored locally on your system, it is not authenticating against some service. So in truth, we don't even have 1 factor authentication, as there is no authentication in the first place. So typical approaches to MFA won’t work.

    However that doesn't mean that it is impossible for us to do something that looks like MFA. There are roughly two approaches (each simpler than PKI). One of them is key splitting. That is the result of processing your Master Password doesn't actually get you a working key to decrypt further, instead that result would need to be XORed with another 128-bit key. So it is simply a case of storing that other "half" of the key on some other device. 1Password would need to be able to read that device, which may be tricky on iOS, but it isn't insoluble.

    The other approach would be to move the keyfile. 1Password (on the desktop) has a file called encryptionKey.js. That file contains an encrypted key, which is what gets decrypted by the key derived from your master password. That file (and some backups of it) are part of your 1Password.agilekeychian (which is actually a folder bundle, which looks like a single file on the Mac). It would be possible for us to allow that file (and its backups) to reside on some device or location. Both that file and the Master Password are required to get any further.

    We are more inclined to do key splitting rather than having a movable keyfile.

    The real technical difficulty is getting this to work on every platform. Again, because this is all about data decryption and not authentication, we can't just implement this on one platform (if it were to be anything other than just for show). So while this isn't insurmountable it means that even the "simple" approaches that I described would be tricky.

    But the real reasons that we haven't put in substantial effort in that direction is because for every case where someone reports that their computer or device has been stolen, we get probably a hundred more of "I forgot my Master Password" or "I damaged my data and didn't have usable backups". My fear is that key splitting or keyfile moving wouldn't just double the rate of people getting locked out, but would increase it much more. The threat of data lose becomes very substantial.

    Again, because we aren't running a system that people authenticate against, there is nothing we can do the help people recover their data if they damage a key or forget their Master Passwords.

    Now of course we could make it an advanced option with lots of warnings, but we know that people will always dial up security settings to 11 whether it is in their interest or not. Remember that 1Password is a mass market product. It's great that security geeks use and respect it, but we don't want to give our users rope to hang themselves with.

    I'm just spelling out why, to date, we have resisted calls for MFA. It's harder to get right for a decryption system than for an authentication system, and we think that it might do more harm than good.

    None of this is written in stone. The threat landscape, patterns of usage, and device capabilities change. So while there are no immediate plans add this, we are leaving the door open in the design of our new data format.

  • poof
    poof
    Community Member

    You are using the wrong terminology. Authentication is about verifying that you are who say you are. Authorisation is about being granted access to data you are allowed to access. While 1Password doesn't do authentication, it does do authorisation. It grants you access to your datastore via a password. Since the datastore is also encrypted it does another thing: decrypt it so you can read and write. For this discussion the decryption part is irrelevant.

    The problem with 1Password is that there is only 1 layer of security: a password. Those can be weak. People here want to use something like a YubiKey or whatever to add an additional layer of security. The password for the datastore alone isn't enough, it requires the correct response to some kind of challenge code. There are quite some reasons to do it this way (device gets stolen, somebody is using your account to do some work, pull up a website; setting a different password for 1Password than for your user account for the computer helps in the latter but it doesn't take away the concerns in the former scenario).

    The real question is: how can 1Password be made more secure by adding some an additional security layer without breaking usability too much? And the answer to that could simply be "we are not going to because it is not our intent to be a full fledged max security product, we only want to make it easier to manage your passwords for the forums you visit". You could also be a lot more vocal about people setting up strong passwords (you guys did that via your blog in the past but it is too techy for the masses). Until then, 1Password isn't a professional/high end security product and should not be treated as such (you may have to ask yourself the question if you should use it to store things like bank and creditcard accounts).

  • benfdc
    benfdc
    Community Member
    edited December 2013

    From @Khad in #41:

    We are working on some 1Password socks that will analyze your feet to authenticate you. They are mighty soft (and fuzzy).

    It's been over three years since that post, but all I see in the Agile Goods Store are t-shirts. With hardware support for bluetooth 4.0 now pretty much ubiquitous, the lack of a USB port on iOS devices is no longer a concern. What’s the hold-up here?

    Also, why are the men’s tees only available in S, XL, and XXL?

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    I would quibble with @poof over the appropriateness of "authorization" to describer what 1Password does, but the labels don't matter that much, it's the overall concept.

    To get what looks like 2FA with 1Password is a very different thing than how it is usually done. And this is exactly because there isn't an authentication process. It is sometimes (though not always) a mistake to think that an extra layer adds meaningful security. For example, double encryption does far far less than simply improving ones password by a single character. That is one 42 bit password is stronger than layering two 40 bit passwords. I'm not saying that adding an additional layer though key splitting wouldn't be adding meaningful security, but unless it is done right, it may be more security theater than actual security.

    @benfdc is correct that the ability to get data via sneakernet to iOS and Android devices is easier than ever. So this changes the situation from "not practical" to "not implausible". The fact of the matter is that we don't know in detail what difficulties we face until we try. And on that, the "hold up" is priorities.

    I started playing with a YubiKey some month back, just to get an idea of the protocol. But once it became clear that there wasn't any scenario in which key splitting could make it into the initial releases of 1Password 4, it fell back into the "well we might explore this further down the road."

    The biggest case for key splitting is that in 1Password, as in any well designed crypto system, the weakest point is people's Master Password. And so building up defenses there is what makes the most sense, and key splitting is one approach. But we need to make it reliable and easy enough so that it will work for the people who need it most. If it takes some expertise to set it up and manage it, then it will be used correctly only by those people who already know to use a strong Master Password.

    Anyway, as you see, I am arguing both sides here. And let me add, that from a cryptographic point of view, key splitting is very attractive. The cryptography is simple, elegant, and powerful. It's the key management that gets messy.

    Merry Boxing Day!

    -j

    –-
    Jeffrey Goldberg
    Chief Defender Against the Dark Arts @ AgileBits
    http://agilebits.com

  • benfdc
    benfdc
    Community Member
    edited December 2013

    But we need to make it reliable and easy enough so that it will work for the people who need it most. If it takes some expertise to set it up and manage it, then it will be used correctly only by those people who already know to use a strong Master Password.

    That’s a very powerful point IMO.

    @Poof wrote:

    The real question is: how can 1Password be made more secure by adding some an additional security layer without breaking usability too much? And the answer to that could simply be "we are not going to because it is not our intent to be a full fledged max security product, we only want to make it easier to manage your passwords for the forums you visit".

    I don't agree with that framing of the issue. I see the real question as being whether adding YubiKey support would increase or decrease security across the user base. I find it very plausible that YubiKey support would decrease security for the majority of 1Password users by greatly increasing the risk of losing access to one’s data. A YubiKey is like a handgun in that respect. In well-trained hands, it affords enhanced protection. In less than well-trained hands, well, maybe you’d be safer without it.

    One approach to reconciling these competing concerns might be to make two-factor authentication available as an in-app purchase for a more-than-nominal sum. Lots of ramifications, but part of the point would be to dissuade casual users from activating the feature.

    I wonder how much real-world data is out there addressing this point. Have vendors like LastPass published any reports on how 2FA is working out for their user base? It would be very interesting to know what percentage of YubiKey users have gotten themselves into trouble.

  • poof
    poof
    Community Member

    Thanks jpgoldberg for your answer. We mustn't think that adding an additional layer of security will actually make things safer, it is something that you need to look into. As for the 2FA people here seem to want: Dutch banks use it for example. You have this challenge code you get before each payment. The payment only passes when you enter the correct challenge code. This system has been researched and proven to be the safest there is at the moment (you need to have the username, password, bank card and the challenge code generator). Funny thing is, 1Password uses this in version 3 for iOS (you use a pin code to enter the app but you need to enter the master password when opening the high security entries). The reason why people want it is probably because they know passwords suck in general.

    So to compare it with the handgun: if you are going to hand out handguns give people training so they can properly use them and put a safety pin in place so they don't accidentally go off.

    The major thing I wanted to point out if it is even necessary to have something like this. 1Password isn't an application for military secrets. Most people use it for storing all their login data for forums and such. How much security does one need for storing such information? Personally I think that having just a password is enough for that (especially if you use a different password than for your user account on the computer). Use the appropriate security measure for your data.

This discussion has been closed.