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
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 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.
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
What is your preferred method/datatype for storing passwords in a database (preferably SQL Server 2005). The way I have been doing it in several of our applications is to first use the .NET encryption libraries and then store them in the database as binary(16). Is this the preferred method or should I be using a different datatype or allocating more space than 16?
I store the salted hash equivalent of the password in the database and never the password itself, then always compare the hash to the generated one of what the user passed in.
It's too dangerous to ever store the literal password data anywhere. This makes recovery impossible, but when someone forgets or loses a password you can run through some checks and create a new password.
THE preferred method: never store passwords in your DB. Only hashes thereof. Add salt to taste.
I do the same thing you've described, except it is stored as a String. I Base64 encode the encrypted binary value. The amount of space to allocate depends on the encryption algorithm/cipher strength.
I think you are doing it right (given that you use a Salt).
store the hash of the salted-password, such as bcrypt(nounce+pwd). You may prefer bcrypt over SHA1 or MD5 because it can be tuned to be CPU-intensive, therefore making a brute force attack way longer.
add a captcha to the login form after a few login errors (to avoid brute-force attacks)
if your application has a "forgot my password" link, make sure it does not send the new password by email, but instead it should send a link to a (secured) page allowing the user to define a new password (possibly only after confirmation of some personal information, such as the user's birth date, for example). Also, if your application allows the user to define a new password, make sure you require the user to confirm the current password.
and obviously, secure the login form (typically with HTTPS) and the servers themselves
With these measures, your user's passwords will be fairly well protected against:
=> offline dictionary attacks
=> live dictionary attacks
=> denial of service attacks
=> all sorts of attacks!
Since the result of a hash function is a series of byte in the range 0 to 255 (or -128 to 127, depending the signed-ness of your 8-bit data type), storing it as a raw binary field makes the most sense, as it is the most compact representation and requires no additional encoding and decoding steps.
Some databases or drivers don't have great support for binary data types, or sometimes developers just aren't familiar enough with them to feel comfortable. In that case, using a binary-to-text encoding like Base-64 or Base-85, and storing the resulting text in a character field is acceptable.
The size of the field necessary is determined by the hash function that you use. MD5 always outputs 16 bytes, SHA-1 always outputs 20 bytes. Once you select a hash function, you are usually stuck with it, as changing requires a reset of all existing passwords. So, using a variable-size field doesn't buy you anything.
Regarding the "best" way to perform the hashing, I've tried to provide many answers to other SO questions on that topic:
Encrypting passwords
Encrypting passwords
Encrypting passwords in .NET
Salt
Salt: Secret or public?
Hash iterations
I use the sha hash of the username, a guid in the web config, and the password, stored as a varchar(40). If they want to brute force / dictionary they'll need to hack the web server for the guid as well. The username breaks creating a rainbow table across the whole database if they do find the password. If a user wants to change their username, I just reset the password at the same time.
System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(
username.ToLower().Trim(),
ConfigurationManager.AppSettings("salt"),
password
);
A simple hash of the password, or even (salt + password) is not generally adequate.
see:
http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/
and
http://gom-jabbar.org/articles/2008/12/03/why-you-should-use-bcrypt-to-store-your-passwords
Both recommend the bcrypt algorithms. Free implementations can be found online for most popular languages.
You can use multiple hashes in your database, it just requires a little bit of extra effort. It's well worth it though if you think there's the remotest chance you'll need to support additional formats in the future. I'll often use password entries like
{hashId}${salt}${hashed password}
where "hashId" is just some number I use internally to recognize that, e.g., I'm using SHA1 with a specific hash pattern; "salt" is a base64-encoded random salt; and "hashed password" is a base64-encoded hash. If you need to migrate hashes you can intercept people with an old password format and make them change their password the next time they log in.
As others have mentioned you want to be careful with your hashes since it's easy to do something that's not really secure, e.g., H(salt,password) is far weaker than H(password,salt), but at the same time you want to balance the effort put into this with the value of the site content. I'll often use H(H(password,salt),password).
Finally, the cost of using base64-encoded passwords is modest when compared to the benefits of being able to use various tools that expect text data. Yeah, they should be more flexible, but are you ready to tell your boss that he can't use his favorite third party tool because you want to save a few bytes per record? :-)
Edited to add one other comment: if I suggested deliberately using an algorithm that burned even a 1/10th of a second hashing each password I would be lucky to just be laughed out of my boss's office. (Not so lucky? He would jot something down to discuss at my next annual review.) Burning that time isn't a problem when you have dozens, or even hundreds, of users. If you're pushing 100k users you'll usually have multiple people logging in at the same time. You need something fast and strong, not slow and strong. The "but what about the credit card information?" is disingenuous at best since stored credit card information shouldn't be anywhere near your regular database, and would be encrypted by the application anyway, not individual users.
If you are working with ASP.Net you can use the built in membership API.
It supports many types of storage options, inlcuding; one way hash, two way encryption, md5 + salt. http://www.asp.net/learn/security for more info.
If you dont need anything too fancy, this is great for websites.
If you are not using ASP.Net here is a good link to a few articles from 4guys and codeproject
https://web.archive.org/web/20210519000117/http://aspnet.4guysfromrolla.com/articles/081705-1.aspx
https://web.archive.org/web/20210510025422/http://aspnet.4guysfromrolla.com/articles/103002-1.aspx
http://www.codeproject.com/KB/security/SimpleEncryption.aspx
Since your question is about storage method & size I will address that.
Storage type can be either binary or text representation (base64 is the most common). Binary is smaller but I find working with text easier. If you are doing per user salting (different salt per password) then it is easier to store salt+hash as a single combined string.
The size is hash algorithm dependent. The output of MD5 is always 16 bytes, SHA1 is always 20 bytes. SHA-256 & SHA-512 are 32 & 64 bytes respectively. If you are using text encoding you will need slightly more storage depending on the encoding method. I tend to use Base64 because storage is relatively cheap. Base64 is going to require roughly 33% larger field.
If you have per user salting you will need space for the hash also. Putting it all together 64bit salt + SHA1 hash (160 bit) base64 encoded takes 40 characters so I store it as char(40).
Lastly if you want to do it right you shouldn't be using a single hash but a key derivation function like RBKDF2. SHA1 and MD5 hashes are insanely fast. Even a single threaded application can hash about 30K to 50K passwords per second thats up to 200K passwords per second on quad core machine. GPUs can hash 100x to 1000x as many passwords per second.With speeds like that brute force attacking becomes an acceptable intrusion method. RBKDF2 allows you to specify the number of iterations to fine tune how "slow" your hashing is. The point isn' to bring the system to its knees but to pick a number of iterations so that you cap upper limit on hash throughput (say 500 hashes per second). A future proof method would be to include the number of iterations in the password field (iterations + salt + hash). This would allow increasing iterations in the future to keep pace with more powerful processors. To be even more flexible use varchar to allow potentially larger/alternative hashes in the future.
The .Net implementation is RFC2892DeriveBytes
http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx