Skip to Content

How your passwords are stored!

Most of us use numerous services available on the net such as mails, social networking services, and blogs. So it is obvious to have the question “Can a database administrator working on Facebook can get the password of my Facebook account if he wishes?”. A worthy question it is. But the answer is “No”. Your passwords are never stored as it is. (Well, I don’t know the policy of Facebook regarding this; I mention it just for an example).

When you enter your password for login it should be verified by the server, at the same time, the password should not be stored as it is in the databases. Thinking about encryption is a good option here, but where will you store the key then? “If key can be stored securely in the database, then we could’ve stored password in the same manner!”.

The solution is ‘Hashing’. What is a hash function? A hash function is one in which when you pass data, it will produce an output which looks almost random (but not exactly random, it is produced by some algorithm)

Let A be the data and h(n) be the hash function.

h(A) = X

where X is called the message digest of the data A.

h(n) does not have an inverse function. So given X alone, you cannot arrive at A using any algorithm.

i.e., h-1(X) does not exist.

At the same time, the algorithm should be as such that it does not produce the same message digest for two different messages which is impossible, so the probability of getting same message digest for two different messages should be minimum (Pigeon hole principle explains why it is impossible to avoid collision). Two different messages having a same message digest is called a collision. There are various standard hash functions such as MD2, MD4, MD5, SHA0, SHA1, SHA2 are available which has the above mentioned property. I am not a very good mathematician so it is inappropriate for me to explain more about the mathematical properties of hash functions further, so I stop myself here.

MD5(‘Hi’) = c1a5298f939e87e8f962a5edfc206918 (Hexadecimal representation)

MD5 is one of the most famous hash functions and it gives the above output for ‘Hi’.

Now how to achieve our target? i.e., saving our password in the database server in a way the DBA can’t get it.

We saw that hash is a one way function and no inverse function exists for a hash function. So if we store the message digest of our password in the database, no one can convert it back into password even if they had full access to the database. When we login, the password we enter is converted into message digest and it is compared with the message digest of our original password which is already stored at the database.

There are various function modules available in SAP to do hashing of character or any type of data.


The above function module can be used to hash passwords.

Hope this will be an useful information. For a more generalized info regarding this visit my blog.

– Fareez Ahamed K.N.

You must be Logged on to comment or reply to a post.
  • Well the admin can not see the password, but he can use your whatever-account. Its not necessary to know the password of someone to use his account. You just take the hashed value of the user and store this into a save area. Then you take your own hash value updating the users profile and cause you know your own password (hopefully) you are now able to log in to the users account. After doing this’n’that you restore the users hash value from the save area and everything looks good.

    And with rainbow tables its just a matter of time to find your password out of the hash value. The amount of time is just a question of salting the password. If there is no salt or you know the salt the password can be decrypted in hours if it is simple.

    • Thanks for your kind reply Rainer.

      I agree with you Rainer. Still this is a widely used concept. This works in an assumption that the admin doesn’t have updating rights. But in the method of salting I don’t understand something. When an admin is having access the database, then he has access to the salt also ( considering a salt like joined date, or DOB or last login ). So he can ultimately break the password. However I agree that salt adds a difficulty so that passwords cannot be obtained from rainbow tables.

      Moreover here I have used MD5 for hashing the password, where MD5 is a quick hash function which can be decoded quickly too. But some database systems like MySQL has proprietary hash functions for password which are not quick hash functions. They are designed especially for passwords thus providing more security. I don’t know whether SAP has got any such functions. So I used MD5 here.

      Thanks and regards

      • Just wanted to point out that still strong passwords are needed – even if they are stored as hash values only. In most cases, admins are trustworthy, butmore then once user datanases weres stolen. In order to make it difficult to retrieve the passwords they need to be salted AND the should not be simple.

        But on the other hand, the rules for passwords should not be so rigid – otherwise users are writing down the passwords and hide the postit under their keyboard. But thats another story.

        • Ya. You are right. I understand your point. Have to make more study on how to choose a salt. Thanks for your honest comments.


  • Hi,

    there are some errors in your blog.

    First, it would be nice to mention that you are talking about cryptographic hash functions, not just regular hash functions used in hash tables.

    It’s not precise to say that inversion function does not exist for a hash function. For any hash function you can define inverse function as: generate messages m0,m1… until you get a message for given hash. Obviously, this inverse function will work for any hash function but it is going to be really slow. The more precise definition is: it is infeasible to generate a message that has a given hash.

    MD2, MD4 and MD5 are not collision resistant. They are completely broken and there are well know collisions for them. Hence you should never use any of these functions in new projects. It’s true that there is no known attack on retrieving message from hash so you can still use MD5 for storing passwords but it’s not a good idea.

    SHA-0 should never be used. It has been withdrawn shortly after publication and replaced by SHA-1. I’ve never seen it used.

    SHA-1. There are known some weaknesses in this hash function but the collisions are not known yet. Hence I would not suggest using this SHA-1 in new projects if possible. You should try to use SHA-2.

    As it was already mentioned you forgot to mention adding salt. Adding salt prevents attacker from per-calculating table with hashes for a set of messages. For example the attacker could generate table with hashes for all passwords using only letter and numbers with length from 3 to 8 characters. Adding salt to message before hashing will make this table useless.

    There is also one disadvantage for using hash functions for storing passwords. The hash functions are optimized for speed. Hence also attacker can try more messages in less time when he tries to use dictionary attack. As a solution for this issue you can use key derivation functions instead of hash functions. The good examples are scrypt and PBKDF2.


    • Hi Martin,

      First of all I would like to thank you all my heart for giving me such a good explanation. I accept all your points. I wasn’t aware of the importance of salt when I wrote this article. But now I really do.

      And regarding which hash function to use, I use MD5 here as I couldn’t find the function module for any other better hash functions. When I first learnt this methodology, I tried it in MySQL which has specially designed cryptographic hash function for password (PASSWORD()) which is not a quick hash function and tried some attacks (look at my personal blog). But I didn’t use salt there too which is a blunder mistake.

      Anyway, I learnt a lot from your comment on my work. I thank you once again heartily.



  • Hi Fareez,

    I tried the FM MD5_CALCULATE_HASH_FOR_CHAR  with various strings in DATA parameter with LENGTH =  1 or 2 ….

    but always got the same HASH  which is  D41D8CD98F00B204E9800998ECF8427E

    Am I missing something ??  Please guide.

    Many Thanks


    • Hi Jitendra,

      The hash that is generated in your code is for empty string. You might have made some error in passing your string I suppose. Length is an optional parameter. You need not give it while calling the FM, it will automatically calculate the length.



  • Hi Fareez,

    If I do NOT pass  the length parameter , then it throws the exception NO_DATA .

    I tried it by passing the different-different strings, but it returns the same HASH.

    Many Thanks,


    • Hi Jitendra,

      For me its working fine without the length parameter. My code is just the following

             DATA                 = LV_PASSWORD

             HASH                 = STRU-PASSHS.

      In the above program the input I’m giving is of domain CHAR32.