Heikki H.

+1

Would be nice if the browser extension could also copy TOTP code if the password item has that configured.

That would work too, yes. Might be even better.

Currently if a user is disabled, PasswordState UI end user can't quickly determine this by checking the user icon, which could have some overlay to describe the user can't access the system and the shared password list in question. One can remove disabled users and their access, but if you don't to that, end users may get confused why some person has access to passwords, even if they no longer work at the company. Since PasswordState has the feature to enable and disable users, there should be visual indication of this for end users. Please make a separate user icon for users which have been disabled in the system.

Would like to see option to limit users from adding attachments to specific folders. Since it's already a global configuration, would expect not to be big thing to make per folder setting for it too. Either implement a way to prevent users from adding documents to any folders, but continue to allow uploading them to lists and password items. Or provide a way to disable uploading documents just to specific folders. Use case: Admin makes some folder hierarchy/context on where people should be storing their lists. If there's no way to prevent uploading documents, people tend to forget or not read internal guidance and they end up storing personal documents to folders which are shared to also others. We would like to be able to prevent this from happening.

Could this message be made admin configurable if not fully, at least able to add a mailto-link or https web-link to be added to the message.

Well, I guess not a problem since "There is no rate limit on the Pwned Passwords API."

Since the release of 8.6 - Build 8600 there is the report feature. How does the integration take account of haveibeenpwned API rate limiting? https://haveibeenpwned.com/API/v2#RateLimiting I mean if there are multiple users running simultaneous reports, are the API calls queued or will we hit the rate limits? And what happens if the report generation hits the rate limit?

Like in thread for Microsoft Teams, which most enterprises are more likely to use.

Thanks @RTCIO. I've been discussing this with ClickStudios awesome support and I believe they are working to implement this feature. Hopefully in next version and during August 2018

Yes, but that's also an email notification as default, right? This banner would be visible only on site, so it would bother only active users. And not in the PasswordState notification area, which our users rarely check. A banner would be much more visible, I mean banners like seen on this Google Image search https://www.google.com/search?q=site+notification+banner+maintenance&tbm=isch

Would be nice to be able to set a notification banner say a week before a maintenance break. A small banner with free text field to admins to set. Additionally schedule this to appear on predefined date/time. Banner should be user dismissable at least per session.

Forgot to mention that if one now has the shared secrets/keys in some password manager like Keepass and would like to share them to team and migrate the TOTP generator to PasswordState, it would require him/her to use some gr-generator to generate a image, upload that to PasswordState before being able to generate tokens from PasswordState. If the feature would have been done to support manually enterin secret/key, migrating to PasswordState would be just copy&paste. Way more secure and easier.

Version Passwordstate 8.4 (Build 8411) added support for generating TOTP tokens withing PasswordState, feature is called 'One-Time Password Authenticator'. The setup is shown in this video Passwordstate - Whats New in Build 8411? starting around 1:41. Discussed the missing manual setup issue with PasswordState support and they won't fix this if others won't need it too. So I ask you to vote for this feature. Since PasswordState is a web app and in most cases I don't this it has access to device camera to scan a qr-code (specially if your desktop doesn't have one). So users would/might end up saving the issuer generated qr-code in a image file locally and uploading that image to PasswordState. That file might not get securely deleted afterwards, which it should since it has the shared secret in it. In worst scenario user leaves the qr-code in his/her Downloads directory. There should be manual way of adding the TOTP token shared secret/key to PasswordState, one can get this from the most token issuers, quickly checked that Facebook shows key as default Google asks “can’t scan it?” and gives out the shared secret. Twtter also has “can’t scan code”. AWS shows “Show secret key for manual configuration”. Microsoft also provides “or enter code manually” as default option. Dropbox also has the option to show the code. Sure all of them default to qr-code, since it’s user friendly for personal use. But if using a password manager, best to use manual method and store the secret/key within password manager so you can migrate to another TOTP token generator easily. Most of those authenticator apps won’t let you restore/show the secret after adding a service, some do but most won't. It's fine if the authenticator and the shared secrets are in backup scope, like Github said in their blog post. The manual setup method would be much user friendly in PasswordState, specially for a shared password list. And lets not forget the backup/restore/migration need, I might wan't to change my authenticator app. If the shared secret/key would be stored in a password manager, migration is easy. When entering the secret manually, we would need to be able to enter also the time perioid (default 30s) and number of digits in token (default 6). Optionally token hash algorithm might be needed (default SHA-1). Since token issuers usually document which format are they using, PasswordState could have predefined list of Issuers where to derive the settings from (by quick googling found this project which has list of common Issuers) and have option to set them yourself.

Well, using range search is fine for anonymity-wise. But if there would be a option to use offline list, I'd still choose that one. Hosting 30GB of files on a Windows server is not an issue, I would not expect it to be for anyone opting to a offline list. Just the search performance would need to be quick and if making transforms from the source files to some other form, performance of that transformation. Transformation could also happen on some other server than one's hosting PasswordState. One thing to scratch your heads, would be when Troy releases new version of pwned passwords list, would it be manual update and how would we get information, do we need to follow Troy's blog or could you provide the information about list updates within PasswordState notifications. Without offline list support we need to weight the pros and cons of using online API for this feature.