Bringing back an old password validation rule

[Former Member]

Good afternoon

On our old 4.6C system, there was a password validation rule that stated the first three characters of the password cannot occur in the same order in the user ID. This rule was removed when we upgraded to ECC 6.0

While the users hated that rule, that rule was a SOX requirement at our company and I would like to have it back. Before I resort to programming user exits, is there a way to reactivate or at least simulate that rule? I cannot use USR40 because not only does it effect all users on the system, it only works on the second logon and not at validation time.

If programming user exits like EXIT_SAPLSUSF_001 is my only option, where can I get the password at logon time? From my understanding, SAP does not store this in a system value or even a global variable or table to prevent the recording of passwords. While this is a valid security reason, it would solve the resurrection of this password role through programming.

Please advise.

Kind Regards

Moggie

[Former Member]

I am wondering how your auditors noticed this??

Perhaps adding "*aud*" and "*audit*" to your USR40 table can solve it....?

Personally I think you and the SEC are barking up the wrong tree...

Just because SAP once enabled this feature (I had not even noticed yet that it was gone...)... does not mean that "hackable users" are less at risk...

If the 4th, 5th, 6th, 7th, 8th, 9th .... character is 456789? So what if the first 3 are "AUD" or "SAP"...?

The most effective protection you can take is to protect the password hashes and set carefull password rules and manage responsibility for generated passwords with saved logon data (your system users and rfc users for which no one (necessarily) needs to even know the password....)

Please ask your SoX auditors why they want this, and invite them to discuss it here if they have any doubts?

Should be interesting...

Julius

Edited by: Julius Bussche on Sep 9, 2008 7:29 AM

[Former Member]

Good afternoon Juliius, and thank you for your very prompt reply.

I found out about it during a July check of our passwords.

I found that a user ID of (for example) BSMITH would allow a password beginning with BSM on ECC 6.0. It did not allow this in the past because we tested this before in past audit checks.

Re: your example to put USR40 entries as a workaround, yes, it does work, but it has three drawbacks:

a) it affects all users, not just that one user

b) it must be added at the time the user ID is created

c) it could make the password creating process more difficult.

The only reason why I consider this password rule of great value is because the head office requires it to be of great value. They have some contract programmers looking into this as we speak, even though I was still asked to investigate it on my own time. Is it really important? I agree with you, it is not. But the fact someone high up requires this to be of value gives it importance enough to see if it can be brought back.

I'll keep looking into this. I thought I found something in a user function to retrieve the user security details: it does bring back the password, but it is scrambled and therefore not usable for additional rule checking.

[Bernhard_SAP]

Hi Moggie,

with the new password rules you can request much mor complex passwords from users than in the past. The limitiation for not repeating the 1. 3 characters is therefore only a very small loss for security.

If you ask for mixed case passwords with minimum length for instance of 20 with minimum 5 special characters and 5 numbers contained in it, repeating the 1st 3 characters of own user is limiting the security of that password only at a forgetable percentage......

What do you think about that?

If auditors still complain about pw-security, enlarge minimum password length to 40, but don't forget to send an e-mail with name,phonenumber and e-mail of that auditor to your users so that they know, to whom they can send their complaints aobut that....

b.rgds, Bernhard

[Former Member]

@ Moggie:

I agree with Bernhard, except slight deviations are:

> The limitiation for not repeating the 1. 3 characters is therefore only a very small loss for security.

Actually it is a very small gain, because it would mean that a brute force crack on the password would not need to "probe" any passwords starting with those 3 characters, in addition to 'SAP'.

> If you ask for mixed case passwords with minimum length for instance of 20 with minimum 5 special characters and 5 numbers contained in it, repeating the 1st 3 characters of own user is limiting the security of that password only at a forgetable percentage....

Actually, I don't know of anyone in the systems I am involved with who have even noticed this. So, which pin in the hay-stack should I try to "crack"?

I suppose that your auditors accept it that user DDIC has SAP_ALL though, because it has always been like that, right?

