Why don't you just "LOCK" the individual passwords instead of the whole App?

Options
AgileBurger
AgileBurger
Community Member
edited December 2014 in Mac

Im not grasping the logic of having a software application that has to be locked at all, otherwise all your passwords are easily exposed. I realized they're "fake locked" but all one has to do is click on them to reveal them.

If someone finds my lock passphrase, then the whole tool is pointless.

Naturally I chose a complex one I could never remember, too. So I have to save it somewhere.

Additionally, being forced to go find it 900x a day because your app locks, is a total pain in the rear end. I realize I can extend the unlock period, but like I just pointed out - this leaves the app completely exposed because you DONT lock the individual passwords.

The software itself should have NO lock on it.

The list of individual passwords should be locked - fully - permanently.

In the rare event someone needs to unlock them, then it makes sense to require a passphrase.

Color me confused.

Comments

  • Penelope Pitstop
    Penelope Pitstop
    Community Member
    edited December 2014
    Options

    Hi @AgileBurger‌,

    I can understand why you think that way. This blog post might help you grasp the logic behind the design decisions.

    If someone finds my lock passphrase, then the whole tool is pointless.

    That's true which is why your master password should be secure and known only to you.

    Naturally I chose a complex one I could never remember, too.

    Choosing a master password that you can't remember is not a good idea. This blog post might help you choose a better one.

    So I have to save it somewhere.

    Good idea but on a piece of paper somewhere safe not in a computer file.

    As you rightly pointed out, the unlocking of the vault is a helpful illusion to make 1Password easy to use. What's actually happening behind the scenes is far more complex. I can't write an effective description of this so I'll leave that to someone else.

    Additionally, being forced to go find it 900x a day because your app locks, is a total pain in the rear end.

    Wow, 900 times a day? I have my preferences set to lock for everything including sleep, screen saver activated, when main window is closed, when fast user switching and if computer is idle for 5 minutes. I'm not required to type my master password anywhere near that amount of times. I've never counted but it would be in the order of the low tens not hundreds. However that isn't a chore because my master password is memorable and the memory is actually reinforced by typing it a few times a day. Yes it is long but I'm lucky enough to have learned how to touch type so it takes a few seconds at most.

    Anyway, I hope what I wrote and the blog post links are useful to you. Hopefully someone else will chime in with a reference to what's going on behind the scenes if that interests you.

    Edit: I forgot to add that if I were required to enter my master password every time I wanted to use one of the passwords in my vault then I would have to type it far more frequently. I wouldn't want that.

  • AgileBurger
    AgileBurger
    Community Member
    edited December 2014
    Options

    That's true which is why your master password should be secure and known only to you.

    Choosing a master password that you can't remember is not a good idea.

    1) A secure password can not be remembered. At least not by someone who has a terrible memory (me). Expecting a user to "remember" it in the first place is a poor business decision, and totally unnecessary when you can just lock the individual passwords instead of the application.

    2) The issue remains: nothing is truly secure since you require a password for the whole program. And that password can be stolen. And everything underneath is exposed.

    save it on paper

    A secure password can not easily be manually typed. Are you guys familiar with what "keyloggers" are? One of the most common ways to steal passwords. You cant copy and paste from paper. If you manually type, you expose your passphrase. Expecting users to manually type a 30 character password is not a viable solution either. Do you see all the facets of why this decision was a poor one?

    I guarantee 99% of your users do not have a very secure "main" password because they have to remember it, or manually type it. That defeats the whole purpose since individual passwords are exposed underneath. I simply can't grasp what you guys were thinking with this. The individual passwords should just be locked. Not the whole program, with exposed passwords while in use.

    Wow, 900 times a day?

    This was an exaggeration. It was not literal.

    I have my preferences set to lock for everything including sleep, screen saver activated, when main window is closed, when fast user switching and if computer is idle for 5 minutes.

    Hope nobody gains access to your computer and takes all your personal information while you're using it then. Which brings us right back to my suggestion. The application is 100% insecure while in use. And if you're manually typing your "unlock" passphrase, the application is 100% insecure while not in use too. (keyloggers)

    All of these problems because you lock the app and leave the passwords exposed underneath. Just lock the passwords underneath, and you don't even need a master password. It literally has no functional value aside from fooling the less-intelligent of your users into thinking the app is more secure.

    Require a passphrase only if the user needs to view the individual password in plain text, or edit it. Since that is so rare, its ideal for requiring the unlock password at that point. Dont lock the application and leave it completely exposed while in use. That is absolutely ludicrous to me.

    I'll check out the blog, but I have a feeling its not going to change my suggestion. I would appreciate any feedback on the suggestion itself, and why its not orders of magnitude more secure, better for users, and more logical?

  • Ben
    Options

    AgileBurger,

    I'm not sure I understand what you are proposing... How would people access their passwords if your suggestions were implemented?

  • Penelope Pitstop
    Penelope Pitstop
    Community Member
    Options

    I'm just another user who was trying to help you AgileBurger not upset you like I appear to have done from the tone of your reply. Sorry if I did because that was the reverse of what I intended.

    A secure password can not be remembered. At least not by someone who has a terrible memory (me).

    Security is a trade off between risk and convenience. Is a 7 word diceware phrase as resistant to brute force attack as a random character string of the same length? No. Is it strong enough to resist a massively parallel offline attack for several years? Yes.

    Is a random character string password you cannot remember so store in an unencrypted Notepad file on your hard drive secure? No, not at all. Your data would be far more exposed to threat from malware of all kinds.

    A secure password can not easily be manually typed. Are you guys familiar with what "keyloggers" are?

    Yes. This has been discussed in this blog post.

    Do you see all the facets of why this decision was a poor one?

    No.

    All of these problems because you lock the app and leave the passwords exposed underneath.

    You seem to be under the impression that the passwords are stored in plain text. They aren't. They are stored in a highly secure format involving a hierarchy of encryption keys. A bit out of date now but this KB article explains it.

    I would appreciate any feedback on the suggestion itself, and why its not orders of magnitude more secure, better for users, and more logical?

    If I understand you correctly, the only time you would ever be required to enter a master password is when a user wishes to view a password as plain text. Is that right? If so, under what circumstance would the user be allowed to automatically log into a website with ⌘ \ ? Could they do that without supplying the master password? How would you propose to store the passwords so that nobody could get at them if they got your keychain files?

    1Password has been designed to resist offline attacks where someone gets hold of the encrypted files with all your password data in them. It is true that the 1Password application can get at this data after you have supplied your master password but it only decrypts passwords as it needs them. Once you lock the app or quit it then all the data is encrypted underneath and nobody can get at it without that master password. Furthermore the encryption techniques used are designed to thwart brute-force guessing attacks by massively parallel computers by slowing down the time it takes to convert your master password into the key required to get at the other keys required to decrypt the other parts of your keychain.

    I hope that goes some way to helping you understand what's going on but if not please ask some more questions. All I can say is that the Agilebits team have thought about this problem very deeply over many years and designed their software accordingly.

  • hawkmoth
    hawkmoth
    Community Member
    Options

    1) A secure password can not be remembered. At least not by someone who has a terrible memory (me). Expecting a user to "remember" it in the first place is a poor business decision, and totally unnecessary when you can just lock the individual passwords instead of the application.

    @AgileBerger - Actually, you can remember highly secure passwords. You can even publish the method you used to pick one from a list of known words. It really is worth reading this blog post, Toward Better Master Passwords. I adopted Diceware to construct my master password and stopped worrying that anyone would be able to crack it.

  • AgileBurger
    AgileBurger
    Community Member
    edited December 2014
    Options

    My goal in creating this thread was to ask why there needs to be a master password for using the app, when you can just lock down the data with a master password.

    I may have figured out the answer on my own:

    "If no password is entered prior to executing the filling of web forms, then a hacker can simply use the app to fill web forms. You must have something that times-out and locks down the whole app when not in use, for this reason."

    That's the angle I wasn't picking up on.

  • AgileBurger
    AgileBurger
    Community Member
    edited December 2014
    Options

    @bwoodruff‌

    I guess my request would be the option of a passphrase for the data itself. In order to view or edit your passwords. And of course it should be different. This way if someone does keylog your password since you're entering it multiple times per day, they still can't get to the data itself. That would address the keylog concern completely I think. It would at least reduce the possible entry points to the rare times you go back into your data and have to unlock that as well.

    Thanks for hearing me out.

  • Drew_AG
    Drew_AG
    1Password Alumni
    Options

    Hi @AgileBerger,

    I guess my request would be the option of a passphrase for the data itself. In order to view or edit your passwords.

    That's how it already works - in order to unlock 1Password and view/edit your data, you need to enter the Master Password. Perhaps I'm misunderstanding your request?

    This way if someone does keylog your password since you're entering it multiple times per day, they still can't get to the data itself.

    Again, I'm not sure if I understand what you mean here. Are you suggesting the use of 2 master passwords in order to access your data in 1Password? What would each one be used for?

    Also, I think this link was already posted earlier in this discussion, but if you're concerned about keystroke loggers, I highly recommend reading this article from our blog: Watch what you type: 1Password’s defenses against keystroke loggers

This discussion has been closed.