June 24, 2008 at 6:19 pm
Hi the article http://www.sqlservercentral.com/articles/Security/freeencryption/1980/
deals with base64 based encoding / decoding. but is there any article that deals with salted passphrase based encoding ? i have such a need now.
September 3, 2008 at 2:31 am
Hi,
I'm in need of the same thing. Does anyone know of a good solution for salted Base64 T-SQL?
Best regards,
- Alex.
September 7, 2008 at 5:45 pm
Why would you salt Base64 encoded data? Base64 is a reversible transformation, not encryption.
The article show how to use a 3rd party Blowfish function to encrypt your data with a key - just generate your salt value(s) and prepend or append them to your plaintext before you pass it through the Blowfish function.
Regards,
Jacob
September 8, 2008 at 1:39 am
Hi Jacob,
Thanks for the response! As far as I know, salted Base64 is reversible as long as you know the salt. Without the salt, you'd need some sort of brute force thing. The salt is a key known on the sending server and the receiving server. The reversible Base64 is to communicate data that forms a transaction. The transaction host expects a salted Base64 message. Can this be done using T-SQL? It would render the need for server side programming obsolete, for the solution at hand at least.
Best regards,
- Alex.
September 8, 2008 at 2:43 am
Salts are commonly used in two ways:
- When encrypting data using a key-based algorithm (Blowfish, TripleDES, AES, etc.) - you typically append the salt to the key/passphrase during encryption to increase the complexity of the key. This helps if the key is compromised and the salt isn't, and generally help prevent weak keys being used if the salt is complex enough.
- When generating a hash from data (MD5, SHA, etc.) - you typically append the salt to the plaintext itself. This prevents a simple rainbow attack using tables of pregenerated hash values for all lengths of plaintext.
In both cases the salt value may be static and commonly known by all both encrypter and decrypter, or may be dynamically generated per plaintext you encrypt, in which case you need some other out-of-band means to transmit the salt values to the decrypter.
Base64 is a simple transformation only - it is NOT encryption. You will often see output from encryption algorithms in Base64 format simply because the ciphertext they output is often composed of bytes that aren't printable in simply 8-bit ASCII, so a Base64 encoding is applied to the ciphertext AFTERWARDS for ease of transmission over text-based media.
When you say "salted Base64" that means one of two things to me:
a) you append the salt value to the plaintext then Base64 encode it. This is utterly trivial to decode and provides no security whatsoever.
b) you modify the Base64 encoding algorithm in some way to incorporate your "salt". The output from this would no longer be Base64 as the world knows, and even though you would modify the decoder to decode it in the same way I doubt very much that it would be in any way secure. Don't try to "roll your own" encryption algorithms - leave that to the experts in the crypto community.
Can you describe in detail exactly how you want to work with this in your transactional client-server scenario?
Regards,
Jacob
September 8, 2008 at 2:58 am
Hi Jacob,
Well, OK, I'm new to .NET, as I'm a classic ASP developer. The solution I'm after is to post from within a DotNetNuke environment to an external site. This involves some security, of course.
The transactional data is made into a string, this string is hashed using HMAC-SHA1 and a token. The result of this is turned into Base64 for transportation, indeed, like you say. So, I missed a step there.
It appears I need a SHA1 option then. MS SQL can Base64 strings, I believe I've read somewhere that there are SHA1 implementations for SQL Server.
You already helped me define my problem more clearly 🙂 Thanks for that!
Best regards,
- Alex.
September 8, 2008 at 6:20 pm
No problems Alex,
From your description you have a set of data being posted along with an HMAC-SHA1 of that data, and your receiving system needs to validate that post by regenerating the HMAC-SHA1 from that data and comparing it to the posted HMAC, correct?
Raul Garcia blogged about generating MACs here a few years ago, though it's SQL2005-specific. His solution was to simply append the "salt" value to the end of the plaintext before hashing it with SHA1 which does the job but isn't quite RFC compliant.
Are you using SQL2000 or SQL2005? For 2000 you need to use either a 3rd party XP or a T-SQL implementation (or a hybrid using COM OLE Automation) of the hashing algorithms, whereas in SQL2005 you have the builtin HashBytes() function and can also write your own CLR function to do the job using the dotNET crypto libs.
These will give you your SHA1 hashing - but only the Chilkat or dotNET CLR solutions will do your HMAC-SHA1 in a standard manner. Shouldn't be too hard to modify the T-SQL implementation or wrap the 3rd-party XP solution in RFC-correct code either. Do you have control over the posting website so that you can modify the HMAC algorithm?
Regards,
Jacob
September 10, 2008 at 6:27 am
Thanks again for your time Jacob,
Your assumption (a set of data being posted along with an HMAC-SHA1) is correct. The blog you mention is very interesting indeed. I found two T-SQL functions that, when combined, could take care of the SHA1 HMAC and the Base64 encoding. However, there probably are reasons why this is not standard procedure. I found it therefore wiser to take care of both in additional application code behind. The .NET framework makes it easy by making things like the HMACSHA1 Class and the ToBase64String Method available. It was time to take the plunge.
I tried to avoid coding, as the .NET field is new to me. However, you can't just keep on trying to find solutions if these solutions are actualy more time absorbing then the alternative 🙂 It did bring some facts unknown to me to my attention though. Searches like this are never waysted. If an elegant SQL solution comes to my attention, I'll certainly post it here.
As for your questions, I'm using SQL Server 2005 for this. I don't have any influence on the recieving end, as it is an online payment gateway.
Best regards,
- Alex.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply