Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Dictionary contents in USR40

Former Member
0 Kudos

Hi

I'm reviewing a document regarding security requirements and it's telling me that USR40 "MUST" be populated with the entire dictionary!

This seems a little excessive... we currently have several common word and pattern definitions in there.

Firstly, could you download an entire dictionary into the table? Where would you get it from/how would you do this/how large would it be?

Could it have performance problems too having to check the entire dictionary?

Thanks!

Ross

1 ACCEPTED SOLUTION

martin_voros
Active Contributor
0 Kudos

Hi,

IMO table USR40 is not very useful anymore. Users got used to passwords where they need to have at least one digit and one special character. If you force this policy than you already excluded all words from any dictionary and you don't have to maintain any table. Also as Julius mentioned adding salt to hash is a good idea to prevent using rainbow tables.

Cheers

8 REPLIES 8

Former Member
0 Kudos

Hi Ross,

Thats absolute rubbish to populate the entire dictionary into USR40

Just enter the most commonly used words, should be around 1000 words max?

Regards,

Laxman

Former Member
0 Kudos

I agree with Laxman.

Add 1 or 2 digits and special characters to the password roles, set the downward compatibility to 0 and take a look at the "charset" param to add a salt to the hashes... and you are done IMO.

Cheers,

Julius

martin_voros
Active Contributor
0 Kudos

Hi,

IMO table USR40 is not very useful anymore. Users got used to passwords where they need to have at least one digit and one special character. If you force this policy than you already excluded all words from any dictionary and you don't have to maintain any table. Also as Julius mentioned adding salt to hash is a good idea to prevent using rainbow tables.

Cheers

0 Kudos

If the password policy is 90 days for those still using passwords, then I normally add the SIDs and the seasons and the months in Swahili, Zulu, Mathabele, English, German, Italian, Spanish, Portugese, French, Dutch, Flemish and Schweizer Mundart (basically all localizations of the Tutu and Latin languages in now modern rurul areas with access to the internet

The main pest with adding all words of all language dependent dictionaries to USR40 is that at logon time it does not tell you which part of the password is not allowed, so you need to guess!

I am fairly certain that the word "I" (as in me...) could create a considerable amount of havok.... Also when SMS-speak hits mainstream Oxford dictionary then u must b carefull bcz da shite is gonna hit da fan bro....

Now that SAP supports 40 character long case sensitive passwords, I prefer to think of it as a pass phrase and not a pass word.

Cheers,

Julius

0 Kudos

A few years ago (in a previous life ) we went to case sensitive long string and some joker decided that my password would be Mary had a little lamb.

Didn't tell me about the . at the end....

0 Kudos

Knowing that"." and the rest of the Oxford dictionary is not allowed would make my little program run faster...

The layout of the keyboard becomes a good template to use. The "silos" in the password tend toward being 4 characters long with the 5th 6th and 7th characters being digits.

Just guessing

Cheers,

Julius

0 Kudos

Thanks all... some great info there (some of it quite amusing)