New answers tagged

6

PBKDF2, scrypt and bcrypt are all configurable; they can be made as slow as you want. The limiting point is not the computer, but the user's patience. For example, suppose that the user will go irate if the password processing (e.g. to unlock an archive file) takes more than 6 seconds. If you use bcrypt only, then you can tune it up so that it takes 6 ...


0

Highly dependent. After a certain point encryption just doesn't become worth it. No matter how secure you can make it. Just because technique X is more secure than technique Y if the data ever gets stolen is a horrible argument for it because in the first place you should have had the proper security in place to make sure it couldn't be stolen in the first ...


2

No, as you have seen, the salt is part of the resulting hash value (the 22 characters after the cost factor). The BCrypt.Verify() function will extract the salt from the stored hash, so it is pointless to store it separately. You can call the function with only one parameter, the library will then generate a salt and the cost factor on its own: string ...


-1

I have learned a lot with this thread, so I thought in a way to easily understand the possible outcome when combined different methods (of course, it won't fit all cases): [W=weak, S=strong]: Formula | Example ---------------|----------------- W(W) = W | md5(sha1(pwd)) W(S) = W | md5(bcrypt(pwd)) S(W) = W | bcrypt(md5(pwd)) S(S) = ...


2

A key point is that you have the password hashes in your database so you do not have to re-hash the password. Lets say you have hashed them (correctly, with salt ect.) N times. To double your work factor you can rehash the hashes N more times in the database. And then apply this same rehash to logins in the future. See ...


3

You seem to have summed it up pretty well. The only drawback I can think of is inactive users in your system - they will continue to have a previous work factor because they may never log in again, or may not have chance to log in before your next breach, meaning their stored password is more vulnerable to attack. As work factor is visible within the stored ...


1

I see no faults there. When using bcrypt, it's often actually a good idea to use a regular hash first, because bcrypt has a little known downside of being limited to only 72 characters of input. Using a hash before makes the input size effectively unlimited, while not reducing security at all. So not only do you get the extra strength of bcrypt, but ...


1

With this scheme you are certainly making an attacker’s life harder. Here is the general attack algorithm for cracking bcrypt-protected plaintext passwords: Obtain hashes (obviously) Generate candidate passwords for password cracking tool Perform the cracking attempt And here is the attack algorithm for cracking your sha1-hashed-than-bcrypted passwords: ...


6

Is this SQL injection? Yes. Why? Let's look at what's happening here. $query = "SELECT pass FROM social WHERE email = '$id'"; This passes $id directly to the query. If $id is not sanitized, SQL injection will occur. if($_POST && isset($_POST['submit'], $_POST['password'], $_POST['id'])) { $pass = ($_POST["password"]); $id ...



Top 50 recent answers are included