Jump to content

Search the Community

Showing results for tags 'mfa'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Essentials
    • Announcements
  • Passwordstate 8.x
    • General Support
    • Feature Requests
    • Feature Requests - Completed
    • Known Issues
    • Installing Passwordstate
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • Mobile Client
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 7.x
    • General Support
    • Known Issues

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 7 results

  1. Hi, I am looking for a new feature, that upon login after entering primary authentication method (e.g. Users/Password) that users will be able to select (from a drop down or similar) their secondary authentication method. For example, if a user had multiple authentication options configured, such as Google Authenticator, YubiKey authentication, Email temporary pin code, they could select the most convenient authentication method at the time of login. Another example could be that users only have YubiKey authentication implemented, and there was an issue with the Yubico API or the internet connectivity of the PasswordState server, users will not be able to login due to the reliance on the Yubico API. In this case the user could choose to use another authentication method, such as Google Authentication which does not rely on internet connectivity allowing them to successfully log in.
  2. Tyler_S

    User selectable MFA option

    Hi Team, I am unsure if this topic will be required to be a feature request or there if these features are currently available, however I am looking to be able to have users select the MFA option upon login. For example, I currently have forms and YubiKey authentication setup, however I would like users to be able to select the MFA option, for example choose between YubiKey/Google Authenticator/etc. Currently if the Passwordstate server was ever to lose connection to the internet/Yubico API, users will not be able to login due to the reliance on the API. If this feature was available, in this scenario users could select Google Auth/Other as their MFA option, and still be able to log in successfully. Is there currently any way to setup this up in the current version of Passwordstate? Any help would be greatly appreciated
  3. parrishk

    MFA Recovery Codes

    Seeking thoughts on the idea of providing "recovery codes" for a user to use in the event that their MFA option does not work, is lost etc. Typically, a web service will allow the saving of a set of recovery codes (typically 5-10) that can be used once to gain access to their account.
  4. Hi, With SAML2 in Azure AD in your documentation (Passwordstate_Security_Administrators_Manual.pdf pages 119-125), this works fine but one parameter is missing in Passwordstate: the logout It's not possible to disconnect users only if the user closes his browser. This logout parameter is https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 Could you set up the logout parameter in the next build of Passwordstate configuration with SAML2 please ?
  5. Hello, I was not sure how to describe this request in the title... Basically, looking for the feature to require two-factor authentication for all users but give the user the choice on which second factor they use. For example, a user must use AD Authentication and one of the allowed second factor options (Google Auth, Yubikey, etc). Possibly even have the option to support two second factor options. Google Auth and Yubickey (with only one being required at the time of authentication). Does this make sense? Thanks,
  6. 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.
  7. Hi, I'm a happy home user of Passwordstate (PWS), and so far the experience has been very nice. I've exposed my PWS to the internet through the use of an Apache reverse proxy, and that works great. Before I did that, I of course made sure I had 2FA enabled for my user, as only using username and password seemed far too dangerous. This has worked perfectly, but, I've been a bit annoyed by the fact that I needed to use 2FA even when I access my PWS from home. So, reading a bit about it lead me to the Administration -> System Settings -> allowed ip ranges -> Web Site Allowed IP Ranges setting, where I've added my internal network range, and set Authentication Option to Forms and Google Authenticator I've also made sure to specify my Apache reverse proxy IP in Administration -> System Settings -> proxy & syslog servers -> X-Forwarded-For Support. My user account is set to use Use the System Wide Authentication Settings under Web Authentication Option. The Apache reverse proxy is set up to use RemoteIPHeader X-Forwarded-For in the configuration for my PWS site. I can also see my real, remote client IP in the IIS logs after adding the X-Forwarded-For column to the logging options in IIS, so I know it gets through. Signing in to PWS from home works fine, with just username and password now. However, signing in from remote still only requires username and password. I'd like remote sign in to require 2FA. I'm sure I'm missing something, but I can't really see what. Any help would be greatly appreciated. Thank you!
×