sap password must never be reused

[Former Member]

Hallo,

at our company we need when a user change his password at the Sap R/3 system,

that neither he or any other user can never reuse it .

The parameter login/password_history_size cannot cover the issue completely, because

a) has a limit of 100 entries

b) has impact only at the user that changed his password, while we need to

prevent all the users from reuse any old password set by any user.

Is there any suggestion ?

(Further details:

Our sap system version is R/3 ECC6 SR2.

The user logon into sap is done by Sapgui)

Thank you

[Former Member]

what is the frequency in which you change your passwords = what is the value in parameter login/password_expiration_time?

[Former Member]

@Mylène Dorias ,

the parameter login/password_expiration_time is set to 30

[Former Member]

Okay - if you change passwords every 30 days and have login/password_history_size set to 100 that makes for 100 month = almost 10 years. I don't believe that the average employee of your company stays on for 10 years --> that would be highly unusual.

But even if --> repeating a password after 10 years ...

For your second request, that the same password must never be used by another user ... there's no avoiding this! Like my co-poster pointed out, you can define 'forbidden' passwords (= passwords that nobody can use, not even once) - but that will never cover all the words and there's no preventing two users using the names of their wifes (assuming its the same name) at the same time!

[Former Member]

@Mylène,

the demand of preventing two users using the same password at the same time,

is asked by the auditing control, so we try to find a way to solve it .

Edited by: Nuno Fonseca on May 26, 2010 1:21 PM

[Former Member]

> @Mylène,
> 
> the demand of preventing two users using the same password at the same time,
> is asked by the auditing control, so we try to find a way to solve it .
> 
> Edited by: Nuno Fonseca on May 26, 2010 1:21 PM

This is not rational. I would not know of any software that manages that. You should talk to them again -->> maybe if you asked them how the system should react in case one user changes her/his password to something that another user already has ... should the system say: 'Sorry, chosen password already in use by User FonsecaNuno' ??? I think this requirement is nonsensical and I have checked with an auditor since my first post - she's sure there's a misunderstanding: no auditor (in this country) could ever request such a thing.

[jurjen_heeck]

> the demand of preventing two users using the same password at the same time,

> is asked by the auditing control, so we try to find a way to solve it .

In order to fullfill their requirement your system has to intercept and store plain text passwords entered by users to compare them. Talking about a security risk. I'd never log on to a system if I'd know my password was stored in plain text, let alone used for anything else than my authentication.

When I saw the first post in this thread I already considered the requirement to be a very strange one. Maybe you can invite your auditors onto this forum to have a discussion about it?

[Former Member]

@Jurjen Heeck ,

I agree that the option to store plain text passwords is unsecure, this what I already mentioned at

my previous reply for updating the table USR40.

[jurjen_heeck]

> I agree that the option to store plain text passwords is unsecure, this what I already mentioned at

> my previous reply for updating the table USR40.

In that case you're limited to comparing password hashes and that means you'll also intercept 'never used' passwords which accidentally make the same hash.

I'd still like to discuss the advantages of this requirement with your auditors. Are people trading used passwords in your company? Or posting them on a bulletin board? Why shouldn't I (unknowingly) choose a password that one of my hundreds of colleagues has chosen a year earlier? Just the fact that someone has already used a certain word or phrase doesn't immediately make it easy to guess.......

[Former Member]

Hi Nuno,

The control they are requesting is a poor one and introduces more risk (written down passwords etc) than it mitigates.

If you can provide the text of the following from your auditors then we can suggest appropriate controls to meet the objective.

1. Risk text

2. Control objective (it may be incorporated in the risk)

An example would be enforcing password complexity. 8 characters minimum, 2 letters, 2 numbers, 1 symbol (depends on your version of SAP). The chance of getting 2 people with the same password is negligible.

I also assume that your auditors have made this policy active on your network accounts. If this is the case then it will be cheaper to set up SSO based on network authentication than it will be to achieve their request in SAP.

[Former Member]

Special characters are very usefull, but I still think this is either the wording choice in "sharing the password = sharing the user ID itself, or... they completed GRC remediation phases using the "big hammer" or "out of the box compliance" approach and this is the response to "staying clean"...

Yes, SSO would help to hurt them more (access to mails, files, ESS, etc...).

I would also be interested in the background of why users are doing this, if that is what it is. This has mainstream trend potential for "bad" implementations.

Cheers,

Julius

[WolfgangJanzen]

 the demand of preventing two users using the same password at the same time,
 is asked by the auditing control, so we try to find a way to solve it .

That's something I dare to question (and I'm in this business for more than 10 years ...).

Take a closer look on the way the password history check is implemented:

1. only passwords which have been chosen by the user will be memorized in the password history

2. when an administrator sets a new password, there will be no lookup in the password history

(reason: the administrator should not be informed that this password was previously chosen by the user)

The proposal to reject a password which was previously chosen by any other user does not make any sense for multiple reasons:

