Question - Login/min_password_digits to 1

[Former Member]

Hello,

We are adding complexity on our passwords. We have tested "Login/min_password_digits to 1" in DEV and QA successfully and ready to move to PROD. The numeric value on passwords is now being required. I have overlooked one possibility and could not test without delaying the deployment for another week since system restart is only on the weekends. My question is the u201Cwhat ifu201D in the scenario I was not able to test.

What happens to the user/users with password that currently do NOT have any numeric value/values? Do they get immediately prompted to change their password with numeric when "Login/min_password_digits to 1" is in effect or only when their password expired and prompted to change?

We are running ECC 6.0 and SAPGUI: 710 Final Release, version 7100.2.8.1039, patch level 8.

Thanks in advance.

John N.

[Former Member]

Hi John,

It will apply to DIALOG and COMMUNICATION type users when they next change their password.

It will not apply to SERVICE and SYSTEM type users, they are not subject to password validity rules and cannot change their own passwords - unless they have admin authority to do so (S_USER_GRP actvt '05').

You can force the system to interogate the password's compliance with the policy prior to their existing password expiring, but that is optional. It will then force DIALOG type users to change their password and reject a COMMUNICATION type user's logon.

SERVICE and SYSTEM users are unaffected.

So, instead of testing - you can cover most of the risk by checking that your user types are set correctly.

You can also "tune" the password wizard to generate passwords which comply with the policy, and limit the length so that they don't confuse folks during the transition. See the settings in PRGN_CUST.

Cheers,

Julius

Edited by: Julius Bussche on Sep 23, 2009 1:33 AM

[Former Member]

>

> It will apply to DIALOG and COMMUNICATION type users when they next change their password.
> Cheers,
> Julius

That's what I need to know. Thanks.

[Former Member]

Hi John,

I have a querry. Do you reset passwords in DEV/QA as well? Do you have expiry date set for DEV/QA systems as well? If yes this can be tested in DEV/QA as well.

[Former Member]

>

> Hi John,
> 
> I have a querry. Do you reset passwords in DEV/QA as well? Do you have expiry date set for DEV/QA systems as well? If yes this can be tested in DEV/QA as well.

Thanks for the suggestion but per my post I can test it in DEV or QA but would not like to delay the deployment for a week due to scheduled weekly restart.

[Former Member]

There is one little "gotcha" though which you might want to check on and test for impact... or rather whether you are exposed to the risk.

Within PROD environments you are likely to have many more inbound connections to the system which authenticate using passwords than QAS and DEV. Particularly if the cardinality of these connections is not correct (i.e. you have a multiple of them pointing to one user which currently does not have a digit in its PWD) then there is a risk that some error occurs and a password is reset. From then onwards the new rules apply to the admin in SU01 as well.

The implication is that you cannot set the PWD back to it's old state to reactivate the many connections which are failing. You will end up having to reset all those connection's logon data on the client side of the calls. You might need to look long and hard to find them all and monitor the system very closely for a few months.

There might be a little trick, but the obvious one of placing the hash back again will not work because there is an application attribute to it now.

While doing that (fixing all the logon data) you might as well fix the cardinality of the connections at the same time...

=> Please check the user types in all clients and cardinality of connections.

Cheers and good luck,

Julius

[Former Member]

>

> There is one little "gotcha" though which you might want to check on and test for impact... or rather whether you are exposed to the risk.
> 
> Within PROD environments you are likely to have many more inbound connections to the system which authenticate using passwords than QAS and DEV. Particularly if the cardinality of these connections is not correct (i.e. you have a multiple of them pointing to one user which currently does not have a digit in its PWD) then there is a risk that some error occurs and a password is reset. From then onwards the new rules apply to the admin in SU01 as well.
> 
> The implication is that you cannot set the PWD back to it's old state to reactivate the many connections which are failing. You will end up having to reset all those connection's logon data on the client side of the calls. You might need to look long and hard to find them all and monitor the system very closely for a few months. 
> 
> There might be a little trick, but the obvious one of placing the hash back again will not work because there is an application attribute to it now. 
> 
> While doing that (fixing all the logon data) you might as well fix the cardinality of the connections at the same time... 
> 
> => Please check the user types in all clients and cardinality of connections.
> 
> Cheers and good luck,
> Julius

