Auditing weak passwords

[Former Member]

Hello all,

Does anyone know of a way to audit passwords (or weak passwords) in SAP R/3? I know it is possible to retrieve the hashed version of the password through table USR02 but this is only a 'fingerprint' of their password and it does not give any indication of the type of passwords that the users are using.

Any ideas welcome...

Regards,

[Former Member]

I would just enforce mandatory strong passwords and suspend accounts that have not logged in in over 45 days.

I know this might be a culture shock for some users but, we have to protect our network.

[Former Member]

Hi,

I understand you 100% but we are trying to be more pro-active as most users are not bothered with using complex passwords. We would like to audit passwords in our system, identify the weak ones and then possibly contact the user and inform them of our policies with security around passwords.

Thanks,

[Former Member]

Hi John,

If you set the "appropriate" level of password complexity and validity, and audit them (or try to...) that they are actually changing their passwords, then they would need to have any future password which complies with these rules, assumg you get them to change it at least once.

If you are aware of any specific weak passwords (like Summer06 or Pa$woRd1), then you can use table USR40 to prevent or at least warn them at the time of changing the password.

For the last bit, you can use an optional part of the Security Optimization Services to get the information about the passwords (I would assume that this is the only legal way of doing it). I am not sure whether it is still available with the latest password hashing mechanisms.

I would be interested in the reasoning of why you would want to do such a thing to your users (see their plain text passwords) if you have set the appropriate rules? I have never understood the reasoning behind making the lives of plebian end users with very limited access (like me) difficult with overly complicated passwords, and even less do I understand why "super users" put themselves at risk by making ways available to read passwords in plain text?

I have often thought about this and I cannot think of one beneficial reason for doing it which does not bring 10 fold the amount of risk with it.

Am I missing something?

Have a nice weekend!

Julius

[WolfgangJanzen]

Hi "<i>John Lennon</i>",

trying to crack a user's password (in order to be able to tell whether it is a primitive password or not) is close to be considered an (illegal) attack. Your incentive might be honorable but not everybody might agree with that approach.

Most users react quite unpleasant if being told that they are using a weak password - and they assume that the messenger is aware of their password (which most people consider a "secret"). Well, most people do not like someone who discloses secrets ...

Just my 5 cents ...

[Former Member]

Yes, the password should be the user secret (at most shared with the admin for technical users) and vendors should also strive to ensure this.

I would think that this is also a legal requirement in many countries.

[Former Member]

You can prevent them from giving themselves weak passwords. I am not sure whether detecting weak passwords

is possible.

you can increase the length of passwords, you can maintain USR40 with weaker passwords. you can do lot more

for prevention with the Login/.... Profile parametrs.

This will help you.

http://help.sap.com/saphelp_erp2005vp/helpdata/en/22/41c43ac23cef2fe10000000a114084/frameset.htm

[tim_alsop]

John,

Many companies who recognise this kind of problem use SNC for authentication to SAP, and when this is combined with Active Directory user authentication the problem of weak passwords in SAP are gone, since the SAP user passwords are deactivated, and not used anymore.

In case you are not familiar with how this works, essentially when a user logs onto their Windows workstation and then run SAPgui to logon to a SAP application, the Kerberos credentials issued by Active Directory during their workstation logon are used to authenticate them to SAP. This means that the only password the user needs to remember is their Active Directory domain logon, which they need every day when they logon to their workstation in the morning. Since they only have this password to remember, it can be made stronger than normal and controlled using Active Directory password policy management. I guess you are already enforcing strong passwords for workstation domain account logon ?

I hope this helps ?

Thanks,

Tim

[WolfgangJanzen]

The usage of weak passwords should be prevented by enforcing a proper password policy (of course you have to find the appropriete level of strictness; if you are too strict and enforce passwords that are hard to memorize a high number of users tend to write them down ...).

Notice: as of NW2004s (ABAP 7.0) you can instruct the system to enforce the password policy compliance - each time a password is verified for correctness it will then also be verified for compliance with the current password rules. By this, you can instruct the system to force only those users to change their password whose password is considered "weak" (i.e. it violates the current password policy).

[Former Member]

SAP password methodology uses one way hash and these values are incompatible in reverse way.

there is no way you can audit the existing passwords.

but you can prevent users assigning themselves weaker passwords.

From 6.10(Web AS) SAP gives a function module PASSWORD_FORMAL_CHECK which checks whether the password

is compliant with current password rules.

and these password rules can be changed according to your requirement with the help of the Profile parameters

which I shown in the link above.

inclusion of special characters and digits increases your level of security on passwords. it gives hard time for keyloggers,password sniffers,etc at a system level.

and you can't save password sniffing at network level unless you are using SNC or any other third party security systems because passwords are comunicated only by getting them compressed but not encrypted.

main things to look after passwords are

profile parameters,USR40 patterns, SNC or any third party tools which can provide security at network level.

[tim_alsop]

John,

Do you need any more help with this ? if not, can you assign points to answers provided so far ?

Thanks,

Tim