I know enough about cryptology to make life difficult for a novice programmer and get laughed at by security experts. So with that in mind, I ask: how secure is javax.crypto.Cipher? I realise that anything can be cracked by someone with a will and a way, but I still would like to know relative details.
The reason I ask is I would like to store account names and passwords that will be sent through my Cryptor class that will encrpyt them, and would like to know if this will do the job. If any one has any literature that I could read, that would be greatly apprieciated.
Thanks ~Aedon
Cipher is a generic class to apply an encryption/decryption algorithm. Its security depends on the actual encryption algorithm used (DES, triple-DES, AES, etc.), on the size of its key, and on the block chaining type that you choose.
If you intend to store passwords securely, then your requirements are quite different from simply "communicating securely/privately". A Cipher on its own is not enough to protect you. You need to use one of these
bcrypt
scrypt
PBKDF2 from PKCS#5
in that circumstance. Here are some arguments and links concerning password security.
The punchline is that "normal" encryption (or hashing, too) is just way too fast to hold off serious attackers. You want to artificially slow down the entire process to make it as hard as possible for somebody systematically attacking your application. A single user won't notice the difference between 1 or 500 milliseconds when entering a password but for an attacker this means that in order to break your scheme it will take them 500 times as long on the average - so if it would have taken roughly 1 month to find a valid password before, now it will take 500 months.
Since NullCipher is a Cipher - not secure at all.
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
Just a quick question about the use of encryption for app data.
Say you have a mobile app, this app needs to store some potentially sensitive data. In this case, a list of corporate ip addresses that need to be kept hidden.
The obvious answer would be to encrypt with the hash of a user's password. However in this case, a user account is optional and so a password may not exist. What would be the next best method of encrypting the stores data?
My first guess and probably the least secure is a key built into the application, but issue here is risk of different attacks that could see that password recovered.
Next guess would be finding some sort of identifier of the device that can be used as a seed for a password generator. Again seems like a flawed method.
Last idea is to securely randomly generate the password and store it encrypted with one of the above methods.
Am I following the right train of thought or am I way off?
I have a decent understanding of cryptography algorithms but finding the right application has me scratching my head. Any help would be much appreciated.
Thank you
The point is: as long as your data only resides on the mobile device, in the end, you are limited. In that sense: if you need to store information in a secure and reliable way, then you should consider a "server side" solution.
If that isn't possible, the next best thing is to have your app ask the user for a distinct password - which is then used as key as outlined in your question. You definitely do not want a single generic key that works for all users/devices.
But of course - asking the user to type a special password each time he wants to use the app will not be a solution your users will like. So you will have to offer the user to store that password somehow - which again increases the range of potential attacks.
Long story short: without a "remote" service you simply have to balance "user experience" with "enough security". Depending on your user set, you have to determine what is more crucial to these people - security or convenience.
Next guess would be finding some sort of identifier of the device that can be used as a seed for a password generator. Again seems like a flawed.
--- ?
You can encrypt it with the hash of ANDROID_ID or UUID in place of password
What's your opinion on this?
I'm creating a register method in vertx which use Bcrypt to encode password in database.
My problem came from the slow performance in encoding password using BCrypt.
When im using :
- Bcrypt my query take around ~1200ms
- Whitout Bcrypt ~220ms
So what can i do to improve performance ? Is there antoher way to encode password in VertX ?
i'm using Bcrypt (http://www.mindrot.org/projects/jBCrypt/) in vertx.
As you stated: that's not a Vert.x issue/problem. The BCrypt algorithm takes an X amount of time to encode/encrypt a given value — and it's slow on purpose.
I guess you can leverage on the Vert.x capabilities and have N instances of "worker verticles" doing the encryption work. Again, the time "won't shrink", but you will have "some dedicated guys" just for doing that — you can always tweak the number of instances to your needs. Maybe that's too much, but I'm just throwing it in case you haven't thought about it.
Moreover, I think using BCrypt is (one of) the way(s) to go; it's a one time operation and later on "checking" a given value it is not-so-time-consuming. Additionally, it will give you a better/strong security compared to other (hashing included) algorithms if you use the proper salt size, jadda, jadda.
Note that BCrypt is slow on purpose (see e.g. here: Bcrypt for password hashing because it is slow?) so it is not a "bug" but a feature.
(as mentioned in the link, the slowness adds to extra security - it is slower to brute-force the password)
So you really should think twice before wanting the BCrypt password encryption to be fast.
Honestly, that is probably the best way. BCrypt does a better hash encoding. The faster algorithms aren't nearly as good and certainly don't future proof whatever system you are making. But yes, you can use MD5 and it'll go much faster.
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'm trying to write a simple password manager in java. I would like to encrypt the file with the stored passwords using AES 256 bit encryption. In addition I would like the user to be able to decrypt the file with a password. When reading other posts online almost all of them stress that it is not secure to simply use a password as a key, they mention using random salts to add security. But I do not understand how I can use random salts when generating the key. If I create the key from the user's password and a random salt then when they try to decrypt their file how will I know what the salt was? This has me completely confused.
Currently I run their password through several different hashes using a constant salt at each step. Is this sufficiently secure or I am I missing something? Any help on how to securely generate a key from a password would be greatly appreciated! Thanks in advance.
Remember that a salt isn't a secret. You can just append it to the encrypted data. The point of the salt is to prevent somebody from using a pre-computed dictionary of common pieces of data encrypted with common passwords as a way into "cracking" the encrypted file.
By making sure that the salt is random and combining it with the password, you remove the possibility of a dictionary attack because there's (effectively) no chance that a hacker will have a database of data pre-encrypted with your "salt+password". (As a starter, see this page, from one of my tutorials, on salts in password-based encryption.)
You also (effectively) eliminate the problem of collisions: where using the same password on two files may give an attacker a clue to the content if the same block of data occurring in both files looks the same in the encrypted version.
You still usually need to take other precautions, though, simply because a typical password doesn't usually contain much entropy. For example, 8 perfectly random lower case letters will generate about 40 bits of entropy; 8 lower case letters obeying typical patterns of English will generate about 20 bits of entropy. In other words, of the 2^256 possible keys, in reality typical users will be choosing among some small fraction in the range 2^20-2^40. In the case of a savvy user, the situation gets a little better, but you will be very unlikely to get close to 256 bits of entropy. (Consider that in a "pass phrase", there'll be about 2.5-3 bits of entropy per character, so a 30-character pass phrase gives you about 75 bits of entropy-- and let's be honest, how many people use anything like a 30 character password?; 8 perfectly random characters using the 'full' range of printable ASCII will give you a little under 64 bits.)
One way of alleviating this situation a little is to transform the password (with salt appended) using a computationally complex one-way function so that it will take a hacker a little longer to try each key that they want to guess. Again, see this page for more details.
To give you a rough idea of the pitfalls of password-based encryption of files, you may also want to have a look at the Arcmexer library I wrote a couple of years ago, which includes a method named isProbablyCorrectPassword(). Combined with a dictionary/algorithm for generating candidate passwords, you can use it to gauge the effectiveness of the above methods (since ZIP file encryption uses a combination of these techniques).
Use this library: http://www.jcraft.com/jsch/
There's a good AES example ere:
http://www.jcraft.com/jsch/examples/AES.java.html
A lot of big names use this package, Maven, Eclipse, etc.