I would like to ask if there is any possibility to do de-hashing with salt.
Because currently I using doing encrypt with salt and hash. But I want to study about de-hashing part, is it possible to do de-hashing ?
I'm assuming that by de-hashing, you mean reversing the hashing process.
Hashing is a form of one way encryption. The original message is entirely destroyed in the process of creating the hash and, therefore, it is not possible to reverse the process. If it is possible, then that is a problem with the hashing algorithm.
Or in more formal terms, Hashing algorithms, by definition, are not Bijective.
Related
hello I am new to java and i want to develop a simple login application where i have to store values in db. I have read many examples for encryption and decryption but i cant understand(may be because of complex english words) what is algorithm,key, padding and why we have to use getBytes(). Can you explain in detail with examples in simple english. Which algorithm,padding is best useful for encryption and decryption.Is key a predefined fixed word or can we set our own key. Code will be much useful.
Im kinda newbie on the subject so id just recommend hashing and salting the passwords, i cannot offer much more insight, but i found this video which i found to be quite extensive and interesting on the subject, and iirc he even shows some code samples and examples, i recommend starting from there and come back with doubts from that!
The general gist of things is getting the original password string, and generate a random string with it, concatenating both, then hashing the combined form of those and storing the hashed form of both and the random string, then, when that person is going to login, you apply the same salt to the password inserted and compare it to the hashed form in your database.
This has advantages over standard hashing because the random string is unique per user, meaning all hashes, even from the same passwords, will be different, while in normal hashing, youd get the same hash for the same passwords, and thus, it would be easier to crack some if many users had the same password, which cant be done in this case, since every hash key is different.
So remember, generate random string, concat it, hash the concatted string, store the hash and the random string into the db, and compare on login.
I am actually nicely surprised, someone asked before doing it wrong way.
However what are you asking is quite broad for a single answer. I'd advice to take at least some basic course on cryptography (I'd recoment the Coursera. Even if you don't finish your course, you will get pretty good basics what and why you shoud or should not do.
simple login application where i have to store values in db
If the values you mean user passwords, then use slow salted hash, please read https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
If you want to encrypt some values reversibly, there are plenty examples around, though not all are secure,
Code will be much useful
you may check
https://gusto77.wordpress.com/2017/10/30/encryption-reference-project/
what is algorithm,key, padding and why we have to use getBytes().
I will start with the bytes. Encryption works with byte arrays. So for any text you need to convert your data, keys, passwords,.. to byte arrays. As well the encrypted data are byte arrays.
For the algorithm, padding,.. I really advice you to learn about it a little more yourself.
There are ciphers (algorithm) which are considered secure today, it is more important that you use them properly.
Just for an example, commonly used is AES/CBC/PKCS5Padding
AES - cipher (encryption algorithm)
CBC - mode of operation
PKCS5Padding - padding to fit data into required block length
.Is key a predefined fixed word or can we set our own key.
Key is your secret value, you need the same key to decrypt encrypted data, but the key is yours, the best if it's random
The current top-voted to this question states:
Another one that's not so much a security issue, although it is security-related, is complete and abject failure to grok the difference between hashing a password and encrypting it. Most commonly found in code where the programmer is trying to provide unsafe "Remind me of my password" functionality.
What exactly is this difference? I was always under the impression that hashing was a form of encryption. What is the unsafe functionality the poster is referring to?
Hashing is a one way function (well, a mapping). It's irreversible, you apply the secure hash algorithm and you cannot get the original string back. The most you can do is to generate what's called "a collision", that is, finding a different string that provides the same hash. Cryptographically secure hash algorithms are designed to prevent the occurrence of collisions. You can attack a secure hash by the use of a rainbow table, which you can counteract by applying a salt to the hash before storing it.
Encrypting is a proper (two way) function. It's reversible, you can decrypt the mangled string to get original string if you have the key.
The unsafe functionality it's referring to is that if you encrypt the passwords, your application has the key stored somewhere and an attacker who gets access to your database (and/or code) can get the original passwords by getting both the key and the encrypted text, whereas with a hash it's impossible.
People usually say that if a cracker owns your database or your code he doesn't need a password, thus the difference is moot. This is naïve, because you still have the duty to protect your users' passwords, mainly because most of them do use the same password over and over again, exposing them to a greater risk by leaking their passwords.
Hashing is a one-way function, meaning that once you hash a password it is very difficult to get the original password back from the hash. Encryption is a two-way function, where it's much easier to get the original text back from the encrypted text.
Plain hashing is easily defeated using a dictionary attack, where an attacker just pre-hashes every word in a dictionary (or every combination of characters up to a certain length), then uses this new dictionary to look up hashed passwords. Using a unique random salt for each hashed password stored makes it much more difficult for an attacker to use this method. They would basically need to create a new unique dictionary for every salt value that you use, slowing down their attack terribly.
It's unsafe to store passwords using an encryption algorithm because if it's easier for the user or the administrator to get the original password back from the encrypted text, it's also easier for an attacker to do the same.
As shown in the above image, if the password is encrypted it is always a hidden secret where someone can extract the plain text password. However when password is hashed, you are relaxed as there is hardly any method of recovering the password from the hash value.
Extracted from Encrypted vs Hashed Passwords - Which is better?
Is encryption good?
Plain text passwords can be encrypted using symmetric encryption algorithms like DES, AES or with any other algorithms and be stored inside the database. At the authentication (confirming the identity with user name and password), application will decrypt the encrypted password stored in database and compare with user provided password for equality. In this type of an password handling approach, even if someone get access to database tables the passwords will not be simply reusable. However there is a bad news in this approach as well. If somehow someone obtain the cryptographic algorithm along with the key used by your application, he/she will be able to view all the user passwords stored in your database by decryption. "This is the best option I got", a software developer may scream, but is there a better way?
Cryptographic hash function (one-way-only)
Yes there is, may be you have missed the point here. Did you notice that there is no requirement to decrypt and compare? If there is one-way-only conversion approach where the password can be converted into some converted-word, but the reverse operation (generation of password from converted-word) is impossible. Now even if someone gets access to the database, there is no way that the passwords be reproduced or extracted using the converted-words. In this approach, there will be hardly anyway that some could know your users' top secret passwords; and this will protect the users using the same password across multiple applications. What algorithms can be used for this approach?
I've always thought that Encryption can be converted both ways, in a way that the end value can bring you to original value and with Hashing you'll not be able to revert from the end result to the original value.
Hashing algorithms are usually cryptographic in nature, but the principal difference is that encryption is reversible through decryption, and hashing is not.
An encryption function typically takes input and produces encrypted output that is the same, or slightly larger size.
A hashing function takes input and produces a typically smaller output, typically of a fixed size as well.
While it isn't possible to take a hashed result and "dehash" it to get back the original input, you can typically brute-force your way to something that produces the same hash.
In other words, if a authentication scheme takes a password, hashes it, and compares it to a hashed version of the requires password, it might not be required that you actually know the original password, only its hash, and you can brute-force your way to something that will match, even if it's a different password.
Hashing functions are typically created to minimize the chance of collisions and make it hard to just calculate something that will produce the same hash as something else.
Hashing:
It is a one-way algorithm and once hashed can not rollback and this is its sweet point against encryption.
Encryption
If we perform encryption, there will a key to do this. If this key will be leaked all of your passwords could be decrypted easily.
On the other hand, even if your database will be hacked or your server admin took data from DB and you used hashed passwords, the hacker will not able to break these hashed passwords. This would actually practically impossible if we use hashing with proper salt and additional security with PBKDF2.
If you want to take a look at how should you write your hash functions, you can visit here.
There are many algorithms to perform hashing.
MD5 - Uses the Message Digest Algorithm 5 (MD5) hash function. The output hash is 128 bits in length. The MD5 algorithm was designed by Ron Rivest in the early 1990s and is not a preferred option today.
SHA1 - Uses Security Hash Algorithm (SHA1) hash published in 1995. The output hash is 160 bits in length. Although most widely used, this is not a preferred option today.
HMACSHA256, HMACSHA384, HMACSHA512 - Use the functions SHA-256, SHA-384, and SHA-512 of the SHA-2 family. SHA-2 was published in 2001. The output hash lengths are 256, 384, and 512 bits, respectively,as the hash functions’ names indicate.
Ideally you should do both.
First Hash the pass password for the one way security. Use a salt for extra security.
Then encrypt the hash to defend against dictionary attacks if your database of password hashes is compromised.
As correct as the other answers may be, in the context that the quote was in, hashing is a tool that may be used in securing information, encryption is a process that takes information and makes it very difficult for unauthorized people to read/use.
Here's one reason you may want to use one over the other - password retrieval.
If you only store a hash of a user's password, you can't offer a 'forgotten password' feature.
I've been experimenting with some basic cryptography techniques in Java (my preferred programming language) and have a simple example that uses modular exponentiation to generate a shared secret between two client pairs.
But, given a shared secret, what are some simple-to-implement (yet secure) methods for actually using this secret to encrypt/decrypt or scramble/unscramble data being sent over the wire?
For example, if I have the String:
"So long, and thanks for all the fish"
And the shared secret (BigInteger):
1110278255331388386297296974141977
How can the String be sent over the wire in a way that allows for the clients to understand each other, while ensuring that without the shared secret, no middle man can interpret it?
I'm not asking for a finished implementation, just ideas or references to algorithms/techniques that can be used. I'm also avoiding relying on existing programs or APIs (like public/private keys) since this is just a side project for my own educational purposes.
There is a standard way of doing what you are after and that is called password-based key derivation. You need to use a secure symmetric encryption algorithm. You can of course go for asymmetric ones like RSA, but with a shared secret, that is redundant.
However, you don't want to use your shared secret directly.
Your shared secret may have an inappropriate size to be used as a key. For example, AES, as a good choice, accepts 128-bit and 256-bit keys and the shared secret may not be a good match.
The key for your symmetric algorithm of choice should be secure enough, which means that it should have a secure level of randomness which your shared secret may lack.
This is exactly the case algorithms like PBKDF2 (password-based key derivation function 2) are invented for. PBKDF2 is already implemented in standard java and you may use it. It generates a secure key with arbitrary size based on a "passphrase", which is simply the shared secret in this case. These family of algorithms have a iteration parameter, which indicates how many times a hash function is applied to derive the key. Make sure to set it to a high number like a few thousand.
I should note though that security (confidentiality and integrity of transmitted data) in this cases relies on your shared secret to be actually secret. I don't know how you are generating it, but you need to make sure that the process is secure. Diffie-Hellman Key Exchange is a good example. If you are not familiar with this, I recommend you to take a look and see what is does to ensure that the process is safe.
As it is already stated in the comments, you don't need to (and also should not) innovate in cryptography for a practical application. You will find anything you need already implemented and proven secure. Take my last sentence with a grain of salt though.
I try to implement a SHA1 decoder but i can't find something usefull on internet. Can anyone help me find information on how I can implement an SHA1 decryption. I want to transform the encrypted data to Strings.
I try to implement a SHA1 decoder but i can't find something useful on internet.
SHA-1 is a hash function. It's one-way: you hash the data, and get a hash. If you hash the same data, you'll get the hash; if you hash different data, you'll "almost certainly" get a different hash.
If you could "decrypt" it, it wouldn't be doing its job.
If you figure out how to crack sha1 props to you. I think the government may be able to do it but you would be hard pressed to find a public library that has a smart algorithm that doesnt take a great deal of resources to crack.
they claim they can crack it and decrypt it, I doubt it works
another source that claims they can decrypt it, i doubt their code is publicly available though
Is there a specific reason you are trying to decrypt it, maybe there is a flaw in your design or another way to solve your problem?
heres a neat diaolog about the progression of sha1
Hash functions are designed to be one-way. So you can't simply calculate the input from the output. Doing this is called a pre-image attack. If the message itself can't be guessed, such an attack requires around 2^159 attempts, which is infeasible.
The best way to reverse SHA-1 is to guess the input. For typical user passwords this attack succeeds quite often, since the password isn't complex enough. For example a typical GPU will be able to try >100mio passwords per second.
This is why we don't use plain SHA-1 for password hashing. We use deliberately slow schemes, such as PBKDF2, bcrypt or scrypt with sufficient work-factor.
If you need to find the password behind a SHA1 hash, put the Hash on google.
If the password is common, and the hash is not 'SALTED', you have a chance to get the password.
Else read this:
https://en.wikipedia.org/wiki/Rainbow_table
I implemented Diffie–Hellman key exchange in Java with some large groups from RFC 3526. My output is a fairly large array of bytes. Is it safe to use the first 448 bits (56 bytes) of the output for a blowfish key? Should I transform the bytes in any way, or pick any specific bytes for the key?
From a theoretical point of view, no, it is not safe. Not that I could pinpoint an actual attack; but the output of a Diffie-Hellman key exchange is an element of a group consisting in q elements and offering sqrt(q) security at most. Truncating parts of the encoding of that element does not look like a good idea...
The "proper" way is to use a one-way key derivation function. In simple words, process the Diffie-Hellman output with a good hash function such as SHA-256 and use the hash result as key. Hashing time will be negligible with regards to the Diffie-Hellman step. Java already includes fine implementations of SHA-256 and SHA-512, and if you are after compatibility with very old Java implementations (e.g. the Microsoft JVM which was coming with Internet Explorer 5.5) then you can use an independent Java implementation of SHA-2 such as the one in sphlib. Or possibly reimplement it from the spec (that's not hard): FIPS 180-3 (a PDF file).
If you need more than 128 bits for your key then this means that you are a time-traveler from year 2050 or so; 128 bits are (much) more than enough to protect you for the time being, assuming that you use a proper symmetric encryption scheme.
Speaking of which: Blowfish is not really recommended anymore. It has 64-bit blocks, which implies trouble when the encrypted data length reaches a few gigabytes, a size which is not that big nowadays. You would be better off using a 128-bit block cipher such as the AES. Also, in any serious symmetric encryption system you will need a keyed integrity check. This can be done with a MAC (Message Authentication Code) such as HMAC, itself built over a hash function (then again, easy to implement, and there is a Java implementation in sphlib). Or, even better, use the AES in a combined encryption/MAC mode which will handle the tricky details for you (because using a block cipher properly is not easy); lookup CWC and GCM (both are patent-free; the latter has been approved by NIST).
The solution that you propose depends on whether the most significant bits of a Diffie-Hellman exchange are hard core. There are some small results known that show that the most significant bits are unpredictable, but I'm not aware of a paper that is strong enough to show that your approach is correct.
However, there are several proposals for a key derivation from Diffie-Hellman keys.
E.g. a nice paper is NIST SP 800-135. So far this is only a draft and can be found here. However, it reviews some existing standards. Of course, using a standard is always preferable to develop it yourself.
While Thomas Pornin's proposal looks reasonable it is nonetheless an ad hoc solution. And to be on the safe side you should probably not use it. Rather I'd use something that has been analyzed (e.g. the key derivation scheme use in TLS version 1.2).