3

Passwords of end Users are stored in Database which is encrypted (using one way hash like MD5). Apart from me, there are 'other' people belonging to other teams who have access to Database which means access to schema and the particular table where passwords are stored. By other teams, I mean Database Administrators who will try to know purpose of a column & table for creating indexes, normalization etc. Other teams also include System Administrators who take backups regularly.

Even though am using one way hash, there are sites which will help in decryption of these passwords by matching against their Database.

So, its as good as exposing passwords of end users to 'other' people who are not intended to know. I cannot restrict view permissions of these tables to 'other' people who also have to work on these tables for some other reasons.

Its a question of ethics. But, an attacker doesn't have any ethics(that's what I believe).

What options do I have in this regard?

Vikas V
  • 693
  • 8
  • 12

7 Answers7

4

You can start of by using a stronger hashing mechanism like SHA-2 instead of MD5. Also you can make your hashed passwords' database more secure by using salted password hashing. I did a presentation in my class once about password hashing and I found this link and this one too to be very informative (apart from the Wikipedia). Hope this helps you too.

TheRookierLearner
  • 4,222
  • 8
  • 24
  • 28
  • 3
    Single iteration SHA-2 is a bad choice, even with a salt. Use bcrypt, PBKDF2 or scrypt. In principle you could use a homebrew iterated hashing scheme (like your second link), but I recommend using a standard password hash. – CodesInChaos Mar 01 '13 at 11:28
4
  1. Use a better hash. We have many questions related to this, but it boils down to bcrypt, PBKDF2 or scrypt with sufficient iterations(at least 10'000 for PBKDF2, equivalent values for the others) and a random salt. Single iteration SHA-2 is not acceptable, even with a salt.

  2. Encrypt the hash with a key that's stored in some form of config file. The exact choice depends on your platform, could be .net's encrypted web.config, or some kind of key store, or even just a normal textfile config.

    This helps against attackers that can view the database, but not that config file. But obviously it doesn't help against a full compromise.

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
3

Do you have the option of adding a salt to your passwords?

http://en.wikipedia.org/wiki/Salt_(cryptography)

I believe this would make those databases less effective for decrypting your hashes.

3

First "encrypting" and "hashing" are different things. The one way operation you describe is hashing.

The attack you describe sounds like a rainbow table attack. Generally you need to add a salt to your password hashed to prevent it, but if you're using a weak hashing function (like MD5), your scheme will still be vulnerable.

You need to be careful about what function you use to do this. It's easy to choose the wrong function and not gain a lot of security. Take a look at this question. The general idea is to use an adaptive hash function, like bcrypt, to take care of all these security details for you.

Community
  • 1
Oleksi
  • 4,809
  • 2
  • 19
  • 26
2

Depending on your database platform (and potentially extra licensing) there are mechanisms to prevent other users (even DBAs) from seeing particular columns. In Oracle, for example, it is called Virtual Private Database

http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm

Gary
  • 884
  • 7
  • 12
1

The use of salts, a key derivation function and a system-enforced password policy is advised.

  • Salts of a sufficient length will effectively prevent the use of rainbow tables and dictionary attacks
  • The use of a key derivation function like scrypt, bcrypt or PBKDF2 (see also) will slow down a possible brute force attack eventhough the salt may be known. This works because those key derivation functions are designed with the goal to intentionally run slow on CPUs, memory or both (scrypt). Note that the calculation time for each password can be customized by the use of parameters. This approach is highly preferred over the use of a standard hash function like MD5. By the way, MD5 is prone to collision attacks found by Boer, Bosselaers and Dobbertin and its use is not recommended.
  • Since passwords are one of the inputs of such a key derivation function, weak passwords may break your system's security. To encounter this, let your system check new passwords before storing them in the database. Strong passwords should have a min length, should contain upper- and lowercase (special) characters and numbers. Even if your database security policy cannot exclude your administrators from reading derived keys and their corresponding salt values, they wouldn't be able to make any use of this
Community
  • 1
  • 1
    1) A salt prevents rainbow tables, but does nothing at all against password guessing attacks, in particular it doesn't help at all against dictionary attacks. 2) Collision attacks against MD5 are irrelevant for password hashing 3) I believe the OP doesn't want to expose hashes to DB admins, so you didn't answer the question – CodesInChaos Mar 01 '13 at 18:20
  • @Martin a.k.a "user21360" - You probably logged into this site using a different google/yahoo/etc. account than your primary "Martin" account. Since you probably don't have enough rep to do so, I'll flag for Moderator attention to see if they can assist. – makerofthings7 Mar 01 '13 at 18:45
  • If somehow your post got lost in a shuffle, e-mail `team@stackexchange.com` with a link to this, as well as a link to the account it should be attributed to. We'll get it sorted out. – Tim Post Mar 01 '13 at 19:55
-1

@CodeInChaos: 1. You forgot dictionary-based rainbow tables. 2. The OP tells he uses MD5 for password hashing and I just advised him to not do that. OP doesn't want that administrators who have access to the database with the hash values can derive any password knowledge from that. What I meant by prone to collision attacks is more precisely known as pre-image resistance and thus recommending a more secure alternative in general is absolutely valid. Maybe my link is off-topic, though. 3. I believe the OP is looking for good answers in general. He also said that those administrators need to create backups from the full database. Which is not possible without read permissions. Nevertheless, when the salts and password inputs (3.) are long enough, even the knowledge of both doesn't disclose any password. That's why I recommended to use a good password policy.

@makerofthings7, Tom Post: Thank you for your help! Yes, I accidentally posted from a temporary account.

Martin Lundberg
  • 1
  • 1) A salt prevents multi-target attacks, but when attacking a single target you still can use dictionaries to come up with plausible passwords. 2) There is no practical first pre-image attack against MD5, and collision attacks don't matter at all. – CodesInChaos Mar 02 '13 at 11:24