I'm building a simple trivia game that has "hangman" style clues (where letters are revealed as the player asks for hints). I don't want to flat out send the answer with the question any user with sufficient smarts could figure it out) - rather I'd like to encrypt answers on the server and decrypt them on the client. Security isn't of huge importance I just want to make the process harder then it's worth for players. I was wondering if anyone could recommend a strategy for doing this?
A simple approach, which might be sufficiently difficult for most users, would be to send the answer and encryption key to the web client (as hidden form fields), and use Javascript to decrypt it on the fly (inside the browser). A simple exclusive-or'ing of the answer string characters with the key string should be sufficient to "shroud" the answer without requiring large amounts of crypto processing on the client side. Using more than one key string might increase the difficulty of cracking it, too.
I'm assuming that you don't want to implement full commercial-grade crypto on the client side, and also assuming that you only want to hide the answers for a few minutes at most.
Related
sorry if there is an answer to this somewhere, but I could not find a clear explanation.
If I need to encrypt a sensitive field before storing it in my db, can the following approach possibly work?
I write a hard-coded encryption-cipher algorithm (in my php file) without any random behavior, like shuffling a deck of cards in a certain sequence, but only I know the exact sequence. I then also write the exact opposite algorithm to de-crypt the ciphered field, thus (hopefully) eliminating the need for a decryption key.
My understanding is that only the resulting string will be exposed to http(s) traffic and even if the result is posted back it is over https.
Can this approach work?
I have a little background of cryptography so forgive me if this is a silly question. Is there a secure way to encrypt a text using AES that produces the same output with the same input?
Edit
What i want is to store emails in a external analytics provider using AES256 or HMAC 256 (this is a company requirement). But i need to be able to decipher them lately and to distinguish between same emails without deciphering them. I know i can do this with two entries, one with AES and another using HMAC. But can i do this with AES alone and still be secure?
Yes and no. There is a mode called ECB, "electronic code book", that will always produce the same output (cipher text) for a given input (plain text) block.
However, unless you only send each plain text block one time, ECB is not secure. At first, an adversary who intercepts an encrypted message won't be able to decipher it. But, just like old time code books, as they continue to monitor encrypted messages and combine that with knowledge of the context in which they were sent, they can eventually break much of your code.
Use of ECB is generally discouraged. For most messaging applications, an AEAD mode like GCM is recommended.
I realize this question maybe subjective, but I'm fairly new at this and while there is A LOT on this subject. I’ve yet to be able to form a good opinion on this and I'm thinking that maybe due in part that because I'm new I can only think in terms of my project, which isn’t anything out of the ordinary.
So I’m asking in my environment what is the best option for authentication? What method is best sessions? cookies? Something else? Also how do you save passwords in a table safely? I researched data types, but that seem to yield any help. Is there something special that you have to do the table and/or column? Eventually I would love to add other authentication methods to my site {ie Facebook, Google, OpenID}, but I think I need to understand this first.
My environment is ASP.NET with the code behind in VB. I am using MSSQL 2005 (But have access to 2008 if need be).
Thanks
Josh
I'm not familiar with ASP, so I can't answer you on how best to communicate and keep the credentials throughout the session. It sounds like using the built-in membership system, as others have suggested, is the safest approach. I totally sympathize, however, with your desire to do things yourself and understand how they are working under-the-hood. If you do want to tackle doing this yourself, I can speak to the database side of things.
If at all possible, don't ever store the actual password anywhere. You should only be storing an irreversibly-encrypted value generated from the password (using a hash-encryption algorithm such as SHA512Managed). To authenticate the user, rather than decrypting the stored password and comparing the two plain-text passwords, you want to encrypt the entered password and then compare the two encrypted values. If you store the actual password, even if it's encrypted with a reversible-encryption algorithm, it is a big security risk.
Also, if you are using an encryption algorithm that allows you to specify a seed value, you should use an algorithm to generate the seed value based on the original password. You don't want to use the same encryption-seed value for every password.
Also, most encryption methods are designed to be fast so that they can be used for communication streams. However, if they are fast, that means someone can brute-force crack them more quickly. Therefore, the best method for making your encryption safer is to make them as slow as is reasonably possible. Often this is accomplished by re-encrypting the encrypted value over and over again in a loop for a fixed number of times.
I'm trying to encrypt a string in javascript and then decrypt it back in server using c#. I thought of using System.Security.Cryptography.Rijndael on server side and some AES implementation like this or this on client-side.
I don't know much about cryptography, so basically I generate a key and send it to client and encrypt my text with that key and send it back to server.
My problem is that Javascript AES implementations use a key to encrypt a text but c# Rijndael class uses a key and a vector. where does that vector come from?
AES is just a block cipher, which is a cryptographic primitive. Its purpose is to encrypt one single block of data (16 bytes).
Encryption requires a lot more than that. You need a method to encrypt an arbitrary amount of data, and hopefully in a way that doesn't give away any information. To do this, you need to break the amount of data into blocks, pad the last part to a full block, and then somehow encrypt each block in a clever way. Doing that is the responsibility of the encryption mode.
The most trivial mode (electronic cookbook, ECB), just encrypts each block with the same key, but that's horribly dangerous. Other modes require some sort of initialization state, which needs to be random but can be publicly known.
To encrypt and decrypt your data, you must know both the block cipher and the encryption mode, on both sides, and you must find a way to generate the initial state on the encrypting side and to recover it on the decrpyting side to initialize the encoder and the decoder, respectively.
In a nutshell: You need a lot more information about what you're doing!
This isn't perhaps exactly what you are looking for. But I can think that what you actually need to do is implement SSL.
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
This might solve your problem without needing to get involved with coding cryptography.
I want to ask for a mature model to do this.
Suppose I want to deliver a program and a sensitive data file to user. The program is able to read any data stored in the data file, but user is not allowd to easly break the data file. The data file will be encrypted by standard algorithm such as AES. Now, the problem turns to how to manage the key. Putting the key in the program seems to be a bad idea, but what else I can do? Apparently I can't give the key to user directly.
There is no way to do this securely, ie. to really prevent the user from reading the data. As long as they have the data and they have the program that can read it a competent disassembler will be able to figure out how the program reads it and do the same thing. Or, even easier, they could let the program do it and then get the decrypted version out of its memory.
Having said that, if you just want to prevent the average user from doing it, hardcoding the key in your source code should be fine. :) Just be realistic about the level of protection this provides.
Does it have to be pure software? If not, you could look at a solution which does decryption and storage of the key on a hardware device, e.g. a USB dongle.
You can also potentially prevent the whole problem by having your software retireve the data from a web-service instead of a data file. In this case you can control access to the data much more tightly (i.e. who gets how much of what and when). This might or might not work for your application.
Otherwise as others pointed out, there is no known good pure software solution.
There is no 100% safe solution to this because at some point you have to have the key loaded into memory so that de/encryption can take place and a savvy-enough hacker will be able to capture it. The best you can do is to make it very difficult to capture and to mitigate exposure to data (by limiting access as much as possible) if the key is compromised.
As far as how to make it safer... you could have a combined key that is made up of something stored in the program and something derived from the user's passcode?
Is your perceived user determined? are they skilled enough to do reverse the application or the key? If the user is considered to just be a generic desktop user you probably could implement a partial key using some general encryption just to make the key non obvious, beyond that a determined individual will be able to reverse must simple means of encrypting keys and data.
A DVD John conundrum, eh? Why is having a key in the program bad? You could have a super-obscured function which computes it reliably once. Someone with disassembler and debugger can break your key given enough time, IMO.