Is there standard way to generate Password Hash with Microsoft development tools?
Or maybe there is most common way. (I have read that there is MD5, STA1)
Unfortunately I don't have server's source code, but have to consume SOAP web-services.
The must be some algorithm to generate hash code. I need to implement it using Java or using some library.
Here is part of SOAP request that I need send to server. Look at oldPasswordHash.
- <ChangePassword xmlns="urn:____________">
<sessionGUID>{864da5f3-21b6-486a-8bd3-c507ae3d224e}</sessionGUID>
<oldPasswordHash>089ad55bd0a8f6d3c2e2bbf0e4e1475c7e984ef1</oldPasswordHash>
<newPasswordHash>f4a69973e7b0bf9d160f9f60e3c3acd2494beb0d</newPasswordHash>
</ChangePassword>
These are SHA1 hashes of the unsalted passwords.
f4a69973e7b0bf9d160f9f60e3c3acd2494beb0d is the SHA1 hash of Passw0rd!.
The fact that I was able to reverse one of the hashes with a rainbow table service demonstrates that hashing of passwords without salting is very insecure.
In C# you can reproduce the implementation like this:
public static string Hash(string value)
{
var sha = new System.Security.Cryptography.SHA1CryptoServiceProvider();
byte[] hash = sha.ComputeHash(Encoding.ASCII.GetBytes(value));
return BytesToHex(hash).ToLower();
}
private static string BytesToHex(byte[] bytes)
{
return String.Concat(Array.ConvertAll(bytes, x => x.ToString("X2")));
}
For a java version, take a look at the first google hit for "sha1 java".
As for hash algorithm, you need a cryptographic hash function, that is a hash function that is (for all intents and purposes) impossible to reverse. Be also aware that there exist files (and indeed websites) that strive to calculate every hashcodes for every string and publish these so called Rainbow Tables. (SHA256 seems like a good choice to me.)
As for programmatic generation, look at System.Security.Cryptography in .NET.
As for tooling to create hashes, I know of nothing that comes with Windows. Obviously you can use the GNU tooling via Cygwin (or the like) or search for a command-line tool for the algorithm you have chosen.
Cygwin for windows provides command line hashing tools such as sha1sum in its coreutils package that can easily compute a hash for you. The Bouncy Castle libraries would provide implementations of most common hash algorithms in both Java and .NET.
The sample XML doesn't say much. The strings are hex, 40 chars in length which is 20 bytes or 160 bits. That may mean it's SHA-1 (which is 160 bits) but not necessarily. In addition, how did it generate a hash from the password. Was the password plaintext, plaintext with some salt, plaintext mixed with some other hash etc. I guess if you install sha1sum first from the command line, you can see what happens if you feed the password into it. You might get lucky and discover what it's doing. Then you can proceed to code up the equivalent with Bouncy Castle.
Related
In most cases I need to encrypt a string with a password and then send/save it somewhere. Later I want do decrypt it with the password. I am not encrypting nuclear missile codes or medical patient data! The ideal would be 2 functions:
string Encrypt(string plainText, string password);
string Decrypt(string cipherText, string password);
I had a look at the crypto documentation... Oh boy! So I try to code the above calls myself (see a proof of concept using AES Managed and Base64 encoded payload). I am no crypto expert, why do I have to code that? I probably did somethings wrong...
To derive the key from the password the interface requires a salt. Can I use the password as salt? Can I re-use the IV as salt? Maybe not, but I don't want to add another parameter.
Can I use a fixed IV? Same plaintext and password should result in different cipher text, so I have to supply the IV for decryption in the payload.
Can I use a salt for the key and keep the IV constant instead? Feels wrong.
Creating a nonce and deriving IV and key salt from it is a valid approach?
If .Net would support the GCM mode would I still have this problems?
The .NET crypto API exposes a general purpose encryption library, containing object oriented approaches to implement cryptographic algorithms. Of course, to use these algorithms and algorithm implementations you need to have a good grasp on cryptography, which you currently lack.
This general purpose library is required to implement the various protocols that exist out there. Usually a single algorithm doesn't fulfill a specific use case (encrypt a string using a password, returning a different string, in your case). So a protocol needs to be chosen or devised that does fulfill that use case. This protocol may e.g. define a container format such as CMS or PGP, which can for instance be used to encrypt emails (the use case).
You're directly trying to apply cryptographic algorithms to solve your use case. That's not going to work. You need a pre-made protocol, preferably with a pre-made API.
Note that there are many different use cases, many different protocols and even more opinions on how to create and implement those correctly. Libsodium / NaCl for instance defines a small container format called SecretBox that does take some of the work from you.
However, it would of course be rather impossible to implement TLS on top of NaCl, as the functionality / algorithms are just not there. Again, .NET needs a generic crypto library like the .NET API for others to implement their protocols.
So either you'll have to byte the bullet and try to create your own protocol or you take an existing one and take an educated guess if it is secure (hopefully the protocol has been reviewed / updated a few times). Stay away from single person projects without additional contributors (like the many sample codes out there without review).
For your own protocol, yes, there are mistakes such as not storing the salt with the ciphertext. You need a random - or at least unique - salt to be secure, reusing the password for that is certainly not secure. Don't let it become a single person project itself and either borrow a protocol or have it reviewed.
OK, quickly then:
To derive the key from the password the interface requires a salt. Can I use the password as salt? Can I re-use the IV as salt? Maybe not, but I don't want to add another parameter.
No, the salt needs to be unique and preferably random; the password / salt combination should be unique (it should not repeat, not even in time, or over different domains).
Can I use a fixed IV? Same plaintext and password should result in different cipher text, so I have to supply the IV for decryption in the payload.
No, unless the key changes value each time (see above). For CBC the IV should be unpredictable unless you use a fresh key each time.
Can I use a salt for the key and keep the IV constant instead? Feels wrong.
That's possible, as long as you don't repeat the salt.
Creating a nonce and deriving IV and key salt from it is a valid approach?
That depends on very specific details. In other words, I would not try it if you don't exactly know what you're doing.
If .Net would support the GCM mode would I still have this problems?
Absolutely, and in a sense your problems would be worse if you'd use GCM, as using GCM with the same key and IV is completely broken.
Remember, GCM is just an algorithm, not a protocol, it cannot solve your use case by itself.
I am working on Database where some of the Encrypted data I inserted in the database must be decrypted to be shown to the user. Is it possible to convert a decrypted message/varchar entry in the database to their Orginal or String form? let's say I have this hashed message
`abc = `'7meXQAMRb+ERvBj6Dy/SEe6ldukGy6bTKugnCsoYyl+lYNT6';
is there anyway to return that 7meXQAMRb+ERvBj6Dy/SEe6ldukGy6bTKugnCsoYyl+lYNT6 back to abc again?
Btw I used Omu Encrypto for Encrypting my password
No, you cannot decrypt data that has been hashed.
That's the entire point of hashing information; it's a one way process most of the time.
You can use what's called a Rainbow attack to brute force some inputs and see if the hashes match, but to be honest that takes a long time and is probably not what you're looking for.
See Eric J's answer for more details.
One cannot reverse a hashed password reliably into the original string. However, it IS possible to reconstruct SOME valid input that yields a given hash. I'm providing this answer because the other answers are only partially correct, and it is important to understand the relative security of a hash.
To understand this, assume you use a 1-bit hash algorithm (that is, the hash is either 1 or 0). Half of all strings that you hash will yield a "1". Expand that to a 2-bit hash, and 1-in-4 strings that you randomly hash will yield a given hash value (hashes will be 0, 1, 2, or 3... in binary 00, 01, 10, 11). Expand that to say 128 bits and, while hash collisions are FAR less common, they still occur. If your hash algorithm has known vulnerabilities, it can be computationally straightforward to defeat it.
The MD5 has, for example, can be attacked using Rainbow Tables. There are online services that offer hash "cracking" e.g. http://md5crack.com/. Here, cracking means to reconstruct SOME valid input that yields the hash. Even brute force cracking is viable with modern processing power, especially using a GPU-based approach and/or distributed computing.
Hashes are a great tool, but be aware of your security requirements and the relative ease of reversing a hash generated by your chosen hash algorithm into some valid input that yields that hash. Also, always be sure and use a salt value with your hash.
UPDATE
Now that the question has been re-written, I would refer you to AES encryption. See
Using AES encryption in C#
Hashes are one-way, but if you used a third party encryption method like you said, they should provide a decryption method as well.
I reused some old code and come saw that I had been using this code to generate a SHA1 hash.
HashAlgorithm sha = new SHA1CryptoServiceProvider();
return sha.ComputeHash((new UnicodeEncoding()).GetBytes(password.Trim()));
When I use the following code to generate a SHA1-hash I do not end up with the same hash as when I test with, for example, http://gtools.org/tool/sha1-hash-generator/
Which one is correct?
Am I doing something wrong here?
Most likely a difference in encoding. You're using UTF-16. Try using UTF-8.
Just confirmed that this site uses UTF-8. But their code is broken for certain characters, such as ', because they put their input through sql escaping.
But hashing a password with plain SHA-1 is almost never the correct choice. In most cases, such as storing passwords used for login to your site you should use a proper password hashing functions, such as PBKDF2, bcrypt or scrypt with an appropriate salt.
PBKDF2 is implemented in .net in the Rfc2898DeriveBytes Class
Example of SHA-1 salting:
return Convert.ToBase64String(
new HMACSHA1(
Encoding.UTF8.GetBytes(salt))
.ComputeHash(
Encoding.UTF8.GetBytes(input)));
I'm writing a web app in ASP.Net that creates a licence key for a Windows app written in Delphi. For simplicity I'm going to use a email address and date.
I want to encrypt it in C# and email that info to the person then when the Windows app starts up the person enters in the encrypted string.
Every time the Windows app starts it checks that licence by decrypting it and comparing to todays date.
How can I do this to ensure the C# encryption will decrpyt succesffuly in Delphi?
"the world was full of bad security systems designed by people who read Applied Cryptography"
While the trivial answer is 'use the same algorithm and make sure you have the same keys and initial vector', this answer only exposes the true problem you are going to have: How are you going to protect the encryption key? Mail it along with the license? Embed it in the application? The truth is that there is no protocol that can bootstrap itself w/o a root of trust, either a public trusted authority or a shared secret. A shared secret is easy to code, but complete useless in practice (which means AES, 3DES, XDES or any other similar cipher are not the answer), so you need an scheme that starts based on public key cryptography. For such, to encrypt something for the beneficiary of the license, you need the public key of the said beneficiary, which would make provisioning difficult (license site sends public key, you encrypt license, send email etc). It is much better to send the license in clear text, but signed with your private key. Then your application can validate the signature on the license and use it, if not tampered with.
S-MIME is such a scheme. PGP is just as good. Writing your own code in C# and Delphi is possible, but strongly discouraged. See Cryptographic Signatures.
AES for Delphi and AES for C#.
You can use standard RSA or DSA signature algorithms to do what you want. For C#, these are standard algorithms built into the runtime. For Delphi, you have some choices. See Free Encryption library for Delphi.
Once you have chosen an encryption library for Delphi, you can now do the following:
The C# server signs the user's e-mail address and date using the chosen signature algorithm with your private key.
The Delphi client verifies the license using the same signature algorithm.
Once the Delphi client knows the signature is valid, you can then test the e-mail address / date and decide whether or not to allow your program to run.
I have done exactly the kind of signature verification you want/need using the DSA algorithm, LockBox, and C#.
One thing to be aware of is that C# encryption uses big-endian numbers, while LockBox / Windows CryptoAPI uses little-endian numbers. This probably means you need to reverse endian-ness of both the public key variables and the signature itself before sending it to the Delphi client for verification. Check your crypto library documentation.
One last note: others have proposed using symmetric encryption algorithms like AES / 3DES / etc. The problem with this approach is that your "secret" encryption key is shared between server and client. It is possible that someone could recover the key by reverse-engineering your compiled EXE and then create a "key generator" - a worst-case scenario being a fake activation server that passes out "authentic" encrypted licenses. By using assymetric crypto and keeping the private key secret, you won't have this problem. Users would have to crack every new version of your EXE or else pass around signed authentic licenses - much more inconvenient.
Use the same encryption / decryption algorithm in both delphi and c#.
You can either find the code for an encryption algorithm for C# and then convert the code in the decryption algorithm into Delphi. Likely if you pick a popular encryption you'll be able to find both encryption and decryption algorithms already in many different languages.
After reading this post regarding the use ECC to implement the hashing using aa private key I set about trying to find an implementation of ECDH and came across BoucyCastle.
Unfortunately documentation is minimal (as in zerow!) and I'm unsure what I'm about to accomplish is completely correct/valid.
We want to simply hash 4 strings which will be the users registration information (Name, Company, their company ID and their account ID which are both 12 characters long) which will then compute a serial they can use to activate our software.
I have generated a key pair using PUTTYGEN.exe but I cannot workout how to apply this with BouncyCastle, which class can I use to get started? Are there any examples out there?
So far I've concatenated the information and computed a MD5 hash of it (using the .NET classes) I cannot use the new VISTA enhanced API functions as we target XP still - .NET 3.5.
Anyone have any ideas?
I think .NET has the RSACryptoServiceProvider class which is a full RSA implementation.
There's sample code for your particular application here:
http://www.codeproject.com/KB/security/xmldsiglic.aspx
In this example they use MS's sn.exe tool to create the key.
So far I've concatenated the information and computed a MD5 hash of it (using the .NET classes).....
That statement in itself worries me. MD5 is seriously crackable - not just theoretically but practically. Please, please don't use MD5 for secure hashing. Use SHA-256 or SHA-512 and here's why
Also the post you linked is not quite true - yes symmetric algorithms use the same key to encrypt/decrypt but public/private key is not a magic bullet.
1) Public/private key is slow
2) Most publicc/private algorithms just encrypt the symmetric key and then use symmetric encryption for the data because it's much faster
The point is that a good hashing algorithm is non-reversible and hence very difficult to crack so is perfectly fine for your purposes. However, I'd suggest using a SALT, which is a cryptographically random number to add to your user data then hash that data as it makes your data much safer against dictionary attacks ( where hackers use well know terms and variants to crack passwords )