Tag Info

New answers tagged

3

Making a hash function "iterative" already exists; it is called PBKDF2. Bcrypt is still preferable because PBKDF2 can be thoroughly optimized on GPU. Designing a good password hashing function is a difficult job; but yes, existing hash function are good building elements, so they are likely to be involved at some point. Indeed, look at scrypt: it starts and ...


1

Your understanding of the reasons why one should use scrypt and bcrypt is correct. Yes, you could, at least in theory, produce a new algorithm that requires time and memory, and it could incorporate an existing cryptographically secure hash function. You can increase time through iteration, and increase memory by requiring large numbers of prior values to ...


2

The Algorithms are broken : We can manually generate false certificates given only the md5 signature, for instance. Many weaknesses have been found is SHA-1 to this day, but as far as I know, you can't yet generate a false certificate matching a SHA-1 hash. However, it is being considered obsolete, security experts think this weakness may soon come, and are ...


1

The password in SRP is actually a shared secret of (possibly) low entropy. It can be the "password" as the human user understands it, or anything that is deterministically derived from the password. In your case, yes, using a password hashing function such as PBKDF2 is a valid approach. It has the following caveats: PBKDF2, like bcrypt and other good ...


0

Since the hash functions are really hard to invert you can't simply deduce a solution by providing the hash. There is a negligible probability that an attacker can develop a strategy to find a password that's digest matches with the one you store at the database. Don't know whats PHP's default hash method but all the modern hashing algorithms are collision ...


3

password_verify() takes two arguments: a string of which you want to check if it's the correct password, and the value you calculated earlier with password_hash(), which you presumably stored somewhere in a database or so. A typical application could be: <?php $hash = password_hash('my-secret', PASSWORD_DEFAULT); // normally you would save the hash ...


0

password_verify() will only confirm if a given password matches the given hash. It still requires an input, and rainbow tables are a way to generate possible passwords for input. However, if you're generating a recommended size salt value it will help protect against rainbow table attacks. You can find more on correctly securing passwords using hashes and ...


3

From what I can tell from the comments, you want to use stronger and weaker passwords depending on the sensitivity of the file. For that, I suggest a different approach: Instead of having different passwords, require an extra password for the more sensitive documents. So all files are encrypted by default by the standard password, and the more sensitive ...


3

From Wikipedia: A 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer.[2] This means that there's a weakness in MD5's ability to distinguish between different input data - that two arbitrary inputs may calculate the same hash. In April 2009, ...


4

Why it does not guarantee integrity is easier to see in the case of a stream cipher like RC4, where the encryption is a bit-by-bit XOR of the data with a key-dependent stream. Basically, the encryption of message m is: e = m XOR sk, where sk is the RC4 output (a long stream of pseudorandom bits produced from the key k). Suppose that you ...


2

The problem is that hashing provides nothing in terms of integrity in your scenario. You are relying on the encryption alone to assert integrity. If I get a hold of the message and decrypt it, I could alter the message, recalculate the hash, encrypt it again and pass it on. If you trust encryption alone to provide integrity, then this process works, but ...


5

According to the length of the text it could be one of the following hash formats: DomainCachedCredentials Haval128 MD2 MD4 MD5 NTLM But (because it is a hash, a one way function) you can't decrypt it. You can try to brute force it, but this will possibly take a very long time. All the rainbow tables I know were unable to identify the original ...


3

The SAM database is stored as a file on the local hard disk drive, and it is the authoritative credential store for local accounts on each Windows computer. This database contains all the credentials that are local to that specific computer, including the built-in local Administrator account and any other local accounts for that computer. The SAM ...


14

Regarding truncation in general, it's not necessarily bad at all. In fact, the SHA‑384 algorithm is defined as doing a (slightly modified) SHA‑512 and then truncating the result to 384 bits. I'd like to add to the existing answers by providing the relevant material regarding truncation from the SHA standard. FIPS 180‑4, the SHA standard, ...


36

There is no absolute answer, because it depends on the attack model. By truncating the hash, you make some operations easier; this is bad if the attacker wants to perform these operations, and making them easier actually makes them feasible. There are three main characteristics that cryptographic hash functions try to fulfil: Resistance to preimages: ...