1. at an early stage it will disclose the fact that (currently) at least one other user is using that particular password

2. at a later stage it will make it much harder for users to change their passwords since it "burns" password candidates

(the number of possible passwords is continuesly shrinking; that will make it easier for an attacker to guess passwords)

Best regards,

Wolfgang

[Former Member]

We shall see, I'm thinking more along the lines of an overzealous auditor but we need to know more. Maybe you can earn the right not to eat a piece of headwear Of course, with password complexity there is always the problem of too much complexity = post-it.

[WolfgangJanzen]

 I don't believe that the average employee of your company stays on for 10 years --> that would be highly unusual.

Well, fluctuation rate seems to be company / industry / country specific ...

[Former Member]

As remarked, a requirement that any two users should not have the same password seems silly. Any reasonable secured system I'd say should never store recoverable passwords and thus - as far as I know - any reasonable application uses results of one-way functions for storing passwords.

That means by design you cannot it's hard to recover the original password and thus to compare if two users have the same password (due to the added [salt|http://en.wikipedia.org/wiki/Salt_%28cryptography%29]). Of course you could try brute force or dictionary attacks to prove that two users have actually the same password (assuming that collisions are unlikely), but isn't that what you're actually trying to prevent make very difficult at the same time by enforcing complex passwords via your password rules?!

Alex wrote: Of course, with password complexity there is always the problem of too much complexity = post-it.

Thank you, I was really looking for some answer like this. Does anybody see much sense in a system that forces me to choose a reasonable complex password and then change it quite frequently?

Even with SSO I suspect that most of us still face enough standalone applications where we have some user ID and password. So I personally try to keep randomly generated passwords and encrypt them with a (very safe) master password, but that is awkward for some applications (e.g. think web mail, which you might want to access without having your password store at hand). Now most of the users I know use actually sticky notes or files stored with creative names like MyPasswords.txt...

I expected to see more challenges about the frequency of password changes (or for that matter even the requirement to ensure that one user doesn't repeat her/his passwords for quite some time), which in my opinion is a very good recipe for creating insecure passwords. I.e. most users I know react by creating simple password rules, like adding a counter or month/year addition as a prefix or postfix (and rules trying to prevent this often merely foster the sticky note password store).

I strongly believe in reasonable password policies (complex pass phrases without forced frequent changes) along with appropriate user security training (as any application can only enforce rules within its boundaries, which is pretty limited). Am I wrong?

Cheers, harald

[Former Member]

>

>Does anybody see much sense in a system that forces me to choose a reasonable complex password and then change it quite frequently?

Thank you for bringing this up. As a rule I avoid to disagree with Alex

From my experience (and I have been doing user-admin in SAP for 16 years now) - complex password rules can be applicated with reasonably 'educated' users - mostly in business functions, but never never try it somewhere in a production environment (where people wear protective clothes, e. g. leather/rubber gloves + masks) -->> this will lead to much indignation from both: users and their bosses, since this leads to a lot of password-resets due to typos etc. Same goes for warehouses, packing lines and so on.

So (again) I agree with harald and usually avoid the use of signs in passwords and set the change-frequency to something lower, let's say 90 days ...

[WolfgangJanzen]

> As remarked, a requirement that any two users should not have the same password seems silly. Any reasonable secured system I'd say should never store recoverable passwords and thus - as far as I know - any reasonable application uses results of one-way functions for storing passwords.

>

> That means by design you cannot it's hard to recover the original password and thus to compare if two users have the same password (due to the added [salt|http://en.wikipedia.org/wiki/Salt_%28cryptography%29]).

Well, the password history does also not store the plaintext passwords but only their hash values.

That's not the point. Theoretically it would be possible to implement a "global password history" (across all users, with "unlimited" capacity) - that would allow to implement such a feature (one-time usage of passwords) w/o the requirement to store the plaintext values. But since the entire feature does not make sense, I object to implement such stuff (reasons: see my previous posting).

>I.e. most users I know react by creating simple password rules, like adding a counter or month/year addition as a prefix or postfix (and rules trying to prevent this often merely foster the sticky note password store).

>

>I strongly believe in reasonable password policies (complex pass phrases without forced frequent changes) along with appropriate user security training (as any application can only enforce rules within its boundaries, which is pretty limited). Am I wrong?

I agree with you.

Human beings will always be more creative and thus able to trick-out password rules which tend to prevent the usage of "derived password" (see above: static part + variable part, e.g. month or counter). Systems should not fight against their users (and so shall system administrators not try to fight against their users, misusing the system as weapon). It's like road signs: as long as they are reasonable (and not too many) people are willing to pay respect. "The more the better" does not lead to good results (but only to an increase in ignoring the rules - only limited by the likelihood to get caught in the act). Well, suffering can be a motivator for invention ... (or as Konrad Zuse once said: in a perfect working environment you feel less urgency to change things and thus this is an innovation blocker. So, sometimes it's better to suffer from some deficiencies - since that will stimulate innovation).

