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

SecureAuth IdP Version Affected:  All

Description:  

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

Description:

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

    Account name: NT AUTHORITY\NETWORK SERVICE

 

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.

Cause:  

.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).

Resolution: 

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:

https://docs.microsoft.com/en-us/dotnet/api/system.web.security.membershipprovider.passwordformat?view=netframework-4.7.2

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:

passwordFormat="clear"

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

from:

passwordFormat="clear"

to:

passwordFormat="hashed"

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.