Exception message: Unsecured Passwords Format Detected. The Membership Provider that contains the unsecure passwords format is...

    Applies to:
  • Legacy SecureAuth IdP
Deployment model:
  • On Premises
  • SecureAuth IdP Version Affected:  All



    The IdP and realms are functioning normally but the Application event log contains warnings similar to this example:


    Log Name:      Application

    Source:        ASP.NET 4.0.30319.0

    Date:          12/12/2018 12:12:31 AM

    Event ID:      1310

    Task Category: Web Event

    Level:         Warning

    Keywords:      Classic

    User:          N/A

    Computer:      idp.secureauth.com


    Event code: 3008

    Event message: A configuration error has occurred.

    Event time: 12/12/2018 12:12:31 AM

    Event time (UTC): 12/12/2018 12:12:31 AM

    Event ID: f865e83e375b4d029fadb6fc97a99a29

    Event sequence: 2

    Event occurrence: 1

    Event detail code: 0


    Application information:

        Application domain: /LM/W3SVC/1/ROOT/SecureAuth10-41-131522725379992307

        Trust level: Full

        Application Virtual Path: /SecureAuth10

        Application Path: D:\SecureAuth\SecureAuth10\

        Machine name: IDP


    Process information:

        Process ID: 10779

        Process name: w3wp.exe



    Exception information:

        Exception type: ConfigurationErrorsException

        Exception message: Unsecured Passwords Format Detected. The Membership Provider that contains the unsecure passwords format is: SqlMembershipProvider. The obsoleted password format is: clear. For more information, see https://go.microsoft.com/fwlink/?linkid=834784.


    The above example is for the SqlMembershipProvider but the same message can be received for the ODBCMembershipProvider.




    .NET has detected that the listed providers are set to use plain text when storing passwords in the respective data store type.

    IdP ships with some undefined/unused membership providers using the default setting of "clear" (plain text).



    If the warning concerns a data source that is undefined\unused then the warning can be safely ignored as the warning is just referring to the defaults and does not pose a security risk. To prevent these warnings in the first instance see the additional notes below.

    When the the data source is defined by filling out a connection string etc. and in use, it is also normal procedure to choose an encryption type that isn't "Clear".

    However if the data store type (that the warning mentions) is already in use on the given realm and found to be storing passwords in clear text then this should be reviewed to verify it meets the security standards expected.  Microsoft advise that "hashed" is the best method to use:



    Additional notes:

    To prevent these warnings, the unused membership providers should be set to used "hashed" as the password format.  To accomplish this do the following:

    1. Back up the web.config for the respective realm generating the warning

    2. Decrypt the web.config

    3. Open the web.config in a text edit and search for:


    This can usually be found in both the ODBC and SQL sections.

    If the realm isn't using those types of datastore, where passwordFormat is set to "clear", then it should be safe to change





    4. Save the web.config

    5. An additional change is required because by default IIS auto-generates encryption keys each time the worker starts.  That's no good if the values are used to encrypt or hash passwords because it will never evaluate to the same value twice.

    To set static keys, open the admin console, then go to the respective realm and navigate to the Post Auth tab | Machine Key section, then click on "Generate New Keys".

    6. Save and test the realm.



    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 1 found this helpful



    Please sign in to leave a comment.