Cheers, Wolfgang

[Former Member]

Theoretically it would be possible to implement a "global password history" (across all users, with "unlimited" capacity) - that would allow to implement such a feature (one-time usage of passwords) w/o the requirement to store the plaintext values.

True, I didn't think properly the first time (with current hardware, user numbers and stored passwords computation time is probably at worst in the range of a couple seconds). Thanks for correcting my silly mistake...

[Former Member]

>

> Alex wrote: Of course, with password complexity there is always the problem of too much complexity = post-it.
> 

> Thank you, I was really looking for some answer like this. Does anybody see much sense in a system that forces me to choose > a reasonable complex password and then change it quite frequently?

Finding that happy medium is the tricky one. Personally I agree with you that complexity of password increases security over regular resetting of passwords. Too complex + too frequent is counter productive.

Some interesting info here on password psychology: http://psychology.wichita.edu/surl/usabilitynews/81/Passwords.asp

[Former Member]

Perhaps the demand for the system side is that users do not agree on the client side to use the same password so that they can work "together".

SSO tends to sort that out... but the min diff per user will not nor a collection of "burnt" hashed (now without user name as attribute) as they are communicating the pwd. It is like hardcoding - there is no medication for it other than solving the root cause and monitoring it.

Ie. how was this found and why are they doing it?

As a pain measure, you could set the validity period of pwd's low with a higher minimum difference requirement as suggested by Mylene, but it will only piss them off and they will write they down even more because they cannot use simple conventions, even although the rules are simple.

What is the root cause? (is the counter question to provide an answer IMO).

Cheers,

Julius

[Former Member]

> Thank you for bringing this up. As a rule I avoid to disagree with Alex 
>

I enjoy our differences of opinion It is always nice to have good challenge to allow rethinking.

[panayotis_foudopoulos]

Dear Wolfgang,

Your answer has helped me absolutely to document why the direction proposed by the auditors was wrong. I totally agree with you. Finally we managed to bypass the issue by linking SAP password checking to our SSO system, which is going to be productive in two months. Therefore, we have convinced the auditors to wait for two months and not insist on their initial direction. Another participant in this thread has already suggested that we should link SAP to SSO and bypass the issue.

Just for the sake of history, I would like to document the reasoning of the auditors initially insisting on their strict password rule: In an insurance group, obliged to conform to the EU directive Solvency II by January 1st, 2012, anything that can be identified as a risk, whose mitigation cannot be documented, will incur an obligation to the insurance group to keep an extra reserve capital to face the risk if it occurs. Therefore, they tried to eliminate as many risks as possible. This answers a question asked by another member of this thread: "Are people publishing passwords or creating a fashion with paswords in the company?". The answer is "No, but we have to prove that, if ever this become a reality, there would be an automatic mechanism to prevent it.".

I would like to thank all of the participants in this list. Your contribution to the solution is highly appreciated. I consider this thread closed.

Best regards,

Panayotis E. Foudopoulos

SAP Manager

INTERAMERICAN GROUP

Member of EUREKO

[Former Member]

Hi

Not sure if any standard functionality in SAP will help as per your requirement. However here is my suggestion to you.

Password exception list is stored in table USR40. You can have a customized program to update this table whenever any user tries to change his/her password in SAP. This way user will get a exception error if any entry already exists in table USR40.

Thanks.

Anjan

[Former Member]

@anjanpandey

We thought also of this solution but the table USR40 will be updated with unencrypted text .

In this way the previous passwords will be displayed at USR40.

We do not want this for security reasons .

Maybe a solution can be a custom program that reads the table USRPWDHISTORY,

each time when a user changes his password and does not permit him to use

an entry saved in USRPWDHISTORY

[Former Member]

Possibly there is a misunderstanding here and the auditor meant that you should not share the same user ID. People do that by sharing the password.

You can disable the multi gui login parameter in rz10. Works for SAPGui login.

If your interpretation of what the auditor wants is correct, then the auditor is very strange...

Cheers,

Julius

[Former Member]

You can tell an auditor "no", you know. (Just be really nice about it.)

In my industry, we work with a lot of the national and international standards and I can't think off the top of my head, any standards that require this. I don't think this would even rise to a "no" due to system inherent weaknesses if you have all of your SAP parameters set properly.

An auditor should be looking at a specific risk, depending on that risk would determine the course of action. They should provide you with what the issue is rather than just stating that you have to set an unreasonable password policy.

Given if you could even do this on SAP, the costs associated could be prohibitive. Does this fall in line with your other password standards and pray you never implement SSO.

[Former Member]

In addition to being nice about it you can explain the consequences, if you are using application specific passwords.

That way you do not prevent yourself from implementing SSO and digging a deeper hole.

Perhaps Project Managers are the root cause problem. Possibly we are all a part of the problem...

Cheers,

Julius

Edited by: Julius Bussche on May 28, 2010 11:09 PM