Best way to store a password

[aewarnick]

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.

[f1shrman]

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.

[aewarnick]

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?

[f1shrman]

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............. :-)

[aewarnick]

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?

[Calculator]

No collisions have been found with SHA-256/512, and is a secure hashing algorithm.

[aewarnick]

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?

[f1shrman]

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?

I would agree that using SHA-256 or SHA-512 will cover the bases well.

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.

[f1shrman]

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?

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.

[aewarnick]

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?

[aewarnick]

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?

[aewarnick]

Noone else thinks this is a good idea?

[kumaresh_ana]

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?

If you transmit / store the hash as binaries no matter what the radix is, its going to occupy the same bandwidth.

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.

[aewarnick]

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?

[kumaresh_ana]

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?

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.

if a radix of 220 was used; And it could be stored, transmitted and shown without any more transformations. Seems useful to me.

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.

Remember no one is transmitting the hash as plaintext except in some minor places

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.