Solved

Posted on 2012-08-26
Medium Priority
1,999 Views
Hi Experts
I have a table with the following columns
The password will be stored encrypted with the 3DES algorithm (using the value of the key)
the key must be stored encrypted, they used a master key.
My question is, with which I can encrypt the key algorithm considering he used a master key
0
Question by:enrique_aeo
• 4
• 2
• 2
• +5

LVL 84

Assisted Solution

David Johnson, CD, MVP earned 336 total points
ID: 38334527
You don't have the master key?

My question is, with which I can encrypt the key algorithm considering he used a master key

Don't you mean decrypt?  If you don't have the master key then you have to brute-force it (try all possible values)

This is not a hacker forum site btw
0

Author Comment

ID: 38334665
the table does not exist, I'm at the stage of analysis

I'm not a hacker, I'm just making a proposal. I'm not sure that is a "master key", that's why I ask for your help
0

LVL 75

Expert Comment

ID: 38334909
Please restate your question as I agree with ve3ofa that it is unclear whether you are asking to encrypt information or decrypt information.

In any event, if data is encrypted with a master key, then you will need that master key to decrypt it. You would be far better off playing the lottery of your region than you would be trying to brute-force a decryption of those values   : )
0

LVL 84

Expert Comment

ID: 38335182
A proposal for what?

What do you have and what do you want to do with what you have?
0

Author Comment

ID: 38339335
is what I want to do.
table 2 : with the following columns: id_application, master_key

Then
key: which recommend  algorithm to encrypt this column whereas I use master_key column of table 2
0

LVL 28

Assisted Solution

Ryan McCauley earned 332 total points
ID: 38341433
Why are you encrypting the password at all? There's no reason at all for the password to be encrypted in a reversible fashion, using 3DES, AES, or anything else.