2

When a hash function has an output of size n bits, then: The generic algorithm for finding a preimage (or a second preimage) has average cost 2n evaluations of the hash function. The generic algorithm for finding a collision has average cost about 2n/2 evaluations of the hash function. By "generic" we mean "the algorithm that works against every hash ...


1

In order to support "partial passwords", the bank must necessarily store either the plaintext password, or at least some values that would allow fast reconstruction of the complete password. It is easily seen in the following way: when the bank asks for, say, the 3rd, 4th and 8th letters of the password, then there are less than one million possibilities ...


1

They are probably storing the password encrypted (i.e. not hashed); encryption is reversible so there is no reason why they cannot use code which takes the user input characters, decrypts the stored password and checks the input matches the characters in the password. If done correctly the program used to do this would only temporarily store the plaintext ...


4

No, it does not mean they are storing the passwords in plain text. The question doesn't completely describe the behavior. Are they matching patterns only from your current password, or patterns from all 8 of your previous passwords? If it's the first case, the answer is dead simple, and this is that they have the hashes from the 8 previous passwords ...


0

A hash by definition should not allow you to find if it's similar to something else. From wikipedia: it is easy to compute the hash value for any given message it is infeasible to generate a message that has a given hash it is infeasible to modify a message without changing the hash it is infeasible to find two different messages with the same hash. ...


-1

Quoting wikipedia: It is good practice to not store passwords in cleartext. Instead when checking a whole password it is common to store the result of passing the password to a cryptographic hash function. As the user doesn't supply the whole password it cannot be verified against a stored digest of the whole password. Some have suggested storing ...


5

"MD5(SHA-1(password))" is more secure than "MD5(password)" in the following sense: computing SHA-1 then MD5 on a candidate password takes about 2.5x the time it takes to compute only MD5 on the same password. Thus, it makes naive dictionary attacks 2.5x slower. It still is pathetically weak, for two reasons: 2.5x slower than a single MD5 is still awfully ...


10

You could try Cryptographic Obfuscation when it exists Cryptographic Obfuscation is were, in certain senses, you make a programs source code unreadable. What you can then do is hardcode a cyrptographic key into the program. You would also want the server to supply a random seed to your program since the computer could not be trusted. The only problem with ...


0

It depends on your dictionary. If you intend to use one that begins at the one-character "1" and ends with "zzzzzzzz", it is going to take a looong time. But if you take some guessing, it could be done in a matter of hours. You could invert the order and go "bottom-up". You could use only dictionary words, or totally exclude them. For example, knowing that ...


0

It can vary, but an eight-character password may take 57 days or more (depending on hardware) to crack. But that is in a brute force scenario. It all depends on how high end your graphics proc is as well as other elements.I do Not know much about hashcat. But I do use Kismet I would recommended it in your EH testing. Something to think about: Cracking a ...


19

It is fundamentally impossible to validate that an unmodified version of your client connects to your server. ... unless you do what is necessary to ensure it. This means client-side tamper-resistant hardware. When your code runs on the client's computer, the computer owner can run a debugger and modify the client code at any point with arbitrary values. ...


37

It is fundamentally impossible to validate a client on a system you don't control. That doesn't mean it can't be done to a sufficient degree. eBook readers, for example, generally try to ensure the client is authentic. They (seem to) do so in a manner that is secure enough to defend against their threat. Good enough to protect nuclear secrets? No. But ...


5

I too have approached an issue such as this with the company I work for. after weeks of working it out, the answer is its not really possible. And here is why: You're basically encountering a "Trusted Client" problem. The client code runs on the user's PC, and the user has full control over the PC its originating from. The user can change the bytes of the ...


1

I think your real question is at the end there, "How long is it going to take to break my encryption?" And that tool that you are asking about is mathematics. For symmetric-key ciphers, you can calculate the number of possible keys by using 2^x where x is the number of bits in your key. In AES-256 for example, the key is 256 bits long, which gives us 2^256 ...


