Secret protection RRS feed

  • Question

  • Hi,

    I have an application with a sensitive information stored in a sql table.

    The table has several columns and the sensitive info is not in clear. The Application stores the hash and not the data it self.

    I noticed in the application source code the algoritm and secret used to generate the hash.

    I also noticed the contractor developers have access to production DB replicas and the source code.

    I see it will be quite easy for a developer to generate hashes of random data and compare it with production hashes until they find I match. This way they can get the sensitive information quite easily (the sensitive information has fixed size) .

    What is the best way to protect this info?

    I'm planning to create a separate service with 2 operations( one to generate the hash to be persisted and one to verify the submitted secret and client ID  (i.e: generates a hash for the secret and compare it with the hash stored for that client ID  ) . This service source code could be accessible only to internal developers and not to contractors developers.

    Does it sounds good?

    I guess this problem is quite common to several requisites (forms based authentication, credit cards pins, etc). Are there any reference implementation to deal with this?

    Thank you so much,


    Wednesday, October 19, 2016 6:55 AM

All replies

  • This is actually a common practice for storing passwords and is secure if the developer is using a proper hash function. Here is a link that might be helpful to understand this practice: https://crackstation.net/hashing-security.htm

    It is not easy (impossible in practice) to reverse a good hash function. There are some known attacks on systems using hashes (search "Rainbow table", still you can use "salt" to guard against them), but if the hashed value is long and random enough, the chance of finding a value with the same hash is quite minimal.

    In your case, if the implementation is not using custom hash function, but rather SHA2/3 or some other good hashing algorithm (SHA1 is not considered safe anymore), you should not be concerned.

    If the stored values are really small and a brute force attack is possible, then you can implement the two functions, you are proposing. You can change the algorithm if you find it necessary, but never implement your own hashing function. If the stored information is short, I would advice to use some (static) random long "pepper" while creating the hashes.

    Remember - security through obscurity is frowned upon by every security expert. If the contractor developed the hashing properly, it is not that important if he had access to the DB.

    Monday, October 24, 2016 11:14 AM
  • Hi quattur,

    I'm not implementing the hashing function. I meant the code that is invoking the hashing function is visible to all developers. Every developer can see the "algorithm" being used because they see the primitive function in use(MD5, SHA1, SHA2, SHA3, SHA256, ...! In my case is System.Security.Cryptography.MD5CryptoServiceProvider) and they also can see the name of the web.config appSettings key where the salt is parametrized.

    In this case, the developers even know the salt used in production and they have access to the production database.

    You see ... the developers can "guess" the original data in production databases quite easily .... they all know the algorithm and also the salt.

    For now, I will just protect the web.config settings with aspnet_regiis to protect that info from any eventual external malicious user but in the future I would like to isolate that code on a separate service not available to contractor developers ... my intention is to protect the sensitive data even from developers ... makes sense?

    Monday, October 31, 2016 6:51 PM
  • Every developer can see the "algorithm" being used because they see the primitive function in use(MD5, SHA1, SHA2, SHA3, SHA256, ...! In my case is System.Security.Cryptography.MD5CryptoServiceProvider)...

    You should definitely change the hashing function if it is using MD5! If it makes sense to you, you can develop it as a service.

    ...my intention is to protect the sensitive data even from developers ... makes sense?

    That's the right way to go. You should make it so secure that even the person who has full access to the code and DB cannot guess the secret information. I believe that simply switching to SHA2/3 will suffice.

    If the software is publicly accessible, you can try to prevent login brute force attacks by using slow hashing function like Bcrypt (or hash several thousand times with a fast hashing function)

    Wednesday, November 2, 2016 9:47 AM
  • please work on oracle database server and please contact oracle in USA.
    Friday, February 10, 2017 4:56 AM