Skip to Content

Secretum secretorum

I’ve started reading Secretum by Monaldi & Sorti. It is somewhat heavier than the Dan Brown books. Monaldi & Sorti are able to create high calibre thrillers which manage to remain lighter reading than Umberto Eco. Don’t get me wrong. I don’t look down my (considerable) nose at books by Dan Brown. I just wanted to challenge myself and see if I could read heavier books. It’s the same with TV. I am -or better was- a big fan of the 24 series. I found the real time concept rather innovative for a TV series while it was already done in movies like Nick of Time . For the laymen, in a real time movie each minute/hour in a movie corresponds with “reality”. If the 90 minutes movie scenario starts at 1:00 PM for example, it’ll end at 2:30 PM. Sure, the commercial breaks in 24 are a spoil-sport and the realism is hard to find, but it was still interesting. People seemed to love it and they’re currently broadcasting a fourth season. Sadly, the scenario doesn’t follow the real time principle that strictly anymore and takes too many wide bends to fit things into the scenario. It’s clear that the formula is bleeding dry. I might have better been off following Lost , but someone told me that one needs to follow every second in order to know what’s happening. It’s a pity that I knew that too late. No need to despair though. I’m eagerly waiting for the second season of Carnivàle to be broadcast. To my mind it’s a Monaldi and Sorti type of TV series, but it isn’t as incomprehensible as the second part of Twin Peaks .

Let’s get back to Secretum. It’s the second part of a series of seven books, based on actual facts and figures. The story takes place in Rome in the year 1700, when many pilgrims are heading to the city to celebrate the holy year. Pope Innocentius XII is dying and a lot of politicians, diplomats, cardinals and other power-mad people are negotiating the next conclave in the highest secrecy.


Insecure passwords

That brings me “seamlessly” (sic.) to the real subject of this web log: secrecy/security in web applications. I’m currently working on a project where users need to create and maintain their own private data. As such there’s nothing special about that, but the vicious thing is that the application is open to everybody and is therefore not restricted to only personnel and students. This has as an implication that the ”users” aren’t necessarily defined as users in our SAP and/or LDAP system. Our first idea was to let the user choose their own userid/password but a test with a test panel revealed that this wasn’t a safe approach. People tended to choose the least secure userids and, most importantly, more than insecure passwords. In fact two people choose the same userid and password at the same time without knowing. That made the application rather vulnerable, so we decided on another tack and to fob the secure generated userids/password on the users. But before I elaborate on how we did this, I want to discuss what secure -also called strong- passwords are all about. There are some rules of thumb to follow:

  1. don’t use your name or a name of a relative or a pet
  2. don’t use the name of your favourite food, TV series, movie or pop star
  3. don’t use any ID, driver license, license plate number, etc.
  4. don’t use words you’ll find in a reference book
  5. don’t use the same password twice. Each login needs a different password
  6. don’t write passwords down

What should it be then? Well, choose a password with at least 8 (alpha)numeric case sensitive characters. If allowed, consider using punctuation. OK, is SdN102005 a good password for logging into the SDN site? Not at all, for several reasons. Since you’re logging into SDN, the connection is made quickly. Adding the date is the common pitfall when people need to choose a new password every month. But how does one choose a good password? A good thing is to use a password generator. They generate passwords like ç!e’Jd1=
Yeah sure! One can’t possibly remember that, especially if you have to pick another password for each login, and you can’t write the password down… Yep, you’ve got a problem. That is indeed true.


Alzheimer tricks