2

Existence of a tool that can guarantee security of some encryption system would entail proving a number of hard scientific problems, up to and including the famous P vs NP. Right now, no cryptographer has succeeded in proving that secure encryption or hashing can actually exist, let alone designed a tool that could test a given system. All we have are ...


-2

What are salts used for? Salts try to mitigate the impact (the damage to users) in the wake of a successful server breach that results in all the hash digests in your database being revealed to the public and/or to hackers. Salts are used to protect those revealed hash digests from being brute-forced. So even if a hacker has all your digests, without ...


1

This is similar in functionality to using an algorithm to generate password information. Since you provided an example site: http://hash.tknetwork.de/, we can describe how you might generate a new password when you are required to change it. You can add an integer, date, or other value to the 'parameter' to iterate it You can have multiple master keys ...


14

This basically looks like something along the lines of PBKDF2 or sha512crypt, only with a bunch of "cryptographic voodoo" applied. Salts have a very specific cryptographic purpose: to tie an password-guessing attempt to a single password instance. Having company-specific salts, user-specific salts, per-iteration salts, and (to steal a snark) hand-harvested, ...


1

Just to be clear, there is something else called password hashing that is completely different to what you describe, so that is a terminology collision, which is unfortunate. To handle "exceptions", you must have some storage. One method could be to store (e.g. in a local file) a map from server name to some string, e.g. an integer. The scheme would be: ...


1

The browser checks both fingerprints. The idea behind that is if it is possible to create a fake certificate with the same MD5 or SHA-1 hash, there is a much lower (almost zero) probability the same certificate second hash also matches. This could be called: Dual Hash Fingerprinting. Both MD5 and SHA-1 are considered vulnerable in theory (MD5 also in ...


1

If you picked one of the three weak passwords "love", "dog" and "cow", and a password database was lost: Without salts, I can try these three passwords and find immediately everybody in the whole database using these three weak password. With salting, I have to try love+your salt, dog+your salt, cow+your salt to crack your password if it was ridiculously ...


34

You have to consider two attack vectors: Online attack Offline attack Limiting login guessing helps against Online attacks. Let's say it's three times, this means that an attacker can test ALL accounts for the three most common passwords that fit your password policy (how about "password", "12345678" and "12345"?). Salting helps against Offline attacks ...


1

In theory: If the attacker has not built a rainbow table, if a password of some strength can be hacked in 1 unit of time, then N passwords of that strength can be hacked in O(1) time without salt and O(N) time with salt. That's what salt does. No advantage on a fixed password; shows advantage over multiple passwords. If the attacker has a rainbow table, ...


1

Generally, the most important thing is password length. But it is true that an easy password could be broken down easier than a random one. For example, when you are trying to guess a hash using rainbow tables. If it is a normally used word like "cat" it is more likely that you can have it in this table than "07OFmy3HOY3l9e1gCNww7nNpd5lQ8I9an" ;D


7

Salting/hashing is great if your database gets stolen, but it has nothing to do with dictionary attacks that might take place through the normal login procedure. As you mentioned limiting the number login attempts and using CAPTCHA can make dictionary attacks that take place through the normal login procedure ineffective, but salting (or not) won't have ...


80

Salted hashes are designed to protect against attackers being able to attack multiple hashes simultaneously or build rainbow tables of pre-calculated hash values. That is all. They do nothing to improve the underlying strength of the password itself, weak or strong. This also means that they're not designed to defend against online attacks, so they ...


4

No, one point of salted hashing is to get good randomness in the hash regardless of the starting material. However, this does not free us to use bad passwords. Good hashing only protects against one attack vector: that where the intruder steals the file with the hashes. So many other attack vectors on passwords exist... shoulder surfing, brute forcing, ...


0

No, generally not. Iterating hashes does increase the collision risk, since iterating from H(000...128...000) to H(111...128...111) - assuming H does have 128 bit output, is not guranteed to output 000...128...000 to 111...128...111. Instead, by using such thing, you actually decrease the collision resistance. Iterating hash functions should only be done as ...



Top 50 recent answers are included