Lost Bank Account Password due to 'previously used password' not saved

chriswayg

How to reproduce:

• Add a Password field to a Bank Account item
• Save the item
• Edit the item and change the Password
• Save the item

The password change at the online bank was unsuccefssful, and I wanted to try to log in with my old password, but it was nowhere to be found in 1Password. As a result I was locked out of my bank account. (Time to restore online access in this country: 3 days to 3 weeks.)

Expected Behaviour:

• The first password should be accessible in the 'previously used password' section

Actual Behaviour:

• The Bank Account item shows no 'previously used password' section

Version:
1 Password 6.8.9 on Mac, Sync via Dropbox
same problem with the iOS version

---

1Password Version: 6.8.9
Extension Version: Not Provided
OS Version: macOS 10.12.6
Sync Type: Dropbox
Referrer: forum-search:Lost Bank Account Password due to 'previously used password' not saved

AGAlumB

@chriswayg: Thanks for getting in touch. I'm sorry to hear that you're having this trouble, but I'm not sure I follow. 1Password can only save and fill login credentials using Login items, so there wouldn't (and shouldn't) be any "password history" there since it isn't possible to save to a Bank Account item in the "Update Login" process:

Change your passwords and make them stronger

1Password also has no way of knowing your intention for any custom fields, so it never saves or fills that information. I guess my question is, how are you logging into this bank account anyway? It sounds like it isn't using 1Password, unless I've misunderstood your description. If you can fill in the blanks, that may help.

ericsh

I believe I've seen the same thing. In my case, the password isn't stored under "Logins", it's stored under "Passwords". It seem like a bug that "Logins" items save previously used passwords for user recall, but "Passwords" items do not.

Ben

@ericsh

It is working as designed. The passwords category is much less feature rich than the logins category. It’s primary intention is to record passwords generated by the built-in password generator that haven’t been saved ortherwise. If you have a full set of credentials for a website it should be saved in a login item, not a password item.

Ben

ericsh

Intersting, I did not realize that the Passwords category is mainly for internal 1Password use. I use it (i.e. add my own entries) in cases where (for various reasons) there is no web-addressable URL and/or username to provide, or it requires a client other than a browser, for which there is no 1Password integration.

So is your suggestion to use the Logins category anyway, but just leave the unused entries (e.g. username, website) blank?

Corey_C

Generally, yes, @ericsh.

ericsh

Okay thanks, this is really useful info. And it's nice that there's a handy "Convert to Login" button to make the switch. :-)

AGAlumB

:) :+1:

chriswayg

The issue is still occurring in 1Password 7. I tested it on a 'Bank Account', a 'Password' and a 'Login' item. Only the default password field (or default PIN field) in a 'Bank Account' item' gets a password history. If you create an additional custom password fields, they will not have a password history under "View Password History".

1Password needs to communicate clearly, which fields have the password history saved, so we can adjust the way we save additional passwords for a bank account or website. Apparently the 'Password' item used to behave differently and did not have a Password History (according to a comment above.) This appears to be fixed, as now it does have a Password History.

@brenty As to the need to have additional password fields: it depends on the login procedure of the bank. Some require the regular password plus additional codes to be saved, which can also be changed. On login ING-DiBa Bank asks for the 2nd and 6th digit for example. If you loose that code (for example due to an unsuccessful code update) you are locked out and need to wait for a week to receive a letter from the bank.

Now I noticed, that the Web Version of the Vault handles Password History differently. Thus if my vault is on a 1Password.com account, I can see "Item History" instead of "Password History", which gives me a history of all fields. But the "Item History" is not visible in the desktop version and not available for stand-alone vaults (or traditional desktop licenses).

AGAlumB

@chriswayg: Thanks for sharing this. 1Password doesn't have any way of knowing what any of a particular site's processes mean, most especially when they're not adhering to web standards for login forms (or best practices for security in general), but I'm sorry for the trouble you had as a result of that conflict. 1Password has no facility for "password history"-like behaviour for non-password fields...but indeed this problem has already been solved in 1Password memberships with the item history feature. That's not something we can just tack on to the old local vault formats at this point as it would break things across multiple platforms and versions, as it's not something that's built into that; but if you'd like help transitioning to a membership, just shoot us an email at support@1password.com and we can help. :)

chriswayg

@brenty thanks for clarifying, that only one Password field has its own history in the item.

1Password has no facility for "password history"-like behavior for non-password fields...

Well the custom fields can actually be created as Password fields. That these field have no password history could be made more clear, as it is possible to create multiple custom Password fields for each item, and the assumption would be, that each field has the same behaviour as the default password field.

I am currently trialing 1Password membership, which has complete item history. But this feature is not available directly in any of the apps, it can only be accessed on the web-version. I am missing a link inside the app to access the Item History feature, even if the item history is only stored online. Evernote does this with "View History" of previous versions of notes, which require an internet connection.

AGAlumB

@chriswayg: Indeed. Ultimately we'd like to be able to have pretty much all functionality in the native apps. But it's a matter of prioritizing what we work on, since we can't implement everything that's currently available only in the web interface in all six(?) of our other apps. We've done that with some already, and we'll continue to work at it though. It doesn't come up often, but I could envision item history being useful in the app too. Thanks for bringing this up! :)

chriswayg

@brenty thanks for considering that as a future enhancement.

ag_ana

@chriswayg, on behalf of brenty, you are very welcome!

Have a wonderful day :)