These are some hints/tips on how to make life easier on that point and how to make passwords easier to remember without compromising too much on the strength of the passwords:

  1. Use the phonetic version of words/phrases. An example is my domain name: Why idizaai? “Man of thousand faces … every one the same”, said René Artois in the BBC series ‘Allo, ‘Allo! . He was referring to a character called Roger Leclerc who always disguised himself in a recognizable manner, pulled his glasses away and said in Franglais: “It is I, Leclerc”. Wait a minute, shouldn’t a password be at least 8 long, contain (alpha)numeric case sensitive characters and preferably not refer to a TV-series? The latter is true depending on the popularity of it. I personally believe that “I’ll be back” or “Beam me up Scotty”, are more widely known than “It is I, Leclerc”. However you’re right that the password is too short and should be case sensitive. Thus IdiZaAiL.
  2. It still misses some numeric characters though. No dates are allowed therefore one needs to find another way to include them. English lends itself easily to letter to number substitution. The best known are:
    You -> U
    Too -> 2
    For -> 4

    I guess that the chatting and SMS generation knows more about it than me. More on that later. Back to our password. U nfortunately there aren’t letters suitable for replacement.
  3. So we need to find another way. Replacement by resemblance. It’s best explained with these examples:
    o -> 0
    i -> 1
    e -> 3

    If we apply this to our password, it becomes: Id1zaA1L
  4. An alternative is to work with sentences and only retain the first characters of each word. The chatters amongst you know what I mean:
    in my humble opinion -> imho
    rolling on the floor laughing -> rofl
    if the monitor only had eyes -> itmohe
    Thus, while keeping the other rules in mind, we could come up with this:
    The SAP Developer Network is unique among developer communities -> tSdN1uAdC
  5. Mirror writing a.k.a. writing in reverse. Leonardo da Vinci was a master in it and used it frequently in his famous notebook. If we apply this to our “The SAP Developer Network is unique among developer communities”, it becomes “seitinummoc repoleved gnoma euqinu si krowten repoleved pas eht” thus sRg3skrP3. If that’s too difficult, you can also reverse the password instead of the sentence.
    The SAP Developer Network is unique among developer communities -> tSdN1uAdC -> CdAu1NdSt


The ABAP way

This is all very nice, but how does one fit all this into an (ABAP) program? Sure, one can fit these replacement, first letter and mirroring techniques into a program, however it needs to be fed somehow. This needs to be done by a human and that –with all due respect – is the weakest link. Our test earlier with the panel proved this. We therefore needed a program to generate passwords. I was under the illusion that SAP would have standard function modules for that. After all there is a standard password wizard available in trx SU01. Maybe I didn’t search well enough, but I didn’t find anything on this. Even this Attention Security Administrators! New password rules are on their way! on new password rules didn’t unveil anything I could use.

So I decided to write my own password generator. It’s very easy to do. All you need to do is to choose an (alpha)numeric character at random. I deliberately left out the punctuation and special characters like &éèç§ in order to prevent trouble as problems can occur with different keyboard layouts, codepages which are not Unicode, etc. People will already have their hands full trying to remember the generated passwords with only case sensitive (alpha)numeric characters anyway.

There are two possible approaches:

  • make a string with all the possible characters and let the generator pick a character X times at random and concatenate it to the password. The string would look like
    ABCDEFGHIJKMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789. If you need it to be even more random you could mix up the characters.
  • let the random generator pick the ASCII value of an alphanumeric value and concatenate it to the password. The values are:
    a-z: 97-122
    A-Z: 65-90
    0-9: 48-57
    In order to make this even more random an extra random generator for picking out the type of character is needed.

I decided to plump for the second method, since I found it more challenging to code. Why challenging? Well, when it comes to this kind of coding, one notices that ABAP is still tightly connected to COBOL and still doesn’t provide the kind of things which have already been available in languages such as PHP, Coldfusion, Perl, etc. for a long time now. Let’s face it, how long did we have to wait to have a decent editor and things like regular expressions? Don’t get me wrong. I find ABAP a good language to code. In fact I will show in a later article or web log that I actually prefer using ABAP for achieving things instead of using those things which are hyped as so called portable. ABAP was far more suitable than that language. No Java lovers, hold your horses, I’m not going to be shooting in your direction.



As said it wasn’t as easy as I had thought. Whereas one can say in VB X=chr(Y), where X is a char1 and Y an integer, one doesn’t have such a capability in ABAP. One needs to make do with hexadecimal codes. Since the arrival of Unicode concatenating into a string is not getting any simpler. The solution to this is to use type X and XSTRING. One can put a decimal value in an X type field. E.g. when I put 65 in an X field, it’ll become 41. Concatenating into a XSTRING is done via:



Once that’s sorted out one needs to write the randomizer. Luckily it’s provided in the WebAS, but it isn’t well documented though (that’s diplomatically put). It boils down to:

seed = cl_abap_random=>seed( ).
prngb = cl_abap_random_int=>create( seed = seed min = 48 max = 57 ).

One can opt to use the same seed for all randomizers, but I found it more random to use a different seed for each of the three character types and for the type picker itself, thus giving a total of four. If you find this overkill, one will still do fine.

Picking a value from that randomizer is done via:

random = prnga->get_next( ).


One needs to do this X times depending on the size of the password. It’s best to have this X as an import parameter, but I wouldn’t advise allowing any values lower than eight. It’s up to you to restrict the possible values.
Finally, one needs to convert the XSTRING to STRING, which is not as simple as STRING = XSTRING, as one would expect. Thanks to Brians BSP Trouble Shooting: Frequently Asked (Short) Questions , I discovered the classes CL_ABAP_CONV_IN_CE and CL_ABAP_CONV_OUT_CE to get this done.

conv = cl_abap_conv_in_ce=>create( input = xpwd ).
conv->read( IMPORTING data = pwd ).


Et voilà. It’s done. It looks easy at first sight, which it is in the end, but one has to cross a few hurdles in order to get there. The whole code can be downloaded at this location . Now you can generate passwords which are a bit safer than those that the average human mind can think of.

g2GcUlgLe1 (Got to go. See you later. Good luck, everyone)

You must be Logged on to comment or reply to a post.
  • I got link to your article with today’s SDN newsletter and I’d like to respond.

    While you’re right about importance of good password I disagree with you regarding criteria of strong password.

    You’re confusing between password breaking practices here: password guessing (either by humans or machine) and password hash cracking (usually by machine). The method of password generation you suggest is good only against one (relatively rare) kind of attack: guessing by humans. It doesn’t provide any extra defense against machine-driven attack.

    Paraphrasing well known saying, men created different passwords, but 3GHz CPU made them all weak. Considering brute force machine attack, there is no any advantage of allegedly strong passwords like “Id1zaA1L” or “tSdN1uAdC” over naïve passwords like “Kitty” or “Alex123”. They all will be cracked within second by modern PC. These “strong” passwords are actually weaker than naïve ones considering human factor! They’re hard to remember and that’s why are more likely to be written down by humans, less likely to be changed by humans and therefore are more susceptible to theft by other humans.

    Good passwords are not cumbersome meaningless words with numbers and letters, but “pass phrases”: long sequences of regular words, possible in Unicode and numbers. From attacker’s point of view it’s just long password with crack time approaching infinity. Pass phrases tend to be more personal and therefore more unique. For example, “My Рене is mischievous kitty!..” is hard as hell to break even for computer:

    – it’s 31 characters long (no one in its right mind will be able to remember “Id1zaA1L”-style password longer than 10 characters);
    – it contains several Unicode characters (René is written in Russian);
    – it has punctuation marks.

    With all that, this password is very unique and personal and extremely easy to remember by humans.

    Here’s much more about strong passwords for interested readers:

    “The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3”

    “The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3”

    “The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3”

    “Selecting Secure Passwords”


      • I can’t tell you because I’m not working at NetWeaver or ERP department.

        Yes, I read Gerlinde’s blog, too (via your article). Lengthening password up to 40 symbols is good. Whether it supports Unicode is open question. Personally, I think that Unicode capability in password system is a must in year 2005. As well as space characters and punctuation marks.


      • Yes, it does (as long as the system supports Unicode).

        But you don’t have to wait for that.
        As of 6.20 the system supports Unicode.
        And applying the correction of note 874738 already allows you to use unicode characters.

        In non-unicode systems you are restricted to the characters that are contained in the codepage that is used on the logon screen (=> system language locale settings).


  • Have a kind look on function module SUSR_GENERATE_PASSWORD (=> SAP note 832661) respectively RSEC_GENERATE_PASSWORD (for older releases).

    Using function module RSEC_GENERATE_PASSWORD make sure that you do not provide any import parameter (only provide export parameter PASSWORD).

    Cheers, Wolfgang