I'm currently dealing with the aftermath of CircleCI's security issues and the current App Password' feature is showing some limitations. I'm not sure if staff read this area but I may as well post here.
Our formal use of App Passwords is for deployment scripts so that curl can be used to access a deployment script that is part of the repo using a dedicated user account under the control of the Ops team, the App Password is then used by git during the deployment.
- Having to regenerate passwords shows a rather odd limitation - I can not see the rights granted to a password. So while the password itself is a clear text value the rights allocated to it seem to be considered a one-time 'secret', which seems a little daft. I now need to document the rights granted to a password elsewhere to easly change it in the future.
- The issue above results in the Label text being mainly used as a description of the allocated rights, rather than a more general label.
- While you can create a number of App passwords for a user there is no way to link a password back to the exact entry in the list. Yet more external documentation needed to list the first few characters of the password against the allocated label. It would be far more helpful for the system to create a tag that is added to the password and shown against the entry in the list. This would result in the password gain say 8 characters in length before hasing and the 8 characters being stored as clear text in the password table, but not losing any strength.
(It is worth noting that Bitbucket already does some form of password tagging as the first 4 characters of the password seen to be constant.)
As for how this feature is being used by team members in other processes I have no idea as there seem to be no admin oversight of staff creating App Passwords. This seems to be a major security issue in its own right. I can not currently tell who has created App Passwords and/or who has bothered to recreate them after telling them to do so.
Even if I could tell who is using App Password without something like the tag proposed above I have no real way to audit our code base for such passwords - a random string of text is rather hard to search for.
