Password control

[Former Member]

Could anybody tell me if there is a way of restricting passwords not to be the same as the user id. I want to ensure that from the moment i set up a password the user can never change it to be the same as the user id.

I can not see that any parmeter exists in 'RSPARAM'.

Fauiling that is there a report that can be run to list the user id's that has the same password set as the user id?

Thanks in advance

[Former Member]

Hi,

This was dropped from more recent versions of SAP & there is nothing as standard to replace it. The level of password complexity that can be achieved using current password parameters should let you enforce a policy which prevents users from being able to create pass = UserID.

I am also not aware of any method by which you could compare password hashes to identify pass = UserID

[jurjen_heeck]

> I am also not aware of any method by which you could compare password hashes to identify pass = UserID

As far as I know you can never be sure. Different password may well generate identical hashes (at least theoretically) so the risk of false accusations is always around the corner.....

Jurjen

[martin_voros]

Honestly, the probability is so low that I would not be afraid to hash user name and check if it is same as hash stored in DB (don't forget about salt). If you find somebody who tells you that his password is not his user name and hashes are same than there is much bigger problem with that hashing function.

Cheers

[Former Member]

I like your thinking

Actually the call stack of the hashing function is protected, so it knows the allowed programs which may hash a string using it. This means you cannot write your own program to perform the check you have described, even when not using a salt. You would have to mimic a permitted SAP standard program by renaming your own source. After doing that you can typically re-format the server and re-install the SAP system again so obviously not an option compared to the risk... !

One special character and one digit to the minimum rules would exclude all normal naming conventions, leaving only very exotic exceptions like "Obi-1-kenobi" etc. I would go that route.

Cheers,

Julius

[martin_voros]

There is a patch for john the ripper to support sap. But i am not sure which formats are supported. So creating custom dictionary from user names plus dumping hashes should work. Though it does not sound right to dump hashes to a file and move it to another system (i assume that you don't want to install tool for cracking passwords on your application server).

Cheers

[Former Member]

AFAIK the salt is a logical system dependent key and algorithm used by XXPASS & Co., so you would need to hack your own local hashes with local programs (in production).

This would probably cause a lockout immediately...

However there are some dirty tricks. For example there is a logon exit from which you could prompt the user for a password change, and then throw an error to the user if sy-uname (6) = a pwd pattern.

That they are infact already logged on will sooner or later dawn upon them...

You can check for this vulnerability if there is a function group called ZAW0 in your SAP system or the function group SUTL has been modified. There are some consultants / developers from SAP who deliver such tools as a private hobby business of sorts (Z-programs attached to SAP Business Objects "Knowledge Bases". It is however not official SAP source.)

If you would like more details, then please let me know. It is an ancient problem which customers should know about.

Cheers,

Julius

[martin_voros]

Here is a crazy idea. You can define new RFC transaction that points to itself (same as local). The use to FMs RFC_MODIFY_R3_DESTINATION and RFC_READ_R3_DESTINATION to read and modify username/password used for RFc connection. The n try to call some basic RFC enabled FMs. If call is successful then user name and password are correct. The only issue is that it will be noticed and invalid attempt in security logs. So there is always a dirty workaround

Cheers

[Former Member]

Thanks for your prompt replies.