Multifactor Authentication
Comments
-
So, when do we get multifactor authentication?
Multifactor authentication isn't about encryption or key-splitting. Well, I guess you could call it key-splitting, that's actually reasonable. But encryption isn't a necessary factor in the conversation of multifactor authentication.
First, some terms.
Entities are broken down in to subjects and objects. 1Password is an object, a user is a subject; a password is an object too.
Authentication is not identification. 1Password doesn't perform identification - anyone with access to the application, the data and the password can access a 1Password DB. So, identification is assumed in 1Password.
Authentication is the process of determining what objects the subject can access and their associated rights and permissions when interacting with those objects. In 1Password, a subject has authority to read, write, modify, add and delete data in the 1Password DB.
Multifactor authentication is broken down in to 3 types: what you know, what you have, and what you are - three domains that are completely separate. 1Password uses one-factor authentication: what the subject knows. Adding a second password isn't multifactor authentication, btw.
Therefore, multifactor authentication for 1Password would mean that I would need to know something (that's axiomatic) and that I either "be" something or "have" something. Since "being" something is pretty much out of the question (unless you're also going to provide biometric devices), then "having" something is what we need.
What could that "having something" actually be? It could be an image on a USB stick, a document of GIF Google Drive or a text file on a networked file server. It could be a read-only USB device with a specific name and a set of user-defined files. What it is doesn't matter which is why encryption or key-splitting isn't a necessary element of the conversation. Multifactor simply means that the subject has two or more domain-distiinct objects that are used in the process of identification and authentication. Therefore if someone stole my password, then they don't have a chance of accessing my 1Password data without the thing I "have." Conversely, if they still the thing I have, then they still need my password.
Implementing it shouldn't be too difficult. All one needs a reasonably secure hash algorithm, and dialog to point 1Password to the correct data and/or device. Assuming 1Password self-authenticates (aka, it's self-signed to prevent tampering) then someone can hack my computer all day and never get to the password data without both the master password and the thing they must have.
http://en.wikipedia.org/wiki/Multi-factor_authentication
http://research.microsoft.com/en-us/um/people/venkie/jakubowski09tts.pdf
0 -
I might quibble about your definitions, @DMeans, but stepping back from that argument, the question is
"When are we getting multi-factor whatever" for unlocking 1Password?"
But to understand why both this
- Isn't as important for 1Password as it is for other systems
- Why it is difficult to deliver within something like 1Password
both depend on the distinction I've been making between authentication and encryption. And so I must actually quibble with your redefinitions of the terms. I wish I didn't have to.
In which I get pedantic
You are right when you say that at one level of abstraction the distinction between authentication passwords and encryption passwords don't matter. You know a password and you can then see and manipulate your decrypted data.
The pedantry which I must introduce is that when you refer a definition of authentication
Authentication is the process of determining what objects the subject can access and their associated rights and permissions when interacting with those objects. In 1Password, a subject has authority to read, write, modify, add and delete data in the 1Password DB.
the meanings of "access" and "authority" are narrower than you take them. You see, even without your Master Password (but with access to Dropbox or your computer disk) you already have full access to your 1Password data. It's there on your disk. You can look at it, you can change it, you delete it. All of that is because you have access to your 1Password data file.
You go through an authentication process with Dropbox or your own login to your computer to gain that access. Having physical access to your computer may be part of how you (and not many others) have that access.
1Password does not control your (or anyone's) access to that data. To make that data useful, it needs to be decrypted. And that is where 1Password plays a role.
So what about multi-factor something?
Again you are correct that implementing key splitting in 1Password (on a single platform) would not be hard.
Implementing it shouldn't be too difficult. All one needs a reasonably secure hash algorithm, and dialog to point 1Password to the correct data and/or device.
Actually no hashing is needed if the define simply contains 512 bits of key that we just XOR with key derived from your Master Password. Key splitting is extremely easy from a cryptographic point of view. It is also "perfect" in a technical sense of the word. So if the cryptography and the security of it is so easily awesome, where's the rub?
Key splitting will be all or nothing for your 1Password data. The second factor will have to be available on every computer and device on which you use 1Password. If you just use 1Password on desktops, that is easy. But if you synchronize your data to mobile devices we need a "thing that you have" to work on the desktop as well as on your mobile device.
Here, there and everywhere
1Password will need that second factor to decrypt your data every place you wish to decrypt it. So you need to be able to get that second factor everywhere. The one place that the second factor should never be is on a sync service. Otherwise we lose the whole security point of it.
This everywhere (except never anywhere that someone else could get at it) or nowhere choice with no middle ground is a consequence of the fact that 1Password is encryption based instead of authentication based. Again, you may disagree with the terminology, but whatever words we use, the fact remains that if you need the second factor to decrypt your data on your iPad you will also need it to decrypt your 1Password data on your PC.
We could store it on some devices
We could store the second factor on some devices and demand that you supply it on others. So for example, the second key could get stored both on "something you have" and also in, say, the iOS keychain. That way, you wouldn't have to plug in your "something you have" into 1Password each and every time you want to unlock on your phone.
But you still would need to get it there for set up. That is, once the second factor key is created and kept on "something you have" it would need to get installed on those devices where you are willing to have it stored. So every time you create and sync a new vault, you would need to set this up.
This is certainly something that can be done, but it then becomes something that gets tricky to implement in a way that doesn't put an a large burden on the user.
So as we explore ways of doing this, we are investigating approaches that are easy and don't take complicated instructions for people to get right. Impossible? No. Indeed it is exactly the kind of challenge we enjoy.
0 -
Firstly - I appreciate all of your feedback. I believe that this is productive. I also foresee this thread diverging into something that seems more of a flame war than a composite thought towards a solution. That is the opposite of the intent of my original post. Feel free to correct me if I am out of line.
The fact is, as soon as a vulnerability is found on whatever platform - there is a good chance that someone is going to follow the stager with a Meterpreter payload which has built in key logging capabilities (and this is JUST speaking of Metasploit. There are other tools such as CANVAS by Immunity that may pick apart this type of vulnerability sooner.).
The real vision, for me, is "How can we implement another layer of security in 1Password?". I realize that there has been a huge mix mash of nomenclature throughout this thread and that the language barrier has obviously skewed some of what we're trying to get at.
I have no doubt that the 1Password encryption is good. The bottom line is - the master password must be typed. Passwords are inherently terrible. They are difficult for users to remember and as such users more often than not will synchronize their password across domains, if not all websites/programs/etc.
The original intent of my post was to create a collaborative effort where we can, as a composite and intelligent mind add an additional layer of security. I honestly do not care what that is so long as it makes sense and serves the purpose which is... security.
1Password is an excellent program. "Passwords" in themselves are inherently dangerous and vulnerable to so many attacks. How can we add another tier that further enhances the security of this program? I would not have started this thread unless I believed in the potential of the 1Password pioneers and developers.
0 -
So is my understanding correct in thinking that on a desktop (windows) I can simply copy the encryptionKey.js file and throw it on a secure USB then delete it from the desktop after each use? And by doing so it would prevent anyone from accessing my data without BOTH my PC AND USB OR my phone.
0 -
alm46: Are you stating that as a fact 1Password uses JavaScript for encryption?
0 -
@aim46, yes but it isn't that simple. Because we are so worried about the data in the encryptionKeys.js getting lost or damaged, you should also look at 1password.keys and .1password.keys. Also the encryptionKeys.js file will be included in the backups that 1Password makes. We really don't want people to lose or damage those files.
We do not "support" the kind of trick you are looking at, but were you on OS X, I would point out that Unix symbolic links might be a useful tool. I will not give actual instructions because this is not supported, and if you aren't already comfortable playing with Unix symbolic links then you shouldn't be using them.
@michaelbehan. 1Password does not use JavaScript for encryption (with the exception of 1PasswordAnywhere), but it does use JSON to structure its data files. In versions prior to 1Password 4, the 1Password browser extension does do some encryption in JavaScript, but we have been able almost all of that out of the browser extensions in 1Password 4.
0 -
I have no doubt that the 1Password encryption is good. The bottom line is - the master password must be typed. Passwords are inherently terrible. They are difficult for users to remember and as such users more often than not will synchronize their password across domains, if not all websites/programs/etc.
Your whole argument seems to be based on this point, but isn't this the whole point of software like 1Password? You have a single password to remember so even using fully randomised passwords it shouldn't be impossible for users to memorise. Factor in schemes like diceware are it becomes very practical.
We could store the second factor on some devices and demand that you supply it on others. So for example, the second key could get stored both on "something you have" and also in, say, the iOS keychain. That way, you wouldn't have to plug in your "something you have" into 1Password each and every time you want to unlock on your phone.
Surely if you store the second factor on the same device that holds the keychain then it will be vulnerable to same system breaches that would allow a keylogger to be installed, which short of an insecure master password, is the only serious threat to a master password's confidentiality. So what would be the point?
0 -
You are correct @RichardPayne, that storing the second key on the same device (such as your phone) as you store your 1Password data defeats much of the purpose of having a second factor.
But while I don't wish to speak for @DMeans, I expect that a number of people are more concerned about their data being stolen from Dropbox than from their own devices. Or to put it into 2FA terms, their phone is the "something they have".
Imagine an attacker who has read access to Dropbox and who has very high powered password cracking technology and resources. But the attacker does not have access to your phone or to the USB "thing that you have". Storing the second key on the phone would thwart such an attacker.
0 -
@jpgoldberg the way I was looking at it was, who is likely to have high powered password cracking technology? I would guess at the same people with the means and motive to gain access to you physical device.
0 -
@jpgoldberg so instead of cutting out the js file just do the same thing but with the 2 .keys files you mentioned above? Would these be likely to get damaged from multiple moves to and from USB?
0 -
For multi-factor authentication, I should be able to use an image - a GIF of my car - as the second factor. I could keep this image on my phone, my systems or on a USB device. I'm not sure how that gets involved with key-splitting, unless one uses the GIF in key-generation? I'm not a cryptologist, so I'd have to defer to your expertise.
However, a key distinction is that accessing or validating the second factor is not an automatic operation - programmatically, that is. In 'real-life,' I must physically give you something that I have. The same is true as translated into the virtual space - I must provide the object during authentication. As a developer, you might determine via a design effort that the user would like the option to save a pointer to the second-factor object, and that's perfectly valid. But to simply split the key, save that half off somewhere in cyberspace and programmatically access it during authentication, doesn't seem to adhere to the spirit of multifactor authentication at all - and somewhat seems to defeat the purpose, IMO.
To answer a point you alluded to earlier: one of the reasons users want multifactor authentication is so that someone who gains access to the database cannot use 1Password to access it without both factors: the password and the "something you have."
0 -
@RichardPayne Depending on the form of encryption, modern day computers can do thousands to millions of attempts per second on their CPU and about 100 times that on their GPU (perhaps even into the billions). If one wants even more horsepower it is extremely cheap to rent out multiple GPUs on the Amazon Cloud and attack/crack with those.
So, to put it more succinctly - potentially everyone has cheap access to that kind of power.
0 -
I substantially concur with @DMeans here:
As a developer, you might determine via a design effort that the user would like the option to save a pointer to the second-factor object, and that's perfectly valid. But to simply split the key, save that half off somewhere in cyberspace and programmatically access it during authentication, doesn't seem to adhere to the spirit of multifactor authentication at all - and somewhat seems to defeat the purpose, IMO.
And so that leaves us in a situation where we need to get that second factor to be something that an individual can supply to 1Password every time they unlock 1Password on any system on which they use it.
For people who use 1Password exclusively on desktop computers, this would definitely workable. But as soon as we are using 1Password on a broader range of devices, this gets more difficult. And so this is where I don't fully agree. I could imagine someone very reasonable choosing to store the second factor on a USB device that they need to unlock and supply on a desktop, but actually store it on their iPhone. This way an attacker who captures the data from Dropbox or from their desktops will still need to get both factors (the Master Password and the second key). The attacker who captures the data on the phone, however, will only need to get the Master Password.
@DMeans, would you really want to prove your second factor every time you unlocked 1Password on your phone? Do you see other people wanting to do that?
@michaelbehan is correct that supped up machines can guess a lot of passwords quickly. For the data in our latest data format, we have been able to keep that down to just a few tens of thousand password guesses per second.
0 -
@jpgoldberg - Good question. Maybe yes, maybe no. But that's an empathy case to be ascertained through the design effort - it's when we ask the question: what kind of users do I have, what do they want, how do they want to use the product, how do I best empathize with them?
Off the top of my head, (hypothetically speaking) there are probably at least the following use cases in this space: 1) I want multifactor every time; 2) I want multifactor only on the devices of my choice (not on a phone, but on a computer) 3) I want X device to know where the second factor is and automatically use it every time (defeats the purpose for X device, but not for other devices) and possibly even: 4) I want multifactor only on N records, but not all records.
So, if it were me, I'd probably choose #3 first and apply an additional control that allows the user to enable multifactor or not. That seems to cover best the hypothetical use cases.
0 -
Thanks for that @DMeans!
Your number (2) is not possible with an encryption-based system, but (3) is. This is why the difference between "authentication" and "encryption" matters.
You are also correct that it is difficult to speculate about what people want and will do. We won't really know until we try (and even then we won't know because we have no information about how people use 1Password except for those who write in to tell us or post here on the forums.)
0 -
SurveyMonkey :D
0 -
I agree with Khad's commends on "Authentication" vs "Decryption", a lot of people get confused and forgot the fact "there is no server".
However, Khad, no matter what you say, or how many times you address this issue. We need to realized that people need to have a SAFE feeling about giving all of our top secrets to 1password's "master password", and hoping this will safeguard the secrets. If you want the 1password to be sold to more people, i think the bottom line is to make people feel comfortable and confidence about this only "master password".As a foreign customer, the reason i don't feel safe, there are two:
Will any one stole 1password.agilekeychain file.
"1password.agilekeychain" is just a file, if anyone got hold of this file, it is just matter of time using the correct tool to decrypt it, it might take long time to do so. So i would always wonder wether if anyone has stole this file.
What i do to make myself safer, is that I put this file inside of anther knox file and syc it to dropbox, so i need two factors+SMS to login dropbox, and i need to open knox folder first, then open the 1password. I don't know if anyone have done this, or if this make any sense.Will any one SEE the master password.
I am afraid that some one( or admin) at the same office network will force install some kind of key logger on my computer, if they did this, no matter how difficult to decrypt the master password, it will be every easy to just to SEE what the master password is.
I think the design of this software, it should input master password first, then use some kind of 2nd level verification process. Such verification best NOT to be inputed using keyboard, otherwise the the key logger would SEEs it. I would guess we could picking one or two cards/Photo (which i preselected at installation) out of many other Cards/Photo.
I have a Xbox one at home, it detects face... i think this is something you guys can think about in the future, and using this as a 2nd level verification.
Besides the above two reasons i explained. There are also two suggestions on the product enhancement, most people focus on make the file/system harder to decrypt, this is just preventative measures. What about remedial measures?
A. If someone put a gun on my head and ask me my master password for the 1password. At that time, i would wish that i have a decoy or 2nd password, once I logged in with that password, all i see is some non-important password information.
B. If anyone is keep trying to open my 1password software, I would wish 1password would put a time based freeze(like an iphone). Or i would i would get an email notification. If i am already suspect my network Admin stole my 1password.agilekeychain file, and is try to access it using 1password, i would wish that i can get some kind of head up, so i have some time to go change all of my logins or account number.
Well, i am not a computer expert, these are just views based on a foreign customer, hope these make sense. Good luck America
0 -
Hi @shawn33! You raised a lot of issues, so please forgive me for not addressing all of them here.
One of the trickiest issues is what you say with
We need to realized that people need to have a SAFE feeling about giving
all of our top secrets to 1password's "master password", and hoping this
will safeguard the secrets. If you want the 1password to be sold to more
people, i think the bottom line is to make people feel comfortable and
confidence about this only "master password".It would be possible to put in some measure that don't actually increase security but have the effect of making people feel more secure. That practice is known pejoratively in the bussiness as "security theater". It is generally considered a bad thing.
Security Theater isn't always wrong
But like you, I think that there are cases where security theater is perfectly
legitimate. Our app icons are designed to convey an impression of solidity and
security. Yet the app icons don't actually contribute to 1Password's security
(Nobody tell Dan that I said this). But, of course, if it leads people to use
1Password who otherwise wouldn't then it actually does contribute positively
to people's security.I actually made this point about 128 versus 256 bit encryption keys in "Guess why we’re moving to 256-bit AES keys":
If Molly feels that 128-bit keys aren't sufficiently secure, she may incorrectly reject systems that use 128-bit keys instead of 256-bit keys. In doing so, she may make choices that actually weaken her security overall. I might not agree with her reasoning, but we do have to recognize that her feelings do matter to her choices. And I certainly want to keep Molly secure. So if by offering 256-bit keys we enable Molly to make better security choices (even if for the wrong reasons), that is a good thing.
As long as there is no reason not to use 256-bit AES keys, it makes sense to use them. We have now reached the point where there is no harm in using 256-bit keys, and so the reassurance that comes with using them is worthwhile.
First, do no harm.
So then why am I being such a fuddy-duddy about "security theater" in the case of presenting the appearance of multifactor authentication while I'm willing to defend it in case of 256 versus 128 bit keys? The answer is simple. I am concerned that if we were to add something that looked like 2FA but didn't actually improve security it would lead people to choose weaker Master Passwords. The presence of such an option could easily lead to people making themselves less secure.
When intuitions fail
There is something that is very counter-intuitive about passwords that can lead people to weaken their security by following their intuitions. Something protected by two separate 10 letter passwords is weaker than something protected by one 11 letter password.
That is, if you use multiple passwords, say for different layers of security, you are only increasing the security of your top layer slightly. But if you were to use a slightly longer password that covered everythhing, you would have far more security.
Let's suppose that (on some particular hardware and for some particular hashing scheme) it takes an attacker one month to crack a random 10 letter password. How long will it take for an attacker to crack two of them? It would take twice as long as the time to crack one. So it would be two months.
Now suppose we were to have an 11 letter random password. The 11th character would one of 52 possible upper and lowercase letters. So if cracking a 10 character password would take one month, then cracking an 11 character one would take 52 months (four years and 4 months).
What seems like the more secure thing (two separate passwords) is actually 26 times weaker than merely increasing the password by one letter.
Countering intuitions
We are very aware of what makes people feel safe. And we certainly want people to feel safe (as well as actually be safe, of course) using 1Password. But when there are situations where helping people "feel safe" would actually encourage them to be less safe in actuality, we have to say, "no."
I know that this can sound arrogant. We are denying popular options because we think we think we know better than our customers about how to treat their password security. I don't want to be saying, "Trust us. We're professionals." This is one reason why we do our best to explain our design choices.
Getting multiple factors right
I'm not at all ruling out something that looks like multiple factor authentication. But if we do introduce something, it will be something that genuinely increases your security and not something that decreases it.
0 -
Just to be clear: I am completely against "false senses of security". I have been (attempting) to suggest a second form of security. Not only for the ease-of-mind factor for the end-user. More importantly for the integrity of the data being secured.
0 -
I do understand that, @michaelbehan. I was just addressing a single point made by @shawn33. Key splitting, would be something that would add real security to data captured from the cloud, as it would defeat password cracking attempts. I didn't mean to suggest otherwise.
0 -
@jpgoldberg thanks for your reply.
"I am concerned that if we were to add something that looked like 2FA but didn't actually improve security it would lead people to choose weaker Master Passwords. The presence of such an option could easily lead to people making themselves less secure."
I never thought about this fact, but you are absolutely right: some factors will make people choose a weaker Master Passwords.
However, i think everyone focus too much on "having a strong Password which is harder to decrypt". I think 1password is already good enough for this matter, given the user didn't choose a password which is too short.
Please, everyone, don't stuck on the subject of decryption. 1password is already one of the best on this matter. What makes a good 1password, i think there are 4 factors:
- Harder to Decrypt the password.. (already good enough)
- Harder to find and steal the 1password.agilekeychain
- Remedial measures on and detection of abnormal access or access attempt
*4. Harder for Key Loggers to "SEE" the password (wether the is is strong or weak)
I think the last issue is the most important, again this is not a decryption issue, but in real life, (it is very common in China) this might be more likely to happened to regular users.
@jpgoldberg, i would really appreciate if you can address this #4 issue. I am very interested in hear your views, and wether this is something 1password will consider in the future devolopment!
0 -
I'd like to add my voice to those who are asking for the option of adding multifactor authentication to 1 Password. Some users may choose to not use it, while others will determine that the added security versus ease-of-use is worth it. Put the decision in the hands of users.
0 -
This was a great discussion and I would like to thank agilebits team for their elaborate answers.
I've been using 1password myself for few months and gifted it to my parents recently, so I can understand both arguments. I personally would like 1password to implement something similar to TrueCrypt keyfile. I understand the risks, the hassles, and the potential decrease in lockout threshold and I accept that. on the other hand, I would never want this feature for my parents due to the exact reasons @jpgoldbergjpgoldberg stated. It needs to be an option to opt-in with a fair warning about risks and security implications.
I'd like also to hear the teams opinions about using 1password on public places where there is a risk of someone seeing your master password or even planting a key logger.
0 -
Thanks all for your comments. @Sky11 and @sjtaffee are of course right for agreeing with me ;-) If this is introduced it must be an option.
I'm not trying to shoot the idea down, but if in a security product you offer an option for "even more security" people will take it. When I think about this, I'd kind of like to have a quiz that they would have to take before the option could be enabled. You have a pass an exam demonstrating full understanding of the consequences before we would allow it. Sure, that is probably even more obnoxious that even I am willing to be, but I can't deny that I sometimes imagine such a thing.
I'd like to talk about the specific points that @shawn33 raised and defer others.
Please, everyone, don't stuck on the subject of decryption. 1password is already one of the best on this matter.
To be pedantic – and in technical security discussions it is often useful to be pedantic – we are talking about "cracking" the Master Password, not "decrypting it". There is no encrypted Master Password to decrypt.
So with the first two points:
- Harder to Decrypt the password.. (already good enough)
- Harder to find and steal the 1password.agilekeychain
While your number 2 is important for the a number of reasons, and provides a good layer of defense against someone decrypting all your data (they can't decrypt it if they don't have access to the encrypted data), it is a fundamentally less reliable approach. One thing is that the data can be stolen from anywhere, including from your own computer. Foreshadowing a bit, we are not aiming to provide a complete security system for your computer. You have to keep bad guys off of it.
With 1Password data living on four different operating systems (and various versions of those), we simply have to assume that there will be times when it is captured by attackers. So that is why our focus on on number 1. Sure, 2 is important, but the real choke point in 1; and so that is the focus or our defenses.
Lockouts, etc
3 Remedial measures on and detection of abnormal access or access attempt
You are still thinking in terms of an authentication model instead of an encryption one. If someone steals a copy of your 1Password.agilekeychain, they will attempt to crack it on their own machine using their own tools (and not using 1Password itself). The attacker will be working with a copy of data, and they now have full control of that copy. There is no way we can detect what they do with it.
As for detecting the initial access in the first place, consider these:
Alice uses 1Password well and securely. Alice gets some malware which
quietly makes a copy of her 1Password.agilekeychain data and sends that
off to the attacker.1Password in never invoked. There is no opportunity for 1Password to
detect or prevent accessAlice uses 1Password well and securely. Bob gets physical access to
Alice's computer and she is not using Full Disk Encryption (FileVault,
BitLocker, etc). Bob removes hard disk from Alice's computer, makes a copy
of it, and returns it.1Password in never invoked. There is no opportunity for 1Password to
detect or prevent access.Alice uses 1Password well and securely. She syncs her data with
Dropbox.Dropbox receives a "request" from a government agency for the
data. That government agency now has a copy of Alice's
1Password.agilekeychain data which it can analyze at its leisure.1Password in never invoked. There is no opportunity for 1Password to
detect or prevent access.
In each case, the data has been captured by the attacker without going through
1Password at all. 1Password never has the opportunity to prevent access to
that data. All 1Password can do is ensure that the data is well encrypted and
that the Master Password is hard to guess.In these particular cases, key-splitting would prevent decryption of the data
(your original point 1), but it would never prevent access to the data. So I
hope that you are seeing why we put our focus where we do.The person who picks up your unlocked iPhone and takes a couple of guesses at
your Master Password through 1Password itself is not a serious attacker.
Anything other than a terrible Master Password is going to be good enough to
defend agains that and no more is needed. The serious threat is from someone
who obtains that datay (through any number of means, most of which are fully
outside the control of what we do.1).Keyloggers and MFA
4 Harder for Key Loggers to "SEE" the password
In a traditional MFA system, with a real authentication structure, One Time Passwords (OTPs) offer some real defense of the system if the regular password is captured. And so, in the traditional case, MFA offers some protection against keyloggers. So you can be a bit less unsafe when using a potentially hostile computer.
But because 1Password decrypts data stored on your local computer (though it may be synched over net) this scenario doesn't come up. You need to install and run 1Password on your own machine and everything happens locally.
So unless you actually go and install 1Password on a hostile computer, you just aren't running the same sorts of risks. And because you would have to provide your second factor locally to that computer, then it would be subject to the same kinds of attacks that the Master Password would be. So a second factor isn't really doing you much good.
On a compromised machine, the attacker doesn't need to try to get your Master
Password or any other "pre-master" information. The attacker let you jump
through all of the decryption hoops and just attack your locally decrypted
keys.1Password offers a number of hurdles against the attacker who has some control of the machine that you are using. It prevents naive keyloggers from getting things, and it reduces in-memory exposure of secrets. But these defend against the most basic (though common) attacks. But if someone has control over the machine you are using, then in principle they have control over everything it does and knows.
Multi-factor is just going to be a minor annoyance to the serious attacker with full control of your computer, and casual attacker will be defeated by our other measures.
Quite simply:
Keep your systems up-to-date 2
On Windows 8 enable Windows Defender (on by default I think)
On Windows 7 enable Microsoft Security Essentials
On Mac enable, Gatekeeper
On iOS: Don't jailbreak.
Use discretion in what you install.
So sure, 1Password does some stuff to protect against keyloggers, but there are limits to what it can do on a hostile computer.
-
It would we tempting to require that all desktop users of 1Password use
an encrypted file system, but there are some legitimate cases not to
(including the fact that BitLocker isn't available on Windows 7/8 Home
editions. We would love to insist that all users of 1Password on iOS
also use device passcode, but again this is outside our power and would
be overstepping our authority anyway. ↩︎ -
Keeping systems is by far the single easiest and most effective way to
prevent malware on your machine. I know that this isn't as easy for some
Android systems as for the others, but everyone should make sure that
they have things set up so that software updates happens regularly and
quickly. ↩︎
0 -
@jpgoldberg Thank you for your detailed explanation, i have to say that I was not totally agree with you at first. But i learned a lot from your explanations. I think you really got me to rethink a lot of things, and so:
- I changed my 1Password's master password and OSX login password to a very long password... God hope i won't forget about this one day.
- I removed my 1Password.agilekeychain from dropbox... So no agency will "request" it ; )
- I am still thinking wether it make sense to put 1Password.agilekeychain into Knox, so every time 1Password need to access the 1Password.agilekeychain, i will have to open Knox first in order for 1Password to work.
As speaking, i start to think, maybe i should not put the most important login info into 1password, maybe i should use it for secondaries logins. Not that i don't like about 1password, but "never put all the eggs into one basket" ; )
One last comment, the safest place is the human brain. I decided to use an unique passwords for each import login, and memorized the passwords. There are many ways to create unique passwords without forgetting it, which i won't share here any more... hahahah
0 -
One last comment, the safest place is the human brain.
I completely disagree with this. The human brain is fallible and unreliable.
0 -
@Sky11 I must now disagree with 1Password implementing anything from TrueCrypt. :_(
http://truecrypt.sourceforge.net
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
>
This page exists only to help migrate existing data encrypted by TrueCrypt.
>
The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP. Windows 8/7/Vista and later offer integrated >support for encrypted disks and virtual disk images. Such integrated support is also available on other platforms (click here for more information). You >should migrate any data encrypted by TrueCrypt to encrypted disks or virtual disk images supported on your platform.
0 -
@shawn33, you are still thinking of decryption as "logging in". I know that it looks the same, but you may be creating more trouble for yourself then you really need.
There are cases where multiple encryption helps. There are also cases where multiple encryption only adds one bit of strength but creates enormous complexity and increasing the chances of losing data.
I'm not going to tell you that there aren't any reasons to keep your 1Password data off of Dropbox or to keep in an encrypted volume, but you may find that you are going to a lot of trouble for what is, in fact, a tiny security gain.
However, I have noticed (and I'm guilty of this myself) there are "operational rituals" that can make us feel more secure. That is, if we make some of the security measures we take hard (or at least noticeable) then we feel more in control of what we have. That is a good feeling on its own, and for some people that may well be sufficient reason.
0 -
@sky11 and @michaelbehan. Perhaps we should start another discussion about TrueCrypt. I've got my (rather mundane) speculation, but I have no actual information beyond what is already widely known.
0 -
@jpgoldberg I'd love to pick your brain about that as I've heard some pretty odd reasoning! As an aside - I am getting warnings about this site's certificate now. (fyi)
0