OK. I might have a problem with the communication users. I have a few communication users that we need to verify. A majority of our RFC users are service and systems. Thanks for the heads up.

[Former Member]

Our two communication user's password have not change for more than two years. I can only assume the communication users are not affected with the password expiration rule therefore won't be affected on our Login/min_password_digits change. Just as a precaution I'll move back our implementation for a week and perform more test.

Thanks for all the info Julius.

[Former Member]

There are a number of things you can do here:

The obvious question is: What is the password currently? I assume you know that or can find it out.

The more important question is how many RFC clients are calling this user? (=> cardinality).

Via the RFC server profiles in ST03N you can gain a quick impression of this and if more than one source then you need to be carefull. Activating a dynamic SM19 log for them for a few days, or even minutes... can sometimes confirm that there is a risk.

The key here IMO is to correct the cardinality of the connections and their users in the target systems. The PWD is just one of the symptoms - their authorizations is another.

If you take a look in the Security Wiki, you will find something I put together for switching from "legacy" RFC setups to more secure scenarios. Feel free to add to it if you wish.

The features of using downward compatibility of passwords and replacing generic interface users with dedicated SYSTEM users for the connections and usage types are very usefull here for such password problems. The downward password compatibility parameter (if set to "2") can be usefull for monitoring the use of an old password, and as you are familiar with CUA there is also a little opportunity there for you to restore the password if the digit is after the 8th character. The parameter is dynamic, so once you feel safe you can make that switch and if something goes "bang" you can easily switch it back without a restart.

But ultimately the goal should be to correct cardinality risks and disable the compatibility of the new password with it's old hash version. You can also "mimic" older passwords using new hashes if you do not set the password rules so strict that it cannot be complied with.

Cheers,

Julius

[WolfgangJanzen]

>

> Our two communication user's password have not change for more than two years.  I can only assume the communication users are not affected with the password expiration rule therefore won't be affected on our Login/min_password_digits change.  Just as a precaution I'll move back our implementation for a week and perform more test.
> Thanks for all the info Julius.

No, you are wrong - communication users are (in principle) also subject of the password change requirements.

See note 622464.

[Former Member]

> No, you are wrong - communication users are (in principle) also subject of the password change requirements.

> See note 622464.

Not in principle, but John's observation is correct in practice. This is not default behaviour either.

> But you can configure the system (by setting login/password_compliance_to_current_policy to value 1) to check every time a password is validated whether it's still compliant with the current password rule.

Not every time. A SYSTEM and SERVICE type user's password would not be subject to this, even if it was activated.

It could be usefull to find incorrectly set user types though, unless the existing password does comply with the new rules already.

Personally, I check in all clients that the user type is set correctly and the connection cardinality is not illogical such that it causes problems later - and have not had any problems with setting more complex password rules, including special characters.

To mimic any downward compatibility or client programs which might set the PWD to UPPER CASE, I simply don't force a lower case password and for special users change the generated characters to UPPER CASE and ensure that the it does not exceed 8 characters.

But my weapon of choice against this is still rfc/reject expiredpassword and now also icf/reject_expired_password. I find these parameters very efficient in keeping security up to scratch, if the implementation (or clean-up) was done thoroughly.

Cheers,

Julius

[WolfgangJanzen]

>

> > No, you are wrong - communication users are (in principle) also subject of the password change requirements.

> > See note 622464.

> Not in principle, but John's observation is correct in practice. This is not default behaviour either.

Well - if a password change is currently not enforced although it should be, then this is nothing one should rely on ...

> > But you can configure the system (by setting login/password_compliance_to_current_policy to value 1) to check every time a password is validated whether it's still compliant with the current password rule.

> Not every time. A SYSTEM and SERVICE type user's password would not be subject to this, even if it was activated.

Yes, you are right - that point I've forgotten to mention in my posting (but it's documented in the system: the RZ11 documentation of that profile parameter is quite precise).

>

