Printable View
Looking for advice, first of all on how to securely store a passwords in plain sight. My program is going to encrypt the passwords in some way, and I was wondering what would be best. I was thinking at first, CRC-32 but maybe MD5 would be better.
The second question is, advice on finding GOOD source code to do it.
Before you try to address the proper encryption scheme to use, you have to be 100% sure that you have to be responsible for password security in your application. There will more to protecting your passwords than just encrypting them. Actually the encryption process is fairly straight forward. The hard part is protecting the encryption key and being able to replace the key if it is compromised.
Also you need to decide if the passwords can be stored using a one-way encryption algorithm or if the encryption needs to be reversible. How the passwords will be used by your application will dictate the proper methodology to use.
Sorry no answers here......just some food for thought / discussion.
I'll be encrypting a password with the encryption method and no it does not need to be reversable.
I think the best thing to do is to store a hash of some sort against data I'll be encrypting (data being a password). The only problem I can see with doing that is that someone could decompile my program and get the key that I'm using to create the hash, but is there really any other way?
If you have to store the password and you are using it for internal authentication then hashing (preferably SHA-1 or better) is the way to go.
And yes the key used to hash the passwords will be the weak link in the security chain. If you store the key in the application code, you can play some games with the key -like xoring it with some other known values or something similar to obfuscate it. The key will still be available to someone who wants to take the time to dig it out.
What is your target platform? There are some interesting MS API's (DPAPI - Data Protection API's) in 2.0 .Net Framework. These appear to handle some of the key issues. Not sure if they would be useful for you situation though.
Another possibility is to generate a unique value for the each install, say based on certain hardware configurations. Then combine that unique value with the key in the application to generate a unique key for the hashing. Down side here is that the unique key used for hashing needs to stored somewhere in case the hardware settings change and you need to be able to authenticate folks while migrating to the new hash.
More thoughts............. :-)
I avoid M$ at almost all costs. So I won't use any M$ libraries. Sadly, for now though, the target platform is Windows. But I believe times will change when Linux is more user and hardware compatable.
Looks like SHA-256 or SHA-512 is the way to go when I do decide how to encrypt. It looks like I won't even need the key in my program to encrypt the password because SHA-256 does not use it. Am I right about this? And is that secure enough?
No collisions have been found with SHA-256/512, and is a secure hashing algorithm.
I found 3 different source code implementations for SHA-256:
md5deep-1.12
rehash
sha2-1.0 with open-source BSD license
Anyone have any suggestions of which one to use?
I would agree that using SHA-256 or SHA-512 will cover the bases well.Quote:
Originally Posted by aewarnick
I think that you may want to use a salt when you create your hashes. A salt is a value you add when the hash is created to make the hash harder to break. If you use a salt when creating a hash you will need to hang on to it so you can recreate the hash in the future.
Quote:
Originally Posted by aewarnick
Have you looked at the Crypto++ Library 5.2.1 - http://www.eskimo.com/~weidai/cryptlib.html
It may have what you need as well....I have not used it, but it looks to have pretty good support for various crypto schemes.
I have an interesting question related to the creation and transmission of HASH codes.
The 256 hash is this long:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
that length could significantly be reduced by upping the radix.
Why stop at HEX (radix 16)? Why not use some obscure radix like 128 or 256? That would save on bandwidth and storage. Any ideas why they stop at 16?
It looks like there are 220 practically displayable characters in an 8 bit char:
126-33=93
255-128=127
93+127=220
Can you imagine how much shorter the hashes would be if we simply used the numbers available to us!
Who's with me in developing an algorithm to convert any length hex string to a string that uses a radix of 220 instead of 16?
Noone else thinks this is a good idea?
If you transmit / store the hash as binaries no matter what the radix is, its going to occupy the same bandwidth.Quote:
Originally Posted by aewarnick
Each HEX symbol requires 4 bits to store in which case we need 16 ( 2 ^ 4 ) symbols to represent them (human readable)
For radix X numbers we need log X bits ( base of the log is 2 ) to store them and X symbols (ie.) to read them.
So, no matter what the radix you use, they are going to drink equal bandwidth. Also we settled at 16 because mainly its the least power of 2 > 10. We are so accustomed to 10 ( our fingers! ).
Remember no one is transmitting the hash as plaintext except in some minor places.
1. The hash algorithms I've seen for SHA-256 all return a 64 character hex number. Are you saying that they normally aren't stored and transmitted that way?
2. If not how large in bytes is the binary HASH they store; 32 bytes?
I've taken some source code that I aquired and give the option to send back a 32 byte binary or a 64 byte hex number. The problem is that the binary cannot practically be displayed to a user, but if a radix of 220 was used; yes, it will be larger than the binary but much smaller than the hex string. And it could be stored, transmitted and shown without any more transformations. Seems useful to me.
3. "Remember no one is transmitting the hash as plaintext except in some minor places":
Alot of web sites display hex HASH values for their downloads. If they have thousands of downloads, the bandwidth is increased to display the 64 byte hex HASH's. This idea will decrease bandwidth on the web. Am I right?
You could always transform them into hex numbers and use them. Most open source libraries provide text output because the text could be captured in a file and displayed to the user. I have "seen" windows registry of storing user information. They are all hex.Quote:
Originally Posted by aewarnick
No one can read and remember such large number of symbols. I used to read hex as decimal (when i am new to this world). I cant read B I can only tranform it to 11 and read.Quote:
Originally Posted by aewarnick
Sorry about this. I am not right about this. Its a relative term : in many places we use them to show the user not to a computer. We can always translate b/w hex and user readable format (its trivial) rather moving on to higher radix. Some number theory books represent higher radices numbers as string of hex. Itseasier that way.Quote:
Originally Posted by me
Radix 16:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
Radix 220 (guess):
25Hw.Q;\?>,)*+wQ&-=|8~p[}/{!369jWGw
The 220 HASH may look very confusing at first glance but when comparing "side-by-side" with a comparable HASH...
25Hw.Q;\?>,)*+wQ&-=|8~p[}/{!369jWGw
2qHw.Q.e2{x)*+pQ&-Py8~pP}/{!+URjWGw
it's actually much easier to tell they are different than this is:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
bqwa16bf8f01cfea414150derdae2q23b00361a396177a9ca410rf61u20011ad
I would look at the OpenSSL source code, it will tell you everything:Quote:
Originally Posted by aewarnick
http://www.openssl.org/source/
I think MD5 is good, but I wouldn't use CRC-32.
-Greg Dolley
Conversion back and forth is not trivial. If we use hex the conversion this is trivial.
This code assumes 32 bit machine with ascii for char.
The point here is : the variable temp. It can only be 32 bits in length. Also, check the if else which maps hex to char. Both these steps will become costly if we go for higher radix also highly dependent on charcter set used. Atleast this is why I wont go for it.Code:unsigned int hex = 220;
char chex[10];
unsigned int mask = 0xF0000000, i = 0, temp;
memset(chex, 0, 10 * sizeof(char));
do
{
temp = (hex & mask);
temp = temp >> (4 * (7 - i));
chex[i] = temp;
if(chex[i] < 9)
{
chex[i] += 0x30;
}
else
{
chex[i] += 0x37;
}
mask = mask >> 4;
++i;
}while(mask);
printf("%0x, %s\n", hex, chex);
As for comparision there are programs to do that. The bandwidth can always be saved the other way. We can define a new control which can accept hex values and display them as user readable string. Also I dont think its necessary; its not going to save a lot, you transmit 128 bytes instead of 32 bytes traffic which is very small when compared to the file (some kbs).
The savings is trivial...you're right, it may not be worth the effort.
What is that code you posted? Conversion from binary to 16 or binary to 220?
Binary to Hex characters.Quote:
Originally Posted by aewarnick
Compare it with the binary to some higher radix conversion function. It will not be trivial as this one.
You don't know of any code to do that do you?
Its not tough to do that. Here are the steps.
1. get the binary equivalent of the symbol. Usually mask will do this work. But if you go for higher radix (220 radix requires a datatype of length 220 bits) there is no std data type to store the value (ofcourse the input is also an array). But you could always store it in the array.
2. now map those binary values to printable chars. In hex conversion this is done by the if else statement.But in case of higher radix this task is not trivial for higher radix as each value is an array.Code:if(chex[i] < 9)
{
chex[i] += 0x30;
}
else
{
chex[i] += 0x37;
}
Of course you can go for radix 32 in a 32 bit machine and avoid all these array business.
Sorry for a bit offtopic here - however here's another reason for not using md5 in any easily accessible place.
Hope you will find it interesting.
http://www.antsight.com/zsl/rainbowcrack/
That's not off topic at all! It just goes to show why I should use something more secure.