ABAP: Securitysettings for passwords

[Former Member]

Hello,

we have an abap system (ERP2005) on SP12. We have to change the security settings for passwords.

We have the following two requirements from AUDIT.

a) A user is not allowed to have his userid as an password.

b) A password should not have two identical characters togehter. Example: mondayaaa is not allowed.

Are these rules possible to implent?

Regards,

Alexander

[Former Member]

Hello,

we have an abap system (ERP2005) on SP12. We have to change the security settings for passwords.

We have the following two requirements from AUDIT.

a) A user is not allowed to have his userid as an password.

b) A password should not have two identical characters togehter. Example: mondayaaa is not allowed.

Are these rules possible to implent?

As far as I am aware they are not possible to implement via parameters.

You could maintain some disallowed lists in table USR40 e.g.

*aa*
*bb*

etc

You could also maintain userID's in there too which would stop users being able to select them.

Alternatively you could look at some of the other params to enforce complexity and such as:

login/min_password_diff

login/min_password_digits

login/min_password_letters

login/min_password_lng

login/min_password_specials

though you may need to check to see if they are available in your release

Edited by: Alex Ayers on Feb 20, 2008 11:10 AM

[jurjen_heeck]

Alex,

Good idea, entering

*aa*, *bb*

etc into USR40! Very creative. Wish I thought of that.

Userids could be entered in USR40 by some custom report/batchjob. That could be so simple (start by checking if any new users have been created since last run) that it could run every five mins without performance impact.

I was unpleasantly surprised when I discovered that using your uid as a password isn't prohibited by default. Maybe a development request, to have USR40 accept system variables like sy_uname. Besides that I think the use for the USR40 table is limited as the only error message triggered is:"Password is in exception table" which is not true if only a part of the password does not adhere to rules. You'ld want a little more informative messages to guide the user towards creating an allowed password.

As for the password rules in general it's just a matter of stacking enough on top of each other until you force the user to write down their passwords because they cannot be memorized anymore.

[Former Member]

>

> I was unpleasantly surprised when I discovered that using your uid as a password isn't prohibited by default.

Likewise, for some reason I was convinced that pwd NE sy-uname but when I tried it I go the same result as you.

Maybe it was a feature on older versions? it would make sense, as would your idea about having sy-uname as a variable in USR40

[WolfgangJanzen]

>

> >

> > I was unpleasantly surprised when I discovered that using your uid as a password isn't prohibited by default.

>

> Likewise, for some reason I was convinced that pwd NE sy-uname but when I tried it I go the same result as you.

> Maybe it was a feature on older versions?

Yes, it was (but in some weird way: "The first 3 characters of the password must not occur (as substring) in the userID").

Unfortenately, now (as of R/3 4.6C) there's not only the ability to logon by userID and password - but also with aliasname and password (at least when using the so-called "internet users"). But in such a case, it does not make any sense to check on the userID. So, that password rule (see above) was dropped with 6.10. As a kind of compensation, a whole bunch of additional password rules (e.g. "minimum number of digits", etc.) have been implemented.

>

>it would make sense, as would your idea about having sy-uname as a variable in USR40

No, I'm sorry. But that would go far beyond the intention of USR40. That table is supposed to contain patterns of "forbidden" passwords. I dislike the idea of supporting variables or regular expressions. That only leads to situations where it has become impossible to predict the system behavior: which kind of passwords are accepted by the system and which are rejected. If you cannot answer that question straight away, then it's hard to judge the quality of your password policy.

But if you have other good ideas of password rules - which are likely to be supported by other fellows - feel free to submit a development request. Maybe it would also make sense to discuss this in SDN (in order to find out whether there is consensus on certain proposed password rules - or not).

[tim_alsop]

Alexander,

Many companies that have needs like this, and cannot implement thier password policy rules in SAP software decide to implement external authentication, e.g. using SNC for SAP GUI. With this, the password policy can be controlled and managed in Active Directory (when used as a central authentication server for workstation logon and SAP logon) and the user will be able to use the same userid and password and same password policy for when they logon to Windows as when they get authenticated to SAP systems.

Thanks,

Tim