> To mimic any downward compatibility or client programs which might set the PWD to UPPER CASE, I simply don't force a lower case password and for special users change the generated characters to UPPER CASE and ensure that the it does not exceed 8 characters.

Sorry, that's not entirely true: even if you do not enforce the usage of lower-case characters in passwords this does not ensure that you obtain downwards-compatible passwords: as long as you do not prevent the usage of lower-case characters and as long as you do not prevent the usage of passwords which consist of more than 8 characters, you have to deal with (potentially) downwards-incompatible passwords.

>

> But my weapon of choice against this is still rfc/reject expiredpassword and now also icf/reject_expired_password. I find these parameters very efficient in keeping security up to scratch, if the implementation (or clean-up) was done thoroughly.

Do you really think that those two parameters can be set to non-default values in productive systems? I have my (personal) doubts - they are main switches ("on" / "off") effecting the entire system.

[Former Member]

> > {Julius Bussche wrote:}

> > To mimic any downward compatibility or client programs which might set the PWD to UPPER CASE, I simply don't force a lower case password and for special users change the generated characters to UPPER CASE and ensure that the it does not exceed 8 characters.

>

> Sorry, that's not entirely true: even if you do not enforce the usage of lower-case characters in passwords this does not ensure that you obtain downwards-compatible passwords: as long as you do not prevent the usage of lower-case characters and as long as you do not prevent the usage of passwords which consist of more than 8 characters, you have to deal with (potentially) downwards-incompatible passwords.

What I do is that I make it selectively true: If I suspect or know that a password will need to be downwardly compatible, then the wizard (which is instructed to generate an 8 characters password with minimum 1 letter, 1 digit and 1 special) is manually changed to remove any lower case characters.

=> Truncation is irrelevant and any client component converting a lower case "saved" password to UPPER CASE along the way, is doing the right thing.

The downward compatibility can then be disabled.

> > {Julius Bussche wrote:}

> > But my weapon of choice against this is still rfc/reject expiredpassword and now also icf/reject_expired_password. I find these parameters very efficient in keeping security up to scratch, if the implementation (or clean-up) was dont thoroughly.

>

> Do you really think that those two parameters can be set to non-default values in productive systems?

I was not suggesting default values. Though the thought did cross my mind, you can see that I agree with you.

> I have my (personal) doubts - they are main switches ("on" / "off") effecting the entire system.

Exactly that is what I like about them - they force you to use the correct user type, with all implications.

If the connections, user types and design of the application has been done carefully,

then one can switch these to keep it that way,

else keep cleaning up behind (probably human) mistakes.

endif

Cheers,

Julius

[WolfgangJanzen]

>

> What happens to the user/users with password that currently do NOT have any numeric value/values?  Do they get immediately prompted to change their password with numeric when "Login/min_password_digits to 1" is in effect or only when their password expired and prompted to change?

See: http://help.sap.com/saphelp_nw70/helpdata/en/22/41c43ac23cef2fe10000000a114084/content.htm

This can be controlled by profile parameter login/password_compliance_to_current_policy

Normally, the password rules are only checked when setting / changing a password.

But you can configure the system (by setting login/password_compliance_to_current_policy to value 1) to check every time a password is validated whether it's still compliant with the current password rule. By default, this does not happen.

Regards, Wolfgang

[Former Member]

>

> >

> > What happens to the user/users with password that currently do NOT have any numeric value/values?  Do they get immediately prompted to change their password with numeric when "Login/min_password_digits to 1" is in effect or only when their password expired and prompted to change?

>

> See: http://help.sap.com/saphelp_nw70/helpdata/en/22/41c43ac23cef2fe10000000a114084/content.htm

> This can be controlled by profile parameter login/password_compliance_to_current_policy

>

> Normally, the password rules are only checked when setting / changing a password.

> But you can configure the system (by setting login/password_compliance_to_current_policy to value 1) to check every time a password is validated whether it's still compliant with the current password rule. By default, this does not happen.

>

> Regards, Wolfgang

Thanks for all the info Wolfgang.

[WolfgangJanzen]

You are welcome. That's what this forum is for - to answer questions.

Cheers, Wolfgang