I am encrypting an string with PBEWITHSHA256AND128BITAES-CBC-BC using SealedObject and write it to a file. After encrypting when i do a cat on the resulting file i i get read the salt used and the algorithm used in plain text even though the actual data is encrypted.
Doesn't that give crackers a head start? They know the salt and the algorithm with basically zero effort.
The salt isn't secret. Its purpose is generally to prevent dictionary attacks.
Keeping the algorithm secret is security through obscurity, which is pretty much universally discouraged.
When you use PBE (Password-Based Encryption), salt and iteration are just to make cracking more expensive. You only need to generate key once but guessers will have to try millions.
If you require salt to be secret, it defeats the purpose of the password. Password is something easy to remember but less secure. If you really worried about security, don't use password. Use a secret key.
Hiding salt is practically a double key scheme. In most cases, it doesn't make your cipher much stronger.
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 am creating an REST based web application which, after successful user credentials validation, generates auth token and authenticates subsequent requests using this auth token.
The contents(although not fixed yet) of token are
AES_encrypt{username:SHA_256(username,user_specific_salt):timestamp:expiry_period}.
To avoid db call, I am trying to generate salt value based on username itself.
Also, I am not sending salt value to client.
The problem is, I am a bit confused about the solution since the articles I have read so far suggest not to generate salt values on the fly but store at db level. Can someone help me figure out the optimal solution for the above scenario?
It depends on the use-case and level of the security concerns. Having safely stored passwords hashes is of course more important and sensitive than for example authorisations tokens for a web-service of limited functionality.
So the analysis is based on potential risks/benefits of particular solution.
Firstly, look what would happen if you were not using salting at all. Then if someone captures your token and knows its structure (username plus timestamp) may try to recover the key used for the encryption. It is a computational challenging task but in principle possible. Having access to only one or many tokens generated in the same way does not make this task much easier (I may be mistaken, they may be some loop holes in the AES encryption).
The aim is to get your key used for the encryption so that attacker may produce its own valid token for arbitrary user later on.
hacker needs to crack the key
You add a salt, even a fixed one for all the users.
Hacker still has to crack you encryption key, same as before. Once it has it
He takes old token, and updates the timestamp and the job is done. He just copies the original hash. as the timestamp was not hashed useing the salt, so it is not affected.
So lets assume you hash username+salt+timestamp. Otherwise salting is irrelevant as explained above.
So the hacerk needs to crack the salt so it can reproduce the correct hash. Having multiple hashses encoded with the same salt makes it easier to recover the salt. SHA is fast enough to allow brute false attacks nowadays.
hacker needs to crack the key
hacker needs to get one salt from all the hashes
By salting you introduced one extra step for the hacker to deal with but not a difficult one.
You add on the fly generated salt,
Hacker cracks the encryption. Then he needs to crack multiple hashes to recover few salts. He needs to guess the salt generation pattern to fake the token.
hacker needs to crack the key
hacker needs to recover multiple salts from the hashes
hacker needs to deduce the salt generation pattern.
Knowing the pattern it can produce the tokens for any user. Without knowing the pattern it can produced tokens for the cracked users, it is probably enough for the hacker.
Randomly generated salt stored in the DB, one salt for user.
hacker needs to crack the key
hacker needs to recover salt from the hashe
Hacker cannot create tokens for any user, but once knowing the salt it can create token for the hacked user. The DB stored salt does not improved things much, just prevent arbitrary user access but it still allows 'cracked' user access.
Randomly generated salt stored in the DB and changed regularly (hourly, daily).
Now hacking the salt once, does not help in the future, as it will not match the new salt value. Cracking hashes takes longer than hour. So hourly update should be enough. But tricky to implement it correctly, so that the valid tokens would not expire upon salt update.
So depending when you are on the scale of security paranoia and how important is your service you may step up the costs for the hacker.
I would say for your usecase, hashing with salt on the fly is completely fine just do add the timestamp to the messaged hashed, otherwise hashing has no effect.
Now, to prevent your secret key being discovered, you may considering salting our encryption key. That way if the encryption is cracked only for one user not all. But again if it is not banking applicaton, probably not worth it.
I am working on a system that has been hashing user passwords with MD5 (no salt). I want to store the passwords more securely using SHA-512 and a salt.
While this is easy enough to implement for future passwords, I'd like to also retrofit the existing MD5 hashed passwords, preferably without forcing all the users to change their passwords. My idea is to just use SHA-512 and and an appropriate salt to hash the existing MD5 hash. I can either then set some flag in the database that indicates which passwords were hashed from plain text, and which ones were hashed from an MD5 hash. Or I could just try both when authenticating users. Or even just hash new passwords with MD5 and then SHA-512/salt, so they can be treated the same as old passwords.
Programmatically, I don't think this will be a problem, but I don't know enough about encryption/hashing to know if I'm compromising the quality of the hash in any way by applying a SHA-512/salt hash to a password that was already MD5 hashed. My first instinct is that if anything, it would be even stronger, a very light key stretching.
My second instinct is that I don't really know what I'm talking about, so I'd better get advice. Any thoughts?
Function composition with cryptographic primitives is dangerous and should not be done if avoidable. The common solution for your type of problem is to keep both hashes for a migration period, using the new hash where possible and transparently upgrading old passwords (when you check a password and it matches, rehash it with the new algorithm and store it)
This won't work if you have a challenge-response based scheme where you don't get to see the plaintext password, but since you seem to have a stored salt that does not change, I assume your application does the hashing.
If you hash with MD5 first, you will only have the spread of MD5 (128 bit). A large fraction of the space of SHA512 will not be covered by your passwords. So you don't take advantage of SHA512, but it won't be worse than MD5.
You have the benefit that if someone obtains the SHA512 hash and doesn't know the salt (this you have to enforce somehow) can't look up the hashes and get the passwords -- something that would be possible with the MD5 database you have now.
So yes, you can just rehash the existing MD5 passwords. But as explained in the first paragraph, it would be a bad idea to apply MD5 to all new passwords as well and then hash them as SH512. A easy implementation would be to have a boolean 'salted' field in the database next to the hashes (but don't put the salt there).
Trust your second instinct. Use an existing library made especially for hashing passwords instead of trying to cook up your own.
Probably hash your new passwords with MD5 and then hash the MD5 with your password hashing library. That way, you can maintain backwards compatibility with your old passwords.
I.e. password_hash(All old, md5'd passwords) and password_hash( md5(New passwords) )
(Warning: I'm not a cryptography expert)
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
If you look at how most Bank and high security people does there password changing. Most of them basically ask people who is using the old encryption method to create a new password. I think you first solution of placing a flag on all existing old MD5 password users, and notify them they need to create new password and slowly migrate them to the new system. That way when you trouble shoot the system if anything goes wrong you won't be asking is this a new user or an old one. Are we double hashing or single? Should never compare two hash as a possible answer because what if MD5('abc') => 123, SHA('NO') => 123, that means someone could have typed in the wrong password but still gets in.
I decided to try BCrypt for hashing key for AES256 (Rijndael/CBC).
Problem is that AES256 key has to be 32 bytes long. BCrypt key is 60 bytes long and naturally always different. Maybe pretty hard and long week is to blame but I am not able to see how could I use a key hashed with BCrypt in combination with AES256. Am I just tired and blind or there is no way to do this?
Thanks
Are you trying to hash something (like a password) and use that as an AES Key?
I'm not familiar with BCrypt, but SHA-256 would create a hash that is the same size as an AES 256 key. Or if your bent on using BCrypt you could just read the first 32 bytes of that hash and discard the rest.
I don't think you should ever discard bytes from cryptography calculations, because those bytes are supposed to support the other bytes you kept - discarding some weakens the output.
What you need is a secure Key Derivation Function. Truncating the bytes as suggested in the comments works sometimes, but it always depends on the context, so don't do it if you're not absolutely sure about it.
Truncating won't work anyway in situations where you need to "stretch" your input, it's also where the most mistakes are made. If you can't create your key using a secure random generator, typically, what you want to do is transform some non-random input (e.g. password) into something worth as key material. Obviously, the entropy of non-random data is normally not good enough for the purpose.
Look into PKCS#5 and use its PBKDF2 if you want to transform passwords into arbitrary-length keys for AES or any other symmetric encryption algorithm.