I have a following situation.
1. I need to encrypt set of strings in t-sql. These encrypted strings will be manually delivered to users.
2. Users have neither knowledge nor access to sql server. I'd like them to go to a website copy/paste the hash and get the original string.
There are no security requirements. Just that the hash doesn't look like original string
On the other hand it's important that access to the website and decrypting process is ultra-easy for the users.
Do you know what t-sql function I can use(it can be user defined)
What website
Ideally you want to encrypt in your application, and send the encrypted hash to the database.
But there are several ways of encrypting strings in sql server
For example, you can use EncryptByPassPhrase, and DecryptByPassPhrse.
More information here: EncryptByPassPhrase, and DecryptByPassPhrse
Or you can encrypt using something simple like MD5, and they can go to an MD5 decrypter online.
I'm assuming your making the site, so you should easily be able to encrypt, and have the decryption done on the site.
You can consider using base64 encoding. This question explains how to convert input text into base64 string in T-SQL. For example TestData will be converted into 'VGVzdERhdGE='. There are also many online base64 decoders which will perform the inverse task and decode'VGVzdERhdGE=' into 'TestData'. For example see this one.
Of course base64 doesn't provide any security. It only changes the representation of the input text. It means that everyone who will receive the encoded string will be able to decode it.
Related
I have to store AES-GCM encrypted data in a database. Currently we use MariaDB but with the option to later change to PostgreSQL. (however other databases should be considered as well)
Since the algorithm does not actually encrypt strings, but bytes and the output of an encryption algorithm is also a byte[], why not store the encrypted data directly in a binary column?
For MariaDB/MySql that would be as a BLOB. I understand PostgreSQL even has a preferred special data type for encrypted data called bytea.
However most programmers seem to encode the encrypted bytes as Base64 instead and store the resulting string in a VARCHAR.
Encoding to and decoding from Base64 seems counter intuitive to me. It makes the data up to 50% longer and is an extra step each time. It also forces the database to apply a character encoding when storing and retrieving the data. This is an extra step and surely costs extra time and resources, while all we really need to store are some bytes. The encrypted data makes no sense in any character encoding any way.
Question:
Is there any good reason for or against storing encrypted data as binary in a database? Is there a security, data integrity or performance reason why I may not want to store the encrypted data directly as binary?
(I assume this question will shortly be closed as "opinion based" - but nevertheless)
Is there any good reason for or against storing encrypted data as binary in a database
No. I don't see any reason against using a proper "blob" type (BLOB, bytea, varbinary(max), ....)
The general rule of thumb is: use the data type that matches the data. So BLOB (or the equivalent type) is the right choice.
Using base64 encoded strings might be reasoned because not all libraries (obfuscation layers like ORMs) might be able to deal with "blobs" correctly, so people chose to use something that is universally applicable (ignoring the overhead in storage and processing).
Note that Postgres' bytea is not "a special type for encrypted data". It's a general purpose data type for binary data (images, documents, music, ...)
Which method or way would you choose to make encrypted data only accessible for the user and an algorithm to process and evaluate the data? In this case the user would be one of n service-users, who would add sensible data (mostly answers to questions) about himself into the database. The company who is providing the database shouldn’t have any access to the sensible data, but to the results of the data processing. The results wouldn’t give any conclusion of the sensible data.
What you are looking for is Fully Homomorphic Encryption (FHE). FHE operates on encrypted data. This can be achieved by an encryption scheme that supports two operations on encrypted data. RSA and others only supported one operation until Gentry's work.
With FHE schemes like HeLib (there are many now), you can upload your data the server and give a function (circuit) to evaluate. The FHEs, in general, have semantic security (randomized encryption). The Semi-honest server can only see encrypted data and can return the result back to you.
Note: They are not practical, yet.
I think the best way to do that is to save only the result. but if you want to save the user's answers you could use AES with the user's password as a key by doing so the user will have to enter his password every time to decrypt the data.
I have an application that processes email and stores the subject / message body in a database.
This information is used to to preview the emails in a web appliciation before opening the email from disk in outlook.
Emails can be sent with different text-encodings.
To store the subject and body content into the database I feel I need to store the encoding used in the email and then I have 2 options:
store them in binary form
store them base64 encoded
(from: Safely Store HTML in DB without affecting Character encoding)
this because I fear I will lose data because of the collation on the column/table in sqlserver. (since the encoding is row specific in my case)
In this particular case I don't care much for issues regarding searching / sorting the data in the ui.
Another option might be to convert the incoming characters to a specific encoding (utf-8 for instance).
Since I don't feel I fully understand the problem domain (and yes I did read http://www.joelonsoftware.com/articles/Unicode.html) I'd like to know if there is a better way or maybe I'm concerned for nothing.
In my C application I have a decryption key that is used to decrypt sets in the database (username / password). Currently, I simply declared it with
char * key = "$$$secretSampleDecryptionKey$$$";
Shortly after that line, I prepare the SQL statement and then select from the DB. My question is, if someone was to debug my compiled application or dissassemble it, will they actually see the key? What can I do to hide it from them?
EDIT:
As Mark and Aaron pointed out, I can simply use the Linux / Unix strings command
strings nameOfApplication
to print out all the strings in my application, including the "secret" key.
EDIT 2:
The app runs on my server and the database stores sensitive customer data that is encrypted. I thought I was playing it safe by not having the key in a text file for everyone to read but compile it instead.
An interesting link relating the story of someone retrieving a password from a binary :
Deconstructing an ELF File
This is a step-by-step description of what someone could try to discover a password. It will give you some idea of what "not to do". The use of the command strings is the first item in the list for example.
If you want to hide your secret string from strings, you can store it in as a char array not terminated with \0 character. strings should not pick it up.
There is also a nice trick mentioned (which is bypassed) to avoid someone to use a strace/ltrace on your binary.
Ultimately by disassembling the code, the "hacker" manage to retrieve the password, which as other have pointed out is difficult to protect against. Basically you can't really hide anything in a binary...
If the key is in your source then an attacker will be able to find it. The best you can do is to make it more difficult for them.
The stored key should not be text, but binary. That way you avoid searches for strings. Presumably if you have the key present in the code your users do not need to be able to type it in.
Store the key in at least two random looking binary arrays that are XOR'ed together to make the actual key. Alternatively, pick one of the standard text strings that is present in your application anyway, something like: "Please enter the Zipcode: ", and use that as your key, or as one component of the XOR. Hashing such a message would get it to a standard length if needed.
Using a debugger / disassembler the user will always be able to find out the password. You can make it harder (e.g. use obfuscation), but not impossible.
If you really do have a secret (i.e. a private key needed to decrypt the data), you can perform decryption on a smartcard.
In your scenario concerning usernames and password, you might just store the password-hash in the database (see referenced answers in Best way to store password in database)
Can someone see it?
The command strings will show the string, no need to disassemble the application.
Disassembling will just make it more simple to identify which of the 15'000 strings is used as key.
What can I do to hide it from them?
There is only one solution: Don't put it in the code.
Instead, use a license key or similar technique where the user knows the key.
I wonder if someone could give us a real answer to solve this problem. From my experience as an web dev I can tell you that what you give to client does not belong to you anymore to control. Consider a website using some encryption algorithm on the server-side and a hard-coded javascript technique on the client, and the webdev, himself, guided by his own vanity, do not want to show it to the world, but still to be used by the clients, as it is.
In this case, what can he do? Yes, yes, he can come up with the idea to put his script in an infinite loop based on setTimeout, all as an anonymous function, so it can't be tracked, but still the initialisation must be done somewhere, the code must be visibile, further more, he decide to send the code after load in an encrypted way, but still, on the client you wil still have to have the decryption key, so someone who want's the information will still have the two necessary pieces of this puzzle. But our programmer is perseveringly, so he creates the decryption function every time to match only one encrypted string, but still it does him no good. As the client will still have the string and the matching function.
Anything he can do is to find a way to use the environment so that the function can be used only one time, after that the code used to expire as the string, and the real information to be lost forever. And the thing with the highest importance is to make the use of the environment in such a way that the context of the execution of the decryption function can not be forged.
I know that I do not answered your question but I pin pointed some important details of the problem you mentioned. If you work with C there must be some tools you can use, as creating a context using some memory state or an actual system operation to get you something that can't be forged.
EDIT 1:
You could create an interesting domino efect in your code leaking bits of the encryption key based on the execution as when it is needed you wil have it entirely but it would not be stored in a file or in a string in your compiled file, so it can only be found at runtime, and it only be found in some specific conditions, and further more it might take some hrd reverse engineering to get it. Might be a good solution.
With great respect,
Paul
I am using windows form and mysql.
I am very confuse about different between encode and encription?.
encode also change the string value. and decode is give back the string.
In my program,...
userid - mcs
password - mcs
i want to store these strings in mysql database. but not a same string, for security purpose.
What is secure way to store these datas.
encode and encription which is best for this requirement.
thanks in advance.
i googled for the different but till i am not clear!. any one pls tell me the different between encode and encription?. For my requrement what i use?.
Before leave this question just vist my downvote question in Click here
In short:
Encoding transforms data from one representation to another, in such a way that anybody can transform it back. So if you want to prevent other people from seeing the original data, encoding alone is not useful at all.
Encryption transforms data in such a way that only persons who know a secret key can get the original data back.
However, there is a third option, which is what you probably will want to use in this case (which is the reason I am posting this, since others have already stated the above points):
Hashing. This transforms the data in such a way that no one, not even you, can get the data back - however, each time you hash the same data, you will get the same result. Why is this useful? In your case, by hashing the password, you will accomplish your goal of preventing people who can access the database from seeing what the passwords are. However, you can still verify that someone who tries to log in has provided the correct password: simply hash the password the user entered, and if the result matches what is stored in the database, the password was correct. This is a standard and highly recommended approach; see the Wikipedia article on password hashing.
Encoding is how the different characters are represented according to their memory spaces (8bit etc.). Encryption is how to keep a text hidden with the use of a secret key. After encryption the text turns into a series of arbitrary bytes so you encode it with say Base64 encoding to be able to make it into a readable (and properly cachable) string.
You'll want to encrypt your user information before storing in a database for security purposes. MySql Encryption has many function to help you with that.
Encoding and decoding (such as base64) are often associated with security procedures but encoding data is not at all a secure procedure on its own. Encoding simply turns an arbitrary set of byte data such as jpegs, gifs and encrypted bytes, into a string of text which easier and safer to store and transport across a variety of platforms and systems.
With encryption you actually secure data by processing it with a secret key into a different, encrypted block of data that is very hard to break without the key with which it was created. Decryption does the reverse, provided you have the key.
To secure your data you need to encrypt it. To help you store encrypted data you may want to encode but it is optional. If you store your encrypted data as a db blob, there's no need to encode.
To get the data back, you will need decode it (if you encoded) and then decrypt.
Always google gives the best answer, by quick search.. Very neat with example explanation here.
http://www.blesta.com/2009/07/26/encoding-vs-encryption/
http://www.perlmonks.org/index.pl?node_id=66249
Don't get confused, encoding is not encryption
http://www.di-mgt.com.au/encode_encrypt.html