I would like to write a series of encrypted questions and answers. Everything is encrypted except the first question. The user of the game must guess the answer to the question, perform some encryption method using a public key, and if the answer they guessed when encrypted is the same as the encrypted answer then they got it right.
Here's the tricky part, when the user gets the right answer, they must also get the private key to decrypt the next question. Is this possible or am I totally off base?
Ps I know that keys must be random
From my point of view 2 comments:
perform some encryption method using a public key, and if the answer they guessed when encrypted is the same as the encrypted answer then they got it right.
When you crypt something with a key (RSA) there are a part that is random so each time that you crypt a message can get a different value, so you have to check if there are in the library that you are going to use (openSSL?) to force this random part.
You can use a hashing algorithm (MD5, SHA1) that is a common way to achieve your goal
when the user gets the right answer, they must also get the private key to decrypt the next question
I guess that you try that question are not accessible unless you answer the prior question right. So you need to keep a key as secret, so it must be crypted maybe you can use the answer as a key (depending of algorithm that you use to crypt)
Related
Here's the problem, a string has been passed through three separate encryptions in the following order: Original -> Base64 -> AES-256 -> Blowfish (Keyless) -> Final. Write a method that takes this triple encoded string mystery_string = "OXbVgH7UriGqmRZcqOXUOvJt8Q4JKn5MwD1XP8bg9yHwhssYAKfWE+AMpr25HruA" and fully unencrypts it to its original state.
I looked into different libraries/documentation for aes256 and blowfish but all of them required a key. The only one that did not require a key was Base64 (i.e. Base64.encode64('some string') ). Not really sure where to go from here.
Firstly, the only way to crack AES-256 and Blowfish without the key is by brute force enumeration of every possibly 32-byte combination that could be used as the key. In theory, this means it's not crackable in our lifetime. There may be some vulnerabilities you could exploit as you also have the plain text, but I doubt you would have that in a real-life situation.
Second, and most importantly, just going by that site, encode-decode.comhttps://encode-decode.com/, you don't actually have enough information to decode the string even if you did know the password.
The various modes of operation for the AES256 cipher function requires either a 32-byte (or sometimes a 64-byte) key. The secret that you used (you may have just left it blank) needs to be converted into a 32-byte encryption key. This is done using a hashing algorithm, but we don't know which one is used. Hopefully, the site used a key derivation function, which provides several security benefits. However, key derivation functions require multiple parameters, and we would need to know what parameters to enter along with our secret to get the right encryption key.
Finally, we don't know if the secret is being concatenated with a salt before being hashed. Without knowing if a salt is used and what the salt is, we cannot determine the correct 32-byte key used to encrypt the plain text.
In summary, the answer to your question is: No, there is not a quick way to decrypt that string without knowing the key.
However, encryption is an awesome topic to learn.
I'd encourage you to look over the ruby docs for the OpenSSL library. They're actually quite good (besides the don'ts I mention below).
The PBKDF2 Password-based Encryption function is one of the key derivation functions I was referring to.
When encrypting with AES, you will most likely want to use AES-256-GCM which is authenticated encryption.
A couple of don'ts:
Don't use ciphers at random... understand their strengths and weaknesses
Don't use AES-128-EBC - explination
Another good encryption library is rb-NaCl.
Alright, here's the story:
I'm getting married soon, and I'd like to create a website (or an app).
Obviously, I'd like that only guests could access to it.
So I was thinking about a system where it would require a security code to sign up.
The problem is that I do not trust anyone not to be silent about the code, so I was thinking about giving a different code for every couple (or family) of invited people.
On the sign up form, I would then verify that the entered code has not already been used.
But since I don't know who will sign up to the app, and I don't really have time to manually register each guest, I won't have a database with what code has been provided to whom information.
So, I need an algorithm to generate a random security code, and the reversed one, to check if a given string is a validate security code
I need the algorithm to be complex enough so people could not guess what's the magic behing the code they received. (I know, it feels pretty paranoid)
The generated Securiy Code should be pretty simple, like 6 to 8 characters (mix of digits, upper and lower case letters)
The main issue is that I have no clue how to perform a reliable system to generate and validate a security codes.
I feel like I should have a secret key stored on the server side, that would be necessary to generate a code, and I would have to find it back if a given string is a valid code.
Let's say secret is my private key.
The generation algorithm would be something like secret + whatever = generated code (where the + whatever operation remains to define).
But then how could I check a given string? string - whatever =? secret would be the solution (where - whatever is the reverses operation of + whatever).
Well, I actually have no clue of what whatever could (or should) be.
Do you have any advice or guidance ?
For the technical part, I will probably code this in JS (with a NodeJS server).
But as I'm talking about the concept of security code generation, any pseudo-code will do the job.
Generate a hash of the person's email address (capitalized) and make the code the first n-characters. So, for example, if your email address is TOUPYE#GMAIL.COM then the SHA-256 hash would be: 038122aedbf777b8c7c3aaed14ae7c08249a9d47f82f4455a0d667cacc57d383 so your code would be "038122". Generate a list of codes for each person/family. If someone has no email address use the telephone number. If they do not have a telephone, use their address.
okay I am trying to make a log in form to my website in C# it has md5 + salt.. the problem is salt. md5 I can make work but salt just won't work. I made a php that gets the user name, user group id's etc. I have removed tons of instances of salt in the db and it either destroyed log in, or just did nothing. I am wondering if there is an easy way to remove salt?
What do you think is the purpose of the salt? If you could easily remove it, what would have been the reason to add it? You should really take a few minutes to read a tutorial about password hashing.
MD5 is not an appropriate choice to hash passwords, because it is ways too fast. One can calculate 8 Giga MD5 values per second with common hardware nowadays, that makes brute-forcing too easy. Instead use a slow key derivation function like BCrypt or PBKDF2.
To answer your question, you need the stored salt to verify the user entered password. If the user enters the password for login, you calculate a hash with the same salt you used to calculate the stored password in the database, then you can compare the hashes.
What is safer?
I can use either one as I'm using CodeIgniter, but with Sha1, I can't reverse if I ever needed to for some odd reason like I can with encryption.
But I'm still somewhat new to PHP, so if there is a way I can possibly do something like display the sha1 hashed password as stars, so if say your password is "lala123" it would show this to me: "*******" and never ever be able to be shown "lala123", is it possible to do that with sha1? If so, please help me, otherwise I'll use encryption, but only if it's safe to use for passwords. Please let me know :)
Hashing is considered more secure for the very reason that even you cannot restore the password. If you password database is compromised, and the password encryption is reversible, the baddie might decrypt them, especially if the code that does the decryption has been compromised as well. SHA1 is not reversible by design.
You're not supposed to display the password in the UI - ever. The * are just that - an arbitrary number of stars. Disclosing the length of a user's password constitutes in itself a considerable hint to a would-be guesser.
Neither. You should use hashing to keep the passwords secure in case someone gets the password database. But the consensus answer seems to be to use bcrypt, described in this answer. It is a hash function based on blowfish with variable cost so you can tune security versus performance.
Upfront, I'd like to confess to being a complete newbie to cryptography and password security. I'm trying to store passwords in a database being babysat by ruby. My understanding is that plaintext passwords should be appended to a random "salt" and that whole phrase should be hashed by some hashing algorithm such as:
Digest::SHA1.hexdigest(salt_plus_plainpassword)
Once that string is stored in the database, how does one get it out again to verify that what the user entered is correct if there was a now unknown random salt appended to it?
The best way to do it is to store the salt is one for each user and it is generated based on the Time at the point they did it.
It's true that once a person has access to your database they can see the salt for users, but if this has happened you have bigger things to worry about.
The way you check your user's password is that you take their clear text input and crypt it with the salt and then compare the crypted_passwords, if they match they are authenticated. I don't believe that storing the salt is an issue as you will need it. If you are worried about SQL injection attacks you are better off securing your application against them rather than not storing information you need, in this case each users salt.
Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.
But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!
If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...