> What do you think about that?

Don't your managers think that opening an ability to probe a password (any password, any user, in cleartext) from a customer development is MUCH worse than the odd user BSMITH who might have the password 'BMS?????'?

Cheers,

Julius

[jurjen_heeck]

>

> Don't your managers think that opening an ability to probe a password (any password, any user, in cleartext) from a customer development is MUCH worse than the odd user BSMITH who might have the password 'BMS?????'?
> Julius

I think this is by far the best motivation to stay with the password rules SAP can enforce.

edit: noticed the usr40 solution had already passed by.

Edited by: Jurjen Heeck on Sep 9, 2008 3:55 PM

[Former Member]

Good afternoon.

To all the repliers, thank you for your comments so far. Even if they do not have a solution, it does give an idea of whether the request even has an easy solution and that is warmly appreciated.

To be clear on my request: I have no intention of introducing something that will introduce a security risk, including exposing the password in cleartext. I'd rather do it using the native mechanism of the password verification process.

To answer the question about DDIC and SAP: as with any company, the passwords for DDIC and SAP are known only to the BASIS administrator. If the passwords are cycled regularly, adhere to profile values in the instance that encourage strict password rules, and are kept private and secure, it is not a compliance issue to the auditors. This is the same reasoning for any user ID on SAP.

Pending the result of the contract programmer's research, placing a 3 character prefix of each new user ID in table USR40 is looking like the best option, though I do hate to place that kind of check for all user IDS when only one ID really needs that validation rule.

I will keep researching. If I find a solution, I will offer it here.

Kind Regards

Moggie

Edited by: Moggie on Sep 9, 2008 7:31 PM

Edited by: Moggie on Sep 9, 2008 7:35 PM

[Former Member]

Hi Moggie,

Good luck with it.

Personally I would prove to whoever created that control activity that the risk is mitigated in other better ways. Like much of SOX, very little is mandated and much is interpreted. It gives plenty of scope to both design efficient controls and also provide a veneer of control over flawed processes.

Cheers

Alex

[Former Member]

Hi Moggie,

> Pending the result of the contract programmer's research, placing a 3 character prefix of each new user ID in table USR40 is looking like the best option, though I do hate to place that kind of check for all user IDS when only one ID really needs that validation rule.

A problem with that will soon arise when you have for example 10000 user ID's and want the users to have the opportunity to use strong pass-phrases (not just pass-words). Additionally, the passwords are now case-sensitive but the user ID is not. A pass-phrase for users such as "The_D0g_&_Cat_r_FAT" would go undetected even if you have any "THERON's" in the system, but why should it not be allowed? It's a good one!

Users will soon notice that only passwords which are very cryptic can be used, and they will start writing them down on Post-It's.

While that is going on... the "real sinners" who dish out weak or the same initial / reset passwords (like "INIT1234") or administrate the users for whom passwords don't change (like "RFC4PROD") will not have any further "idiot-proof" controls as it is only a warning, which is intentional.

> If the passwords are cycled regularly, adhere to profile values in the instance that encourage strict password rules, and are kept private and secure, it is not a compliance issue to the auditors.

There you have it.

Tell them that. Even if they do use the first 3 bname characters as the first 3 CAPS_ON password characters, they won't be able to do it for long anyway if the password rules are appropriate...

Incase you are not aware of it, please also take a look at (and search here and SAP notes for) infos about instance parameter login/password_compliance_to_current_policy (e.g. SAP Note 862989). With appropriate minimum password rules (not overkilled - because the system must still be able to generate compliant wizard-passwords!), you will catch the bigger risks than any one 'BSM?????'s in there somewhere....

Cheers,

Julius

[Former Member]

Good morning Julius

Thank you for reminding me. I forgot the USR40 check is now case sensitive because of the upgrade to ECC 6.0. Oh well: back to the drawing board on that idea.

Moggie

[Former Member]

>

>  Oh well: back to the drawing board on that idea.

Or discard the old (assumptions) and user the new rules...

Cheers,

Julius