Two autotype per entry besides the database default
Popular easy-to-use and secure password manager
Brought to you by:
ronys
Menu
▾
▴
#788 Two autotype per entry besides the database default
Two autotype options per entry could be very useful. The use cases I see for this are the following:
-
Websites that remember the username. Some of these sites provide a username field that the user can click into and use their database default autotype (usually \u\t\p\n). However, some sites, and google.com is an example of this, do not provide a username field when it remembers the username and only a password field. In cases like this, user has to click on a link to login as a differrent user to use their database default of \u\t\p\n or manually make their autotype \p\n to only enter the password.
-
Changing password often requires the user to enter their old password and then their new password twice. In cases like this, manual editing the autotype to \p\t\p is required.
If the either use case 1 or 2, for sites where the user has a custom autotype for login, it means the user has to delete it,change it to something else and set it back to what they typically use for login. As a work around, I save my custom autoype I use for login in Notes, so that if I have to change it temporarily for passord change as an example, I can copy and paste from Notes.
However, the new feature I propose is one where each entry has two autotype besides the database default. The first autotype would work like it does now (for example, it is the one that is invoked or the database default for the way autotype can currenty be invoked) and the second one is special and takes a special sequence to invoke it. For example, a right click on the entry would have a item to autotype the 2nd autotype sequence if it is not empty.
Related to this, I also wonder if a new autotype key could be added to type the most recent previous password. Something like \pp would mean autotype previous password. So, if I was to change password and have to type current password and then the new password twice, I could click on the link link for the site password change page form, change the password in Password Safe (ideally user knows what is acceptable password policy for the site), change 2nd autotype to \pp\n\p\p\n, then right click on the entry to autotype the 2nd autotype into the password change form. Done!
I think that use-case #1 is adequately covered by allowing entry-specifc override of the default autotype sequence.
The second use-case is more interesting - in effect, you're proposing support for automating the password change sequence of a site! To complete this, I'd add a code to genearate a new password...
Worth consdering, at least for 4.0...
Rony,
Thanks for considering this. I agree that an entry-specific override of the default autotype sequence provides a way to send a custom autotype sequence. However, the point I'm trying to make is that two per entry autotype sequence is beneficial where you would think one is all that is needed.One scenario is that sometimes a site comes up asking for username and password (for example, because user had clear their browser cache and cookies) and sometimes only the password (because the site had rememered the username). At login time, the user can simply select between her two custom per entry autotype sequence without having to edit the entry to change the autotype sequence.
The other benefit for two autotype sequence per entry is that the user can this feature to make password change easier for themselves without Password Safe having to have any dedicated automated password change feature. Essentially, providing two autotype sequence per entry is the tool you are providing to the user to enable them to simplify the process of password change. As I mentioned in my original post, one other 'tool' in this toolbox that would be of great help is the ability to send the prior password from the history as part of a autotype sequence (for example, \pp). An example of how a user could use these tools for password chage is as follows:
i) user logs into the website and goto the password change page
ii) user changes password of the entry in Password Safe
iii) user makes sure their 2nd autotype sequence for the entry is set to send what their password change page requires. For example, for some sites it might be \pp\p\t\p\n (\pp = prior password which was their password before it was changed in step ii) for other sites it might be just \p\t\p\n
iv) user send their 2nd autotype sequence to the password change page.
Password Safe can still provide an automated password change sequence for a site, but my worry here is that every site is going to be a little different and be too much effort for Password Safe developers to keep up with.
I second this request. It is extremely common for websites to ask you to enter just your password when you are already logged in and want to change something about your account.
Currently, the only way to do this is to copy the password to the clipboard and then paste it into the site which, I assume, is less secure than allowing autotype to push the characters directly into the keyboard buffer.
I'd like to have a second autotype function that autotypes just the password by default. If it can be modified to type something else, that's even better.
I second Tim H. I realise a proliferation of autotype options would complicate the user experience, and for most fields I'm ok with the extra steps of copy and paste – but password I never like to place on the clipboard. At the moment I deal with non-standard logins by displaying the password in the entry, and typing it itno the login field myself.
I don't edit the default or individual entry AutoType arguments because I am mostly using it read only, and not very often – my R/W usage is via the Android port, where you use a dedicated soft keyboard with username and password buttons – and I wouldn't keep up with changing web login requirements, or remember which records were set up non-default.
If it were to go beyond the addition of a single "AutoType password" option then my vote would be for "Autotype previous password in history", but that would be very low priority.
Huw,
Maybe you are not aware of this; the \q option to autotype the previous password from the password history is already implemented. What I see is still needed to complete this FR are the following:
Regarding you typing you password for non-standard logins, you can also use the dragbar, which won't put whatever you drag into the clipboard and would also save you from having to type the password.
Finally, another recommendation is to make your default Autotype string \t\s\u\t\p\n instead of the current default of \u\t\p\n because \t\s\u\t\p\n will clear the username and password fields before autotyping (at least I've have never not seen it do this in the many years since I have been using \t\s\u\t\p\n as my default Autotype string).
MrMe, thanks for the comment. The drag bar appeared long after I started using PWS and I never looked at it because I thought, "Why would I ever need that?"
It does appear to do what I want with regards to entering just the password without going through the clipboard. The only thing that would make it just perfect would be if I could customize the main toolbar by adding drag bar button(s) to it instead of needing to keep the drag bar open. It would be nice, but I really don't need it.
Thanks MrMe! Although the Dragbar is visible by default, I had not consciously registered its presence – in order to locate it I just had to untick and retick under the view menu – let alone investigated its function. While a right-click option would be more ergonomic, dragging is a useful solution and for me makes this feature request much lower priority.
Hi, I have a use case for this, too. The password in question is used for a number of applications (no - this is not re-use but a central directory that feeds them) and they have varying login prompts. (Most is '\u\t\p' some are just '\p' or 'DOMAIN\\u\t\p') Using multiple entries is not cool because I would need to sync them manually.
I agree that adding arbitrary autotype entries might be confusing and keyboard shortcut would be complex.
How about adding the ability to specify an autotype pattern in link-entries?
It is already possible to specify a different user name in there, autotype would be consistent with that.
You might want to look into the "Alias" feature of PasswordSafe, described in the "Aliasing Passwords" Appendix, copied here for your convenience. I think it provides a useful way to reuse passwords using differnent autotype sequences, etc.
Password Aliases
If you're using a "single sign-on" system that allows you to share the same password across different machines/servers/applications, etc. you can setup Password Safe entries accordingly, so that changing one password affects all other related entries. This is called "aliasing" entries. This section describes how to define and use such aliases.
Summary
The basic idea is to allow one entry's password to be referred to by another. The "referred to" entry is called the base, and the "referring" entry (or entries) is (are) called the alias(es). When an entry is set to be the alias of another entry, the alias's password effectively "follows" that entry's password: If you copy the alias' password to the clipboard, the password that gets copied is the base's. If you change the base's password, this is immediately reflected in all the alias entries associated with the base. Although this may sound complicated, in fact it's quite simple and intuitive to use. The hardest part is setting up the aliases, as described below.
Defining an alias
In Password Safe, an entry can refer to another's password by means of a specially formatted password in the referring entry. The format is the "name" of the referred-to entry enclosed in square brackets. Most of the time, you can think of "name" as synonymous with the title field of an entry, so if the base entry's title is "master", for example, then entering "[master]" (without the quotes) in another entry's password field is enough to define the other entry as an alias of "master".
In the general case, a "name" can contain all of the following fields, separated by colons: Group, Title and User name. Note that if the title is unique in the database, then the other fields are optional. Likewise, if the group and title together or title and user together specify a unique entry, then the corresponding user or group doesn't have to be specified.
In Password Safe entries, only the Title and Password fields are mandatory. Group and User name fields are optional as long as the resulting combination of "group/title/user name" is unique. As indicated above, the alias' "password" is in the form [g:t:u] but in fact you only have to specify enough information to uniquely identify the base entry. So, if there is only one entry in the database with title 't', then [t] would be sufficient - since title is mandatory and only one item is given, it is assumed to be the title. If there were more than one entry with this title, you would be warned that this is the case, and you would need to be more specific in order to uniquely identify the base entry by adding either its group, its user name, or both. As long as there is a matching unique entry, any of the following formats are accepted: [g:t:u], [g:t], [t:u] or [t]. Specifying a colon without a value implies an empty field, e.g. [g:t:] means an entry with title 't' in group 'g' and with no user name value and [:t:] specifies an entry with title 't' in the root with no user name value, etc.
If you change the password of an Alias (either via the Generate password button or by typing in the password field), the change will only be made when the Apply or OK button is clicked. However, if you wish to change the base entry's password, then you should edit the base entry directly. If you change the Alias's password from [g:t:u] to some other value not in this format, it will change from an alias to a "normal" entry, and will have no relation to the previous base entry. Of course, you can restore the connection by Undo, or manually editing the password.
Unlike shortcuts, which refer to the base entry for all fields, aliases have their own values for all fields except for its password, which is its base's. For example: copying the aliases URL will use the alias's value but copying the alias's password will copy its base's.
Finally, if a normal entry was saving its password history before it was made an alias by changing its password as described above, then it will retain this history. If the alias is then reverted back to a normal entry at a later date, this password history will again become active and be updated if its password is changed.
The following examples should make this clear.
Examples
1. If the base entry's title is "LDAP Server", and there are no other entries with that title, then an alias can be defined by an entry that has "[LDAP Server]" in the password field.
2. If there are "LDAP Server" entries in two different groups, say "Dept. A" and "Dept. B", then one can specify an alias to the latter by "[Dept. A:LDAP Server]". Note you do not have to specify the user name if the information you have provided uniquely identifies the base entry.
3. Different user names can also be used to differentiate between similar base entries, e.g., "[LDAP Server:Joe]" and "[LDAP Server:Mary]".
4. Finally, all three fields may be specified, as in "[Dept. A:LDAP Server:Joe]"
Hi Rony,
thanks for pointing this out - it is exactly what I was looking for!
It is a well hidden feature - shortcuts are more easy to find and I wouldn't have imagined that there is a competing feature so similar to it. Might be worth mentioning/linking aliases on the help for shortcuts.
Actually, I don't get why there is a need to support both at the same time - while shortcuts are easier to create, aliases can cover all use cases shortcuts cover. On the other hand, if it were possible to specify also the autotype pattern, I see not much that would be missing. (history and policy don't make sense - not sure about Notes and Email - custom URL, double click action & friends would be nice, too). Once you know about both features, there's no harm to have both options either :-)
So, thanks again for the pointer and the great tool.