Instead, you should hashing the password and placing it in the user table, along with a salt of some kind. A hash is a one-way operation, so the resulting stored value can be used to verify the password, but is effectively useless is compromised. I'd recommend a hash like SHA256 - it's pretty quick and produces a value large enough that brute force hashing attacks are useless. Make sure you salt the password as well with a user-specific value (you can store the value in the user table as well, as long as it doesn't change), as it would make everybody's hash different.

If you need some more details on how to accomplish the salting or hashing, let me know and I can post some links, but it's pretty straightforward in .NET and it should be easy to find some examples online.
0

LVL 38

Assisted Solution

Rich Rumble earned 668 total points
ID: 38341826
Hashing isn't any better than encrypting these days, if you pay attention to the way people are doing it currently. If you're going to give the option of telling someone your password was "pass1234" in some kind of reminder, then you need to use encryption. If you're just going to use a password reset anyway, then use a SALTED hash, as opposed to a 1 way hash like MD5. You will never be able to tell the user what their password was, and hopefully non one else, like a hacker, will either.
This topic has recently been covered in great detail in this (above)article from Arstechnica, and brings to light how password auditing and recovery are very easy for evil doers, because application makers are not keeping up with modern password hashing techniques.
Personally we use both encryption and salted hashing of passwords, we have an application that needs to login as the user (do not ask) and it's been audited many times, we however purchased the proper hardware to keep track of the encryption (safenet appliance) and it manages the keys for the encryption and decryption.
I do not recommend encryption without using such and appliance or a very good understanding of key management. Hashing using bcrypt should help you far more than using 3des... http://bcrypt.codeplex.com/
-rich
0

LVL 46

Assisted Solution

aikimark earned 332 total points
ID: 38341884
Since you are developing in the .Net arena, you should be using the System.Security.Cryptography namespace, which provides you with a variety of very strong and reliable encryption and hashing methods
http://msdn.microsoft.com/en-us/library/system.security.cryptography.aspx
0

LVL 34

Assisted Solution

Slick812 earned 332 total points
ID: 38342667
greetings  enrique_aeo, , unfortunately digital encryption these days is a complex thing, if you add data base security to it, then it gets even more involved. Some insist on "Hashing" database passwords as a "Safe" option, others are of the opinion that encryption will be "OK" if you use some particular "settings", "crypt algorithm", "security library", "key manager" and many other things, as you have read in the comments already here. All of these are true, ,  and all of these are false, , depending on what you do, , how you do it, , where you do it, , and how valuable (Big Money?) the "Hidden" data is.  You have to talk in terms of "Levels of security" when dealing with hiding (encrypting, hashing) data.  I hope you do not get too discouraged by the many alternate suggestions that you will get about database passwords, It is my opinion, that if you do not have large value "data" to protect, you can use the 3DES algorithm, if you always use the Max Length KEY (key rotator attack), but almost everyone else will say otherwise as "3DES  is dead", the AES is better if thats an option for you. You do have the correct idea that Passwords should NOT be in plain text.
you give this -
table 2 : with the following columns: id_application, master_key

if you were wanting to do a "higher level of security" you might have a second table with the "master key", but since you are here at EE a doubt you need a real high security level.

Here is my suggestion, but I make NO claims about it's security (good or bad), but just to show some aspects about hiding data.

First never place any REAL passwords in any table column labeled password, passw, key,  or master_key, this can tell the database intruder what the data is without even trying any decryption or "hash table lookup". What I do is have a data table column named password with 16 bytes of random binary data (as if it's a MD5 hash) (you can convert to 32 byte ascii hex if you do not understand binary), If they try to get any decrypted data from this Random block, it will always fail. Next have a table column named secure (or any name that does not hint at password) to store the real password as hashed, encrypted, or hidden binary data. Then if you use a 3DES or other encryption algo, you can use the random password column data as the Key for the 3DES (you will need to shorten it for 3DES). This is not for high level security, but should be more than enough your needs. If they do not have your code, they can not tell that the random password is used as a Key for encryption.

Hope this helps some.
0

Author Comment

ID: 38343867
This is the real scenario: This application is for local use, ie intranet, you need as much security is enough or some encryption algorithm.
Being an intranet, I probably exceeded the security?
0

LVL 27

Expert Comment

ID: 38343875
I'm just making a proposal.

Since this just a "proposal", it would help a lot if we knew how these tables are to be used. Is a user going to enter a password somewhere, and you are going to check that password against your table? Or are you going to retrieve passwords from the table in order to use them to logon to some process under the user's ID?

If we had some idea what the purpose is, the proposal might make sense, or maybe we could suggest appropriate modifications.

Tom
0

Author Comment

ID: 38343885
is a web service to save the encrypted password and another method will decrypt the password, but the only parameter is the user
0

LVL 38

Accepted Solution

Rich Rumble earned 668 total points
ID: 38343922
If it's internal, seems like interfacing with active directory or an NT domain would solve your problem(s). We have an application that "needs" to be able to decrypt the users passwords, but it was a very hard fought battle to get that, we were very very very very against reversible encrypted passwords. Even if this is an internal/intranet application, the data your keeping has larger implications on the network as a whole. It may be possible for an admin or a disgruntled employee to copy/save/take your database and have all these passwords decrypted with ease, especially if your handling the keys in software.
We don't know the full story, and we may not need to, but you need to have NO OTHER option before you use ENCRYPTION, which again is REVERSIBLE, as opposed to HASHING using SALTS.
If I were to propose something, I'd extoll the virtues of having integrated authentication with active directory, pam or ldap. Most programming languages interface easily with those authenticators and do not need to store the users password. We had a mediawiki internal server someone setup without using AD/LDAP authentication and we just about fired him, it's so simple to do and it's one less place you have to worry about password theft.
-rich
0

LVL 27

Expert Comment

ID: 38344065
Okay, it's a web service. But how is the password file used? What is the point of storing these in a database? Why not just use the user's password as they enter it? What is the password actually used to do? Will a user ever enter their password in order to use this service?

So far, I have no idea why this file is needed, so I don't see any useful way to comment on the "proposal". I can't even guess why any encryption is needed at all since there's no way to understand what the purpose is.

Tom
0

## Featured Post

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In real business world data are crucial and sometimes data are shared among different information systems. Hence, an agreeable file transfer protocol need to be established.
Sometimes Administrators rights are not enough. These cases call for the SYSTEM account. The process in this article outlines the steps required to execute commands using the SYSTEM account.
Six Sigma Control Plans
Progress
###### Suggested Courses
Course of the Month16 days, 22 hours